Re: [lmi] 'wine' anomalies

[Greg Chicares]

On 2018-03-06 23:57, Greg Chicares wrote:
> [...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.

Fourth option (pushed): Specify wxSP_ARROW_KEYS. See commit 7e6a56c4d19.
I conjecture that wxXRC's default wxSpinCtrl style is
  wxSP_ARROW_KEYS|wxALIGN_RIGHT
because, in order to get wxALIGN_LEFT behavior, it suffices to specify
wxSP_ARROW_KEYS alone. This seems to suggest an anomalous disagreement
between the spin control's own defaults (if you just put one on the
screen without XRC) and wxXRC's spin-control defaults. This discussion:
  https://lists.nongnu.org/archive/html/lmi/2009-05/msg00005.html
seems relevant. But I don't need any wx change here, because I've found
an effective workaround--at least with 'wine'.

And this commit fixes the 'wine' problem noted above. Staring at XRC
screens for the last two full days has made me notice that Weiss ring
again, but my visual cortex reprograms itself faster than 'wine' does.

And I have a new anomaly to report:
  File | New | Illustration
  "Client" tab:
    focus the "Issue age" spincontrol
    hover the mouse pointer over that spincontrol's upward arrow
    press and release the up-arrow key
Contents change from "45" to "46"...then back to "45".
    press and release the down-arrow key
Contents change from "45" to "44"...and then to "43".
It would appear that the keypress changes the value directly, and then
is interpreted as a mouse-click event and changes the value again. No
other key on the keyboard seems to have this effect--only the up and
down arrow keys.

If I close the tabbed dialog (Esc) and reopen it (Ctrl-E) without
touching the mouse, then it reopens in the same place, and the mouse
pointer is over the spin arrow...but the oddity above is not observed.
Apparently it's not sufficient for the mouse pointer to be located
over that arrow; it must be moved there after the dialog has been
opened.

Of course, if the mouse pointer is hovered over the downward arrow,
a similar (inverse) pattern of behavior is observed.

Oh, and if instead of pressing and releasing the arrow keys only once
as instructed above, I press and release them repeatedly...the behavior
depends on the speed of repetition. Slow repetition just repeats the
noted behavior--e.g., 45->46->45, ... 45->46->45. Fast repetition--say,
five times per second--goes 45->46->47->48->49->50->49, so I guess the
"treat that keypress as a mouse event" processing occurs in idle time.

We won't hold up a release because of this: I don't suppose end users
would ever notice it.