Menu woes

Ben Rubinstein benr_mc at cogapp.com
Thu Dec 30 18:56:03 EST 2004


I think there a bunch of different issues wrong (or in some cases, right but
not right for everyone) with how Rev handles menus, and have in the past
tried to describe a completely new architecture that could be introduced
without breaking compatibility at all, and addressing most of these at a
stroke.

But in practise, they are to a large degree separable.  The issue with stack
resizing is completely unrelated to the issue with moving menuitems around
between platforms; neither are related to the problems with metachars and
the limitations on menu decorations and shortcuts.

Ideally I would like it to be possible to define menus, instead of by
buttons, through some other properties/structures/objects that don't have a
position on a card.  Given such a system, it would be an opportunity to
break out of the resizing issue without losing compatibility.  However, I'd
really like to see the resizing issue fixed, and it can be fixed without
creating a new way of defining menus.

On the resizing issue which started this thread, I have torn out a lot of
hair, and wasted a great deal of time, on this one topic since I first
started working with MC/Rev.

- I agree with those who believe that documenting the strangeness is a
sticking plaster, and not an adequate alternative to fixing it; I have the
greatest respect for Jeanne's documentation, but setting up simple menus
should be straightforward, and in a tool like Rev it's not good enough to
say that when people trip over it they should eventually be able to find an
explanation for the behaviour.

- I believe I have come to an uneasy peace with the behaviour - but still
sometimes get caught; but I have to be careful not to disturb the peace, and
I don't think that Richard's suggestion that we should embrace the fear and
treat it as a learning experience addresses this.  When I want a learning
experience I'll use assembler; I use Rev because I want to find a highly
polished solution in the least amount of time.  Rev is so powerful that very
complex applications can be created remarkably quickly; in that context
screwing around with (or getting screwed around by) the menu madness can
quickly distort a project budget, as I know to my cost.

-  I don't think it's acceptable to say "in time you'll learn to define
menus before you do anything else" - that's a workaround.  Every other
aspect of the stack can be modified at will at any time in the development
process - and so can this, you just fall over the undesirable behaviour when
you do. 

In addition, there have always been bugs related to the resizing behaviour.
I'm given to understand that some of them have been there for ten years.  I
also know that new ones arise because of it - for example when metal support
was added on OS X.  And it creates another layer of gotchas for scripts such
as geometry or layout managers (and doubtless lots of other scripts).

Specifically on the resizing issue, it occurs on the Mac, because the scheme
requires the menus to be defined (as placed objects) in an area where for a
simple cross-platform case, it shouldn't exist on Windows.  I think that the
solution adopted was ingenious, but wrong - possibly a historical accident.
I'm guessing (I've no idea if this is true) that Metacard was originally
developed on some non-Mac platform, and existed there for some time before a
Mac engine was developed.  Thus it seemed like menus could be handled simply
by placing objects on the card, in a row at the top, which would have been
the least effort to implement, given that drop-down menu controls would in
fact be supported anywhere on the card.  Then when the port to Mac was made,
there was a hack to copy these menus into the system menubar - and scroll
the card up to hide them in the stack window.  Existing stacks would port to
Mac without any effort, and perhaps everyone cheered at this neat solution.

But I think that if one started from the beginning with the requirement to
support a menubar, which might appear at the top of the screen on Mac, at
the top of the parent window of an MDI app on Windows, or on at the top of
the stack window in other cases, one wouldn't start from there.

My suggestion is that if asked to make a group of menus (however that is
defined) be the menubar on Mac, that should happen in the obvious way, with
no resizing or scrolling; if (as they must be at present) the group of menus
are defined by a group of buttons, and the developer doesn't want them to be
visible, they can be hidden; there's no need to scroll the card to move them
out of sight.   On Windows or other platforms (I'm guessing the *nix GUIs
work like Windows, but I know nuffink) if a straightforward menubar is
required, the engine should draw this under the titlebar, before drawing the
stack.  In other words, the engine creates a menubar - obeying the user's
settings for menu size and styling - outside the 'content area' as seen by
the stack.

I suggest that all that is needed to implement this without losing
compatibility is some new stack properties
    macMenubar
    winMenubar
    ...etc

On Mac, if a stack has the 'macMenubar' set (and the 'menubar' empty) then
the system menubar is set as you'd expect, copying the definition from the
specified group (and there is no scrolling or resizing).

On Windows, if a stack has the 'winMenubar' set, then a menubar defined by
the specified group is displayed under the titlebar of the window, before
the content area starts.  There is no scrolling or resizing, all coordinates
are the same as they would be if the 'winMenubar' property is not set.  The
window itself may change size, but your stack knows nothing about the window
outside of the content area in which it is displayed - how big the titlebar
is, how wide the borders on each side, all of which can be adjusted by the
user - it doesn't need to know anything about the menubar and how it works.

On other platforms... err, I guess it's like Windows, but I don't know.
Maybe someone else can fill in.

The advantage on Mac would be that there is no resizing issue.  The
advantages on Windows would include supporting the user-defined appearance
settings which are currently ignored, and being a step closer to the
possibility of MDI apps.  A general advantage would be a mechanism that
makes it equally simple to have menubars on different platforms defined by
the same group, or different ones.

If a developer wanted to do something custom with the menubar on Windows -
like Chipp in this case - they could simply leave the 'winMenubar' empty,
and handle their menus as they do now.  On the Mac in that case, they might
hide the relevant group in a preOpenX handler.

Overall, the advantage is that simple things - a straightforward menubar -
would be simple, even if some more complex effects might be more complex.
That seems like the right way round.  And the change could be introduced
without any compatibility issues; existing stacks which set 'menubar' would
not set 'macMenubar' or 'winMenubar', and hence would get the existing
behaviour.  (I'd hope that documentation and IDE menu development assistants
would push the new scheme and deprecate the old, and hence new users should
never encounter the problems that we all have in the past.)

I'd be really interested in comments on this scheme.  I've shied away from
entering enhancement requests bugzilla about menus because I want so much.
But I actually think this could be quite a small request, and realy helpful;
so I'd like to know whether other people think it makes sense, and how it
could be improved.

  Ben Rubinstein               |  Email: benr_mc at cogapp.com
  Cognitive Applications Ltd   |  Phone: +44 (0)1273-821600
  http://www.cogapp.com        |  Fax  : +44 (0)1273-728866



More information about the use-livecode mailing list