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

[Greg Chicares]

On 2008-03-14 16:58Z, Vadim Zeitlin wrote:
> On Sat, 08 Mar 2008 16:41:31 +0000 Greg Chicares <address@hidden> wrote:
> 
> 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.

Their applications really did behave that way, years ago.
"Object Oriented Programming Under Windows NT and 95" (1999)
says on page 128:

http://books.google.com/books?id=wrG5JR16UqEC&pg=PA128&sig=yC5SzVJTZn16LCSmN3skgZ3-nBQ
| "A good example of this can be found in Microsoft Excel. When
| there are no spreadsheet or chart windows open, the main window
| has only two menus: File and Help.

So I guess they're no longer following their own guidelines as
specified in the msdn quote above.

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

Okay, great.

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

Good point--I hadn't noticed that.

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

Agreed. We shouldn't change built-in OS behavior of the "Alt+-"
menu because it's much like the "system menu". Just updating the
state in the "Window" menu would be fine with me.

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

Changing this in lmi (instead of in wx) is fine with me. Ideally,
an overriding menu item label could be expressed in XRC.

Could I ask you, though, to show me how to implement it cleanly?
I've already implemented all of these things in lmi long ago, but
my solutions have two problems:

(a) They seem too elaborate. Consider 'docmdichildframe_ex.?pp':
the header documents the purpose, along with the issues I ran
into and how I worked around them; but two files totalling 215
lines seems like an awful lot of code to maintain for such a
simple purpose. I couldn't find a better solution. I bet you can.

(b) They seem fragile. For example, the immediately-following
item (5) shows that when I undo one of my changes, a puzzling
(to me) misbehavior pops up in an unexpected place.

> 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)?

If I apply the patch cited above:
  https://savannah.nongnu.org/patch/download.php?file_id=15212
then I see no statusbar help text for any menuitem at all when
any MDI child exists.

Load the application afresh and pull down the "Help" menu: I see
the "Contents" menuitem highlighted, and "Read documentation" on
the statusbar.

Open any MDI child--say, 'sample.db4'--then pull down the "Help"
menu again: now I see nothing on the statusbar.

This isn't broken in HEAD: it's my patch that breaks it. Either
that patch does something wrong, or it uncovers some latent
problem in something else I've done. I fear I've made a mess of
this whole "Window" menu, and it may be better to throw out
everything I've done here and just do it the right way.

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

That sounds like a good idea to me; use your judgment. We can
use SetWindowMenu() now in lmi, and replace it with a virtual
callback later on, after wx-2.8 .

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

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

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

A modal dialog wouldn't work. An important actual use case is to
create two such MDI child windows with slightly different input,
and toggle between them to analyze the output differences.

But this is a tangent that I'll spin off into a different message
thread. I had brought it up here because of my persistent lack of
success in disabling certain menuitems for such a child window.
Perhaps it'll become clearer how to solve that problem if we
follow that tangent through.

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

Okay, great.