Re: [lmi] Saving and restoring window geometry

[Greg Chicares]

On 2018-04-18 13:43, Vadim Zeitlin wrote:
> On Wed, 18 Apr 2018 12:33:52 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> try the following; I describe what I see under 'wine':
> GC> 
> GC>  - resize and reposition lmi in some recognizable way
> GC>      (I made it a tiny window at lower left)
> GC>  - close and reopen
> GC>      the recognizable size and position have been restored
> GC>  - close and reopen, then minimize, then close and reopen, and unminimize
> GC>      the recognizable size has been restored
> GC>      but the position has been forgotten--lmi is centered
> 
>  I don't see this under msw-7, the position is correctly restored. I'll try
> it later under Wine because I think this might be another Wine-specific
> problem and, hopefully, not one really important in practice, as you probably
> don't often close lmi in minimized state.

It is unusual to close a minimized application manually--I believe people are
more likely to restore its main window and then click on the 'X' close-button.
But our end users use msw, so involuntary closure is common:
 - on "Patch Tuesdays"
 - when corporate overseers force a reboot
 - when the battery runs out
 - upon manual reboot or shutdown for any number of good or bad reasons
and even in the last case I think it's really uncommon to close applications
first. I'd expect window geometry to be preserved for applications closed in
such ways, in response to WM_ENDSESSION.

On 2018-04-18 16:26, Vadim Zeitlin wrote:
| 
|  FWIW I've now rebuilt the latest version under Linux and ran it under Wine
| and I still don't see the problem, neither with wine (3.0) nor
| wine-development (3.5). Perhaps it's due to the difference in the WM being
| used? I just use the bog standard Gnome shell here.
| 
|  Anyhow, I don't think we want to spend much more time on this for the
| already mentioned reasons, so I'll stop debugging this here (but will
| continue with the other bug, related to maximizing the window), unless you
| tell me differently.

Bog-standard gnome doesn't like my
  Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]
because it wants 3D hardware acceleration, and I'm not intelligent enough to
figure out how to use it anyway--I installed it on a machine with fancier
graphics hardware recently, and spent several unproductive minutes trying to
figure out how to open a terminal so I could still use it as a computer.
Therefore, I'm using xfce, which is not necessarily perfect.

At any rate, I don't trust wine to display msw applications properly, so I
look at 'HKCU\Software\lmi\lmi_wx\Persistent_Options\Window\lmi_main'. The
hextuple of values {Iconized,Maximized,h,w,x,y} (decimal unless '0x...') has
the following values after closing in the state given:

  I M    h    w          x   y
  0 1 1168 1930 0xfffffffb  37  maximized = state before closing
  0 0 1168 1930 0xfffffffb  37  unmaximized
  0 0  259  328 0xfffffffb  37  resized
  0 0  259  400       1316 837  resized and moved
  1 0  259  400       1316 837  minimized
  0 0  259  400        760 488  unminimized [1]
  0 1 1168 1930 0xfffffffb  37  maximized [2]

[1] x and y change when they shouldn't IMO
[2] h,w,x,y change when they shouldn't IMO

As long as you're looking at the last line, I figure it's easy to consider
the second-to-last at the same time.

>  FWIW I even wonder if we really want to reopen the window in the minimized
> state if it was minimized when closed. There are some applications for
> which it could make sense, but I don't think it really does for lmi and lmi
> users might be confused if the application window doesn't come up after
> launching it. Or I could also be over-thinking things.

I look at it from a different perspective. Changing only Iconized or Maximized
in the hextuplet above shouldn't affect the {h,w,x,y} values. Those four apply
only in the neither-minimized-nor-maximized state, so changing that state
shouldn't affect them. When a window is {max,min}imized, it should remember
its pre-{max,min}imization h-w-x-y quadruplet, so that restoring the window
retrieves the last h-w-x-y settings as they were the last time the user set
them by moving or resizing.

Put otherwise,
 {max,min}imizing and then restoring
should behave exactly the same way as
 {max,min}imizing, closing and reopening, and then restoring.
I do believe that's the behavior of google-chrome on msw-10. In the old days,
"do whatever ms-word does" was always correct advice; I've just substituted
google-chrome because I think that's now the most widely used and respected app.

Of course, if wine didn't obey the registry values, that would be a wine defect.
But I don't see how wine could really affect which values get saved.

> GC>  - close and reopen, then maximize, then close and reopen, and unmaximize
> GC>      neither size nor position is restored
> GC>      it's the same size as a maximized window
> 
>  I do see this and it's indeed a (known) problem. It's actually even worse
> for me because the window appears as maximized on the wrong (primary)
> monitor instead of the one on which I had maximized it before, so it's
> really annoying. I'd like to fix this, but I think it would involve doing
> it in wxWidgets itself, so I probably need to do it very soon, before you
> upgrade the version used by lmi. Could you please let me know when (at the
> earliest) will this happen?

We're reexamining our short-term plans, so let me get back to you tomorrow.