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

[Vadim Zeitlin]

On Sat, 08 Mar 2008 16:41:31 +0000 Greg Chicares <address@hidden> wrote:

GC>  + (0) A menuitem for each open child
GC> 
GC> That's what started this discussion, and it's a problem that wx
GC> has already solved, so we just have to remove lmi code that gets
GC> in the way--but without breaking anything else marked '*'.

 Ok.

GC>  * (1) "Window" menu shown iff an MDI child is open
GC> 
GC> http://msdn2.microsoft.com/en-us/library/ms644908(printer).aspx
GC> | When no child window exists, the menu bar should contain only
GC> | items used to create or open a document.

 This guideline doesn't seem to be followed by any MDI applications I have
on my system (which happen to be exclusively Microsoft ones) but it does
seem logical and I agree wx should follow it. It will take some effort to
change the code to do it like this but from my initial reading of it it
should be possible.

GC>  * (2) "Window|Next" enabled iff more than one MDI child is open
GC>        ("Window|Previous": likewise)
GC> 
GC> These commands can't do anything if only one MDI child is open.
GC> It seems wrong to enable a command that can't do anything.

 Again, this doesn't seem to be done like this by any of the example
applications I can see. Here the problem is compounded by the fact that
"Next" item doesn't only appear in the "Window" menu but also in the so
called "MDI child" menu which appears if you click on the window button of
the MDI child frame or press Alt+-. Disabling it there should be possible
but is IMO more trouble than it is worth, would it be acceptable to leave
it as is there and only update its state in the "Window" menu? OTOH it
could also be confusing to have it enabled in one place and disabled in the
other one...

GC>  * (3) no "Arrange icons" menuitem

 I agree that we should just drop it, it doesn't do anything useful.

GC>  * (4) menu item labels use sentence capitalization

 Under Windows using "Tile Horizontally" seems to be standard practice so I
don't think we should change this by default. And it's already possible to
override this by changing the label of window menu items by modifying the
menu returned by wxMDIParentFrame::GetWindowMenu() so arguably LMI should
just do this. Or it could replace the menu completely by using
SetWindowMenu().

GC>  * (5) menu items can have help text and bitmaps
GC> 
GC> Other menus have help text; XRC makes it so easy. But with the
GC> patch below, XRC <help> tags are displayed on the statusbar iff
GC> no MDI child window exists.

 Sorry, do you mean help text for the "Window" menu items (which doesn't
seem to be defined) or for normal menu items (which works just fine for me
in the wx mdi sample)?

GC> I'd like <help> tags to behave the same way regardless of any
GC> child-window context, and I'd like to be able to specify my own
GC> help text and bitmaps for menuitems on the "Window" menu.

 This can be achieved by using SetWindowMenu(). It would be arguably even
better to have OnCreateWindowMenu() virtual callback to avoid creating the
standard menu unnecessarily but this can't be done in the 2.8 branch as
adding a new virtual method is not ABI-preserving. I'd be glad to do it in
the trunk if you think it would be useful for LMI later however.

 As for the standard behaviour, I agree that we should add help text to the
built-in menu. However we can't add bitmaps to it both because we don't
have any standard bitmaps for this and because it would look out of place
in an application not using bitmaps for the other menu items.

GC>  + (6) "Illustration | Edit" disabled for child documents
GC>        (corresponding accelerator Ctrl-E: likewise)
GC>        (corresponding toolbar button: likewise)
GC> 
GC> The "child document" concept is described here:
GC>   http://savannah.nongnu.org/support/?104485
GC> and a child document can easily be created thus:
GC>   alt-F N C
GC>   Ctrl-R

 Unfortunately I still have no clear idea about how to implement this
concept which doesn't really have any native equivalent. An easy thing
to do would be to use a modal dialog for the child but this isn't
appropriate here, is it?

GC> Those are the desired behaviors. What's the best way to achieve
GC> them all?

 Most of them can be (more or less easily) fixed in wx and I'll work on
this. (5) can be done in LMI itself. (6) is tricky.

 Regards,
VZ