lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Saving and restoring window geometry


From: Vadim Zeitlin
Subject: Re: [lmi] Saving and restoring window geometry
Date: Mon, 23 Apr 2018 01:37:12 +0200

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

HKEY_CURRENT_USER\Software\lmi\lmi_wx\Persistent_Options\Window\lmi_main
    x    REG_DWORD    0xfffff885
    y    REG_DWORD    0x1d2
    w    REG_DWORD    0x3b8
    h    REG_DWORD    0x2cc
    Maximized    REG_DWORD    0x0
    Iconized    REG_DWORD    0x0


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.


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

 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.

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. 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.

 To summarize, the possibilities are:

0. Don't save the geometry at all, i.e. keep the current behaviour.
1. Save geometry of each kind of MVC dialog separately.
2. Reuse the same geometry for all MVC dialogs.
3. Some combination of (1) and (2), e.g. save the "Preferences" dialog
   geometry separately, but reuse the same one for all the "Edit
   parameters" dialogs.

 (1) is probably safest, (3) might be the best, but is a bit more
complicated to do and might end up being more confusing to the users than
(2). Please let me know what do you think would be best.

 Thanks in advance,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]