Re: [lmi] Saving and restoring window geometry

[Vadim Zeitlin]

On Mon, 23 Apr 2018 00:30:56 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-04-22 23:37, Vadim Zeitlin wrote:
[...]
GC> > But for the geometry, I'm less sure: if
GC> > the user positioned the "MEC parameters" dialog at some place (e.g. I 
might
GC> > want to drag it over another display), wouldn't they want the "GPT
GC> > parameters" dialog appear at the same place when it's next shown? I think
GC> > they would, but the same kind of logic might not apply to the 
"Preferences"
GC> > dialog... so, finally, I don't know how appropriate would it be and would
GC> > like to leave the choice to you, if you don't mind making it.
GC> 
GC> Don't save geometry.

 I have no objections to this (as it doesn't require me to do anything...)
but I'd just like to make sure I've explained the choice clearly because it
seems to me that I might have failed in doing this once again,

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.

GC> And imposing a universal {h,w} would be worse for me than for anyone
GC> else, because...well, try resizing an XRC dialog in 'wine' and you'll
GC> see how awful it is.

 Yes, I did see it :-( I don't know why resizing is so bad with Wine, I
really should compile it from sources and debug it it one of these days.

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.

 Again, I won't return to this question if you've already decided that (0)
was better than (2) and not just better than (1) (which is, once again, we
both agree is unacceptable), but I'd just like to make sure you did notice
that the choice was not limited to (0) or (1) and that the argument against
(1) given above didn't apply to (2).

 Regards,
VZ