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

[Greg Chicares]

On 2008-03-05 13:51Z, Vadim Zeitlin wrote:
> On Wed, 5 Mar 2008 14:45:33 +0100 Vaclav Slavik <address@hidden> wrote:
> 
> VS> Greg Chicares wrote:
> VS> > Would it be difficult to add one menuitem to the MDI "Window"
> VS> > menu for each open file?
> VS> 
> VS> Not at all, it's standard wx behavior, unless the app explicitly 
> VS> disables it. This change restores default behavior:
[...]
> VS> -            |   wxFRAME_NO_WINDOW_MENU
> 
>  BTW, I dug into cvs history to see where does this wxFRAME_NO_WINDOW_MENU
> style come from and it seems to have been there from the very beginning
> (i.e. 2005-03-12 03:01:08 commit with log message "Add GUI files"). I have
> really no idea why was it used though...

At the end of the last millennium I was trying to make wx do some
things a little differently than it did OOTB. In certain cases, I
copied and forked little pieces of wx: this command
  grep Julian.Smart
should find most of them. That was before we were working on lmi
together, and I couldn't have made time to propose and follow up
on wx patches myself. It was the best I could do back then.

Maintaining these frozen "forklets" forever isn't the right thing
to do going forward. I had customized parts of what eventually
became wx-2.2.9, and now that freezes us out of improvements in
wx--some of which address the same concerns, but of course in an
incompatibly different way. The string-comparison operators in
lmi's 'wx_workarounds.hpp' demonstrate this clearly:
 - before wx-2.5.4, they were actually helpful;
 - between [wx-2.5.4, wx-2.6.0), they were superfluous;
 - since wx-2.6.0, they've had to be suppressed, because they
   interfered with wx's own solution to the same problem.
Another example is Vaclav's 'census_document.cpp' change here:
  https://savannah.nongnu.org/patch/index.php?6411
where the first twenty or so lines of the actual patch:
  https://savannah.nongnu.org/patch/download.php?file_id=14993
remove lmi code that only attempts to do something that wx does
already. (I haven't had time to apply all those changes yet, but
I haven't forgotten them--and there are about twenty remaining
files with changes like that one.)

This wxFRAME_NO_WINDOW_MENU thing is yet one more example. With
wx-2.2.9, I had to emulate the MDI "Window" menu outside of wx
in order to offer both vertical and horizontal "Tile" menuitems
(among other reasons enumerated below). But now wx provides both
those menuitems by default. This 20070222T0011Z change:
  http://cvs.sv.gnu.org/viewvc/lmi/lmi/main_wx.cpp?r1=1.70&r2=1.71&view=patch
replaced some platform-specific code with this:
  frame_->Tile(wxVERTICAL);
but that's only a leaf, and the root of the maintainability issue
(the emulation of this whole menu) remains untouched.

Old workarounds don't just lock us out of new improvements; they
also make the code harder to maintain. For example, removing the
wxFRAME_NO_WINDOW_MENU style is the obvious way to add open files
to the "Window" menu, except that it has surprising consequences:
e.g., open any file, and you'll see two "Window" menus (as well
as a host of subtler problems). The code that's responsible for
that is class DocMDIChildFrameEx (in 'docmdichildframe_ex.?pp')
and the EVT_MENU_OPEN handlers. Below is an experimental patch[1]
that suppresses that old code and lets the latest built-in wx
behavior shine through, unless
  CPPFLAGS='-DUSE_OLD_WINDOW_MENU'
is used.

The world isn't going to come to an end if I go into the office
wearing one blue sock and one brown, or one brown shoe and one
black, or a checkered shirt with striped pants; but people would
perceive it as a most unfortunate fashion statement, to say the
least, if I did all those things on the same day. Similarly, the
lack of any one of the desired behaviors on this list might be
forgiven, but lacking too many of them would suggest insufficient
attention to the little details that make an application easy to
learn and use. Let me explain the behaviors I'd like to achieve,
writing
 '*' next to each one that only the old lmi code achieves, and
 '+' next to each one that only the patch below achieves,
and then ask how you would reimplement what I've done.

 + (0) A menuitem for each open child

That's what started this discussion, and it's a problem that wx
has already solved, so we just have to remove lmi code that gets
in the way--but without breaking anything else marked '*'.

 * (1) "Window" menu shown iff an MDI child is open

http://msdn2.microsoft.com/en-us/library/ms644908(printer).aspx
| When no child window exists, the menu bar should contain only
| items used to create or open a document.

Files 'docmdichildframe_ex.?pp' serve no other purpose than this.
If there's a better way to accomplish it, then I'd be happy to
eliminate those files--then we'd have a couple hundred fewer
lines of code to maintain.

 * (2) "Window|Next" enabled iff more than one MDI child is open
       ("Window|Previous": likewise)

These commands can't do anything if only one MDI child is open.
It seems wrong to enable a command that can't do anything.

 * (3) no "Arrange icons" menuitem

Correct me if I've got this wrong, but I think true "iconic"
child windows were last seen in msw-3.x; while msw-95 and later
still use the word "iconic", they really mean minimized--so this
command is only a historical artifact, and it's just not useful
today to have a command that arranges minimized windows, because
they don't look like icons anymore.

Of course, if such a command is actually useful on some other
platform, that could be a good reason for keeping it.

 * (4) menu item labels use sentence capitalization

Because Marcel Proust was not wrong to entitle his chef d'oeuvre
« À la recherche du temps perdu ». He didn't capitalize {r,t,p};
I shouldn't be forced to capitalize {h,v} in "Tile Horizontally"
and "Tile Vertically".

In 'wxWidgets-2.8.7/include/wx/msw/wx.rc' most "Window" menuitems
are defined as msw "MENU" resources (though the "Previous" item
must come from somewhere else), and I suppose we could override
that. But we should make sure we don't favor that platform over
wxGTK, which is free.

 * (5) menu items can have help text and bitmaps

Other menus have help text; XRC makes it so easy. But with the
patch below, XRC <help> tags are displayed on the statusbar iff
no MDI child window exists. I wonder whether that has anything to
do with this comment in 'docmdichildframe_ex.hpp':

// The wx implementation of OnMenuHighlight() assumes that MDI child
// frames have statusbars, but that practice is uncommon, at least for
// msw, where typically only the MDI parent frame has a statusbar.

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

 + (6) "Illustration | Edit" disabled for child documents
       (corresponding accelerator Ctrl-E: likewise)
       (corresponding toolbar button: likewise)

The "child document" concept is described here:
  http://savannah.nongnu.org/support/?104485
and a child document can easily be created thus:
  alt-F N C
  Ctrl-R
Apparently wx already achieves every aspect of behavior (6), with
the patch below to suppress lmi code that otherwise obstructs it.
Without that patch, the toolbar button is disabled correctly, but
the menuitem and the accelerator both give this messagebox:
  Lmi_wx Warning
  That command should have been disabled.
  [file /lmi/src/lmi/illustration_view.cpp, line 135]

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