Re[2]: [lmi] Adding open files to MDI "Window" menu

[Vadim Zeitlin]

On Tue, 18 Mar 2008 14:24:23 +0000 Greg Chicares <address@hidden> wrote:

[better very late than never]

 Hello,

 I return to this old topic which contained requests for several
enhancements to MDI stuff in wxWidgets. I believe that all of them are now
implemented in svn trunk (i.e. what will become 2.9.0 soon) but as I also
significantly refactored and simplified the code while doing this, it is
not easy at all to back port any of these fixes to 2.8 branch. So I hope
that LMI switches to 2.9 (a.k.a. wx svn trunk) in some not too distant
future so that it could profit from these fixes. In the meanwhile I'm going
to test them myself in LMI (so far I only did it in wx mdi sample) and I'd
like to ask you if you'd accept patches with changes inside "#if
wxCHECK_VERSION(2, 9, 0)" even now or if I should keep these changes
locally and submit them to you later when you do switch to 2.9?


GC> On 2008-03-14 16:58Z, Vadim Zeitlin wrote:
GC> > On Sat, 08 Mar 2008 16:41:31 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC>  * (1) "Window" menu shown iff an MDI child is open
...
GC> > It will take some effort to change the code to do it like this but
GC> > from my initial reading of it it should be possible.
GC> 
GC> Okay, great.

 This was done some time ago (in beginning of September), see
http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=55458 It doesn't
require any changes in LMI code, i.e. when you upgrade to 2.9 this will
simply start working as expected if you use the built-in window menu, i.e.
do not use wxFRAME_NO_WINDOW_MENU style.

 
GC> > GC>  * (2) "Window|Next" enabled iff more than one MDI child is open
GC> > GC>        ("Window|Previous": likewise)
GC> > GC> 
GC> > GC> These commands can't do anything if only one MDI child is open.
GC> > GC> It seems wrong to enable a command that can't do anything.
...
GC> > Disabling it there should be possible
GC> > but is IMO more trouble than it is worth, would it be acceptable to leave
GC> > it as is there and only update its state in the "Window" menu?
GC> 
GC> Agreed.

 This is also done now: 
http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=58440
As with the above change, nothing is needed at LMI level.


GC> > GC>  * (4) menu item labels use sentence capitalization
GC> > 
GC> >  Under Windows using "Tile Horizontally" seems to be standard practice so 
I
GC> > don't think we should change this by default. And it's already possible to
GC> > override this by changing the label of window menu items by modifying the
GC> > menu returned by wxMDIParentFrame::GetWindowMenu() so arguably LMI should
GC> > just do this. Or it could replace the menu completely by using
GC> > SetWindowMenu().
GC> 
GC> Changing this in lmi (instead of in wx) is fine with me.

 This is now shown in the mdi sample, see 

http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/samples/mdi/mdi.cpp?r1=58462&r2=58461&pathrev=58462

As you can see, you can simply modify the labels of the standard commands.
You must use the standard identifiers for them (wxID_MDI_WINDOW_XXX) but
other than that it's the same as working with any other menu. In
particular, you can also define accelerators, help strings and bitmaps (not
shown in the sample) for them.


GC> Ideally, an overriding menu item label could be expressed in XRC.

 Unfortunately I don't see how could it work because you can't load a
single menu item from XRC AFAIK. You can, of course, define the entire menu
in XRC and then just call SetWindowMenu(). But then you'd need to add all
standard commands to it yourself which is not ideal. If you really just
need to change the text of 2 items the approach used by the sample seems
better.

GC> Could I ask you, though, to show me how to implement it cleanly?
GC> I've already implemented all of these things in lmi long ago, but
GC> my solutions have two problems:
GC> 
GC> (a) They seem too elaborate. Consider 'docmdichildframe_ex.?pp':
GC> the header documents the purpose, along with the issues I ran
GC> into and how I worked around them; but two files totalling 215
GC> lines seems like an awful lot of code to maintain for such a
GC> simple purpose. I couldn't find a better solution. I bet you can.
GC> 
GC> (b) They seem fragile. For example, the immediately-following
GC> item (5) shows that when I undo one of my changes, a puzzling
GC> (to me) misbehavior pops up in an unexpected place.

 I'm not sure about this part. In particular I don't really see what does
the code in docmdichildframe_ex.?pp have to do with this, it seems to
mainly preoccupy itself with the status bar and not menus at all.

 So I'd like to ask if you still have any questions or if maybe the changes
described above answered them as a side effect?


GC> > GC>  * (5) menu items can have help text and bitmaps
GC> > GC> 
GC> > GC> Other menus have help text; XRC makes it so easy. But with the
GC> > GC> patch below, XRC <help> tags are displayed on the statusbar iff
GC> > GC> no MDI child window exists.
GC> > 
GC> >  Sorry, do you mean help text for the "Window" menu items (which doesn't
GC> > seem to be defined) or for normal menu items (which works just fine for me
GC> > in the wx mdi sample)?
GC> 
GC> If I apply the patch cited above:
GC>   https://savannah.nongnu.org/patch/download.php?file_id=15212
GC> then I see no statusbar help text for any menuitem at all when
GC> any MDI child exists.

 I didn't test this with LMI itself yet but this works for me in the mdi
sample. It definitely didn't work for the "Window" menu items (custom ones,
as the standard menu doesn't define any help strings) but I've fixed this
in http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=58478

 However it worked even before this change for the normal menu items.

GC> Load the application afresh and pull down the "Help" menu: I see
GC> the "Contents" menuitem highlighted, and "Read documentation" on
GC> the statusbar.
GC> 
GC> Open any MDI child--say, 'sample.db4'--then pull down the "Help"
GC> menu again: now I see nothing on the statusbar.

 I'll retest it with my latest changes anyhow soon but I think this should
work fine now (at least it does in the sample).

GC> > GC> I'd like <help> tags to behave the same way regardless of any
GC> > GC> child-window context, and I'd like to be able to specify my own
GC> > GC> help text and bitmaps for menuitems on the "Window" menu.
GC> > 
GC> >  This can be achieved by using SetWindowMenu().
...
GC> That sounds like a good idea to me; use your judgment. We can
GC> use SetWindowMenu() now in lmi, and replace it with a virtual
GC> callback later on, after wx-2.8 .

 This does work now, by using SetWindowMenu() or by changing a help string
for an existing menu item as the mdi sample does, but it didn't work in 2.8
due to a bug.

GC> Agreed. What I seek here is not to force my preferences upon wx
GC> globally, but to gain a customization hook that lets me express
GC> my preferences locally in lmi--and preferably through XRC.

 Just as above, you can define the entire menu in XRC. But it's actually
not a good idea as you'd need to take into account the differences between
the platforms yourself then. So I'd rather recommend doing it from the code
after checking that the items you modify are indeed present.

GC> > GC>  + (6) "Illustration | Edit" disabled for child documents
GC> > GC>        (corresponding accelerator Ctrl-E: likewise)
GC> > GC>        (corresponding toolbar button: likewise)
GC> > GC> 
GC> > GC> The "child document" concept is described here:
GC> > GC>   http://savannah.nongnu.org/support/?104485

 This is still work in progress but I hope to finish it soon (I aim for
this month...).

 Thanks for your patience,
VZ