Re: [lmi] Saving and restoring window geometry

[Greg Chicares]

On 2018-04-22 23:37, Vadim Zeitlin wrote:
> On Thu, 19 Apr 2018 12:52:30 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-04-18 21:58, Greg Chicares wrote:
> GC> > On 2018-04-18 13:43, Vadim Zeitlin wrote:
> GC> >> On Wed, 18 Apr 2018 12:33:52 +0000 Greg Chicares <address@hidden> 
> wrote:
> GC> [...]
> GC> > look at 'HKCU\Software\lmi\lmi_wx\Persistent_Options\Window\lmi_main'.
> GC> 
> GC> It's inconvenient to use 'regedit' to see what's going on. Is there an
> GC> easy way to show the settings that are saved when lmi is closed, just
> GC> for debugging?
> 
>  The following command shows them sufficiently nice IMHO:
> 
> % reg query HKCU\\Software\\lmi\\lmi_wx\\Persistent_Options\\Window\\lmi_main

Agreed. Thanks, I didn't know how to do that in a GUI-less way.

> GC> We haven't yet been able to begin testing any wx upgrade in earnest.
> GC> If you can fix this within, say, one week from now, then we'd rather
> GC> wait for you to do that before we begin testing. Does that work for you?
> 
>  I'll try to do this in the next couple of days, but I actually hoped to do
> it today but didn't because I realized that it's not as simple as I thought
> and so I need more time to decide what's the best way to do it. I'll post
> here when I'll have done it.

Great.

> GC> Could you also write a little patch to make lmi's tabbed input dialog
> GC> persistent? We currently save the selected tab during a session:
> GC> 
> GC>   MvcController::MvcController
> GC>   ...
> GC>     
> BookControl().ChangeSelection(last_selected_page[view_.ResourceFileName()]);
> GC> 
> GC> but that information is lost when lmi closes. I'm assuming that
> GC> wxPersistenceManager would save the tab selection...
> 
>  Yes, it does exactly this for wxBookCtrl (see its documentation at
> http://docs.wxwidgets.org/3.1.1/classwx_persistent_book_ctrl.html) and here
> is the requested little patch: https://github.com/vadz/lmi/pull/83

Okay, I'm working on PDF column margins now, but I should be able to
pull that this week.

>  As you can see, it's really simple and the only potentially controversial
> aspect I see is using the base name of the resource file name as the unique
> key identifying the book control. But the use of the resource file name is
> consistent with the current code and getting rid of the extension makes the
> config keys nicer, without really changing anything else.

Reading your next section without even looking at this patch, this seems
far better than trying to use a single name for every 'skin'.

> GC> but if my guess is wrong and it saves only window geometry, then this
> GC> wouldn't be useful after all.
> 
>  Note that the PR above saves _only_ the page selection, but _not_ the
> window geometry. If you think that saving its geometry would be useful too
> (FWIW I do think so), I could make another commit doing this too, of
> course, but here I have a question: do you think we should still save
> separate geometries for the different MVC dialogs or use the same one for
> all of them? For the page selection, the answer to this question is clear:
> as different MVC books have different pages, it doesn't make any sense to
> reuse the same selection for them.

Indeed. Changing skins is useful, but rare. Page names differ even among
'skin*.xrc', and more so among other '*.xrc' files.

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

Don't save geometry.

AIUI, you're asking whether it would be nice to have various tabbed dialogs
all use the same {x,y}; I think that's extremely unimportant. OTOH, making
them all use the same {h,w} would be procrustean. Even different 'skin*.xrc'
files don't share the same natural geometry, and the other things like
'mec.xrc' are even more different. And imposing a universal {h,w} would be
worse for me than for anyone else, because...well, try resizing an XRC
dialog in 'wine' and you'll see how awful it is. (In native msw, at least
you can get back to the natural default size my reducing the dimensions as
much as you're allowed, but with 'wine' you're allowed to reduce the paint
area to zero pixels IIRC.)

>  To summarize, the possibilities are:
> 
> 0. Don't save the geometry at all, i.e. keep the current behaviour.

This is the One True Way.