Re: [lmi] 'wine' anomalies

[Greg Chicares]

[...Late reply; but we've started discussing wine again, so...]

On 2017-11-15 21:30, Vadim Zeitlin wrote:
> On Tue, 14 Nov 2017 16:13:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--Off the list, on Thu, 19 Oct 2017 15:52:52 +0000, I wrote to you
> GC> about this 'wine' anomaly:
> GC> 
> GC> | - wxSpinCtrl text is right-aligned in an area that includes the
> GC> |    up and down arrows: in the screenshot, e.g., "Retirement Age"
> GC> |    is "65", but the "5" is mostly obscured (would it be weird to
> GC> |    force the "wxALIGN_LEFT" style upon end users?)
> GC> 
> GC> (you thought that was either a 'wine' or a DPI defect).
[...]
>  Anyhow, I'd just like to confirm that I do see the problem with wxSpinCtrl
> here too, running it under Wine 2.0-3 with 200 DPI. And it really looks
> like a Wine bug because I also see it in the widgets wx sample and even at
> DPI 96, while the same binary works fine in a VM with DPI 200.
> 
>  So what to do about this? The first thing I'd do would probably be to try
> with a more recent Wine version, Debian Buster (current "testing") has 2.20

Today we both tried "buster", which now has wine-3.0; this problem
still occurs.

> [...] we could try to fix it in Wine which would, of
> course, be ideal in the long term, but might be not simple (I've never
> tried fixing bugs in Wine before) and won't get into a Debian version of
> Wine for quite some time, or we could try to work around it somehow in
> wxMSW itself.

Third option (recommended): I'll just keep living with it. The human
brain adapts remarkably well. I know: the "Weiss ring floater" that
appeared in my left eye one week before Christmas hasn't changed
physically at all, but I hardly notice it now--just as my retinolgist
predicted.

>  FWIW I also see the 2 other bugs, with black-and-white disabled bitmaps
> and long date problem, but I don't have the fixes for them neither, yet.
> I'll try to return to these issues soon.

I think you suggested an effective fix for long dates in a later
message. Here it is, from 'README.schroot':

wine regedit
# HKCU\Control Panel\International:
#   set sShortDate and sLongDate to "yyyy-MM-dd"

> GC> I have a new observation to add:
> GC> 
> GC> In lmi's tabbed input dialog, <help> text seems to be inaccessible.
> GC> IIRC, in native msw there's a '?' button in the dialog's title bar
> GC> that's used to access this context-sensitive help. With 'wine', I
> GC> see three buttons there: [...] but no '?' button.
> 
>  It looks like you use the default (checked) value of the "Allow the window
> manager to decorate the windows" option in the "Graphics" tab of winecfg
> (see https://wiki.winehq.org/Winecfg). With this option, Wine doesn't draw
> the window title bars at all, so it's not surprising that it uses standard
> XFCE buttons and doesn't have the "?" one.
>  
>  Unfortunately, even after clearing this option -- and seeing suitably ugly
> MSW title bar in the main window now -- I still don't see the "?" button,
> so apparently it's just something that's not implemented by Wine. And

I just tried that with wine-3.0, and it's still as you describe above.

> searching for WS_EX_CONTEXTHELP in Wine sources seems to confirm it, there
> just doesn't seem to be any code for handling it anywhere (although it
> could be hidden in some macros, of course...).
> 
>  I'll recheck this when/if I update to 2.20 to test the other bug, but I
> don't see anything about this being recently implemented in the change log,
> so I don't think it's going to change anything and, again, the best we can
> do is probably just open a Wine bug for this and hope that it gets
> addressed, because I don't think we really want to spend time on working on
> Wine ourselves (not that I wouldn't want to help another open source
> project, but there is simply not enough time for everything...), especially
> on a relatively unimportant bug like this.

Agreed: not worth our time. I think this is another of those features
like alt-hyphen that only really "woke" msw users ever even knew about,
and we wane while the un-woke wax. Today everyone just wants to say:
"Alexa, explain inforce deemed cash value".

> GC> BTW, the icon on this dialog is a wine bottle, whereas other lmi
> GC> windows have lmi icons.
> 
>  Well, at least I can fix this one:

Your [snipped] patch works. I'll commit it soon. Thanks.

> I'm pretty sure it shouldn't be _necessary_ to set the icon explicitly like
> this because the dialog is supposed to inherit the icon from its parent
> frame, but it probably doesn't hurt to do it neither. Perhaps we could even
> do it in wxMSW itself...

I never saw this anomaly outside wine, but after all the wine-glass
icon certainly comes from wine, so how would anyone see it anyway in
native msw? Probably not worth the bother to put this in wxMSW, unless
you think wx has wine users outside of Glastonbury.

> GC> The <help> text isn't accessible by right-clicking or hovering
> GC> the mouse, either; I don't recall whether either of those methods
> GC> showed <help> in native msw.
> 
>  No, it was never accessible by hovering (this just shows "normal"
> tooltips, which are different from the context help tooltips) and while I
> think that it was indeed possible to show popup menu with "Show help" item
> by right clicking on the control, it must have been in some ancient MSW
> version (if ever at all).

Let me assure you that it once existed. Probably in the same msw version
where you could drag and drop stuff on the "trashcan" icon, and it would
actually get deleted. Not as elegant as typing 'rm', but better than
what they're selling nowadays.

> So without the "?" title bar button there is
> indeed no way to show it.

Apparently only I lack the "?" button (due to wine).
But I'm not the target audience.

>  At wxWidgets level, there is wxContextHelpButton which can be used instead
> of this button on non-MSW platforms and, in principle, we could use it in
> the dialog itself and show it only when running under Wine. But I don't
> know if it's really worth the effort, so I won't do this unless you tell me
> that it is.
We already have a "Help" pushbutton on the tabbed dialog. I don't
remember--does it do anything under native msw? If it never does
anything, then maybe we should remove it.

I know we had a long discussion of context-sensitive help here
about a decade ago, whose conclusion is summarized inline thus:

/// Contextual <help> elements in wxxrc files are made available by
/// wxSimpleHelpProvider. No fancier version of that class is needed.

and I still agree that anything less simple is not worth the effort.