Re: [lmi] Saving and restoring window geometry

[Greg Chicares]

On 2018-04-23 13:28, Vadim Zeitlin wrote:
> On Mon, 23 Apr 2018 00:30:56 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Don't save geometry.
[...]
> GC> AIUI, you're asking whether it would be nice to have various tabbed 
> dialogs
> GC> all use the same {x,y}; I think that's extremely unimportant. OTOH, making
> GC> them all use the same {h,w} would be procrustean.
> 
>  This is a good point and means that my alternative (1) from the message at
> http://lists.nongnu.org/archive/html/lmi/2018-04/msg00094.html was a bad
> idea (and I should have realized this myself, sorry). However it doesn't
> necessarily invalidate (2)...
> 
> GC> Even different 'skin*.xrc' files don't share the same natural geometry,
> GC> and the other things like 'mec.xrc' are even more different.
> 
>  ... because with (2) we'd save different geometries for each of those
> dialogs as each of them uses a different XRC file and hence we'd use a
> different config key (as they're based on MvcView::ResourceFileName()) for
> them.

Where you say (2) here, I think that's the old (1):

  http://lists.nongnu.org/archive/html/lmi/2018-04/msg00094.html
| 0. Don't save the geometry at all, i.e. keep the current behavior.
| 1. Save geometry of each kind of MVC dialog separately.
| 2. Reuse the same geometry for all MVC dialogs.

...but, regardless, I don't see any need to save either
 - separate geometry for each 'skin*.xrc' individually; or
 - a common geometry for all  'skin*.xrc';
or any geometry at all for any '*.xrc' file.

These are all modal dialogs except, I guess, 'rounding_view.xrc'
and 'policy_view.xrc' (and non-windows like 'menus.xrc'). For those
two '_view' windows, we could imagine setting up one of each, side
by side, and wanting to make that layout persist--but such a thing
would occur so rarely, if ever, that it's not worth discussing,
much less testing and debugging. For the dialogs, not even such a
weak case can be made: they pop up in an appropriate position that
nobody has ever complained about; you can move them if you want; and
if you move them so that they don't fit within the screen, that's
your own fault--whereas if you do something silly like that and we
make it persistent, it becomes our fault. Therefore:

> GC> >  To summarize, the possibilities are:
> GC> > 
> GC> > 0. Don't save the geometry at all, i.e. keep the current behaviour.
> GC> 
> GC> This is the One True Way.

The only situation in which I'd say otherwise is if the default
behavior does something astonishing with dual monitors (which I
wouldn't notice because I use a single monitor). E.g., if by default
lmi's main window appears on monitor #0, and the tabbed input dialog
on monitor #1, and messageboxes on perhaps a third monitor; and if
making geometry persistent is the only way to let users fix such
weirdness once and for all--then that would need to be considered.

Otherwise, option Zero is best: it requires no work and no testing,
it doesn't allow us to introduce new defects, and I can see no
significant benefit to doing anything else.