Rev Menus [was Re: Location of stack]

[Richard Gaskin]

Jeff Massung wrote:

> On Mon, May 17, 2010 at 2:28 PM, Richard Gaskin
> <ambassador at fourthworld.com>wrote:
>
>>
>> I can think of no solution for adding something to a window in a way that
>> doesn't add it to the window.
>>
>>
> I can't think of way to eat a burger without eating a burger.
>
> Richard, I usually love your insightful posts... but that statement had me
> cocking my head trying to figure out what you meant.  ;-)

With the burger analogy I think you got it. :)

There are at least two issues involved in working with cross-platform 
differences with the menubar in Rev:  the content region and the window 
bounds.

Both can be dealt with effectively, neither as conveniently as I'd prefer.

When placing windows relative to each other or to system components 
(like the Task Bar), the stack's rect only reflects the content region 
and not the full bounds of the window (border and title bar).  On 
Windows, the full window size is affected by user-adjustable settings, 
requiring the scripter to dive into the registry to obtain the current 
ones in use.

When placing controls within the content region, as Rev is currently 
architected one can adjust them to the bottom of the menu bar in one 
line by just putting them in a group.

If we make handling the content region change more convenient, it still 
won't do a thing to address the other factor of total window size.  OSes 
are just different, and making good cross-platform appearances will take 
an extra few lines of code than they would if we were lazy.

Java ports to OS X commonly solve both sides of this with laziness: 
they just leave the menus attached to the top of the window. :)


> In all seriousness, though, this is 100% a solved problem and has been for
> *years*. REALbasic doesn't have this problem, and neither do the myriad of
> other cross-platform bits of middle-ware and languages.

I'm not familiar with how RealBASIC handles this, but I can see merit in 
a solution that uses the OS to render the menu bar for us into a portion 
of the window outside of the content region, as you suggest.

Not only would this simplify some aspects of internal layout, it would 
also make sure our menus are rendered with the correct font, size, and 
spacing for each OS.

Curiously, a brief search of the RQCC didn't turn up such a request.  If 
you have time to add one I think it would be helpful.


> The real problems here are (a) backwards compatibility (as Jacque noted) and
> (b) that Rev insists on emulating a menu bar as a background group of
> pull-down buttons instead of using whatever API is native to the OS and just
> making a menu bar. ;-)

It could be done in a way that also allows for backward compatibility:

In a system that lets the OS render the menu bar, we don't want to have 
to make individual buttons for each menu; those buttons have properties 
that aren't relevant to their role as pull-down menus, and it would 
simply be more conveniently have a list of menu titles and items 
assigned to a new stack property perhaps called a "menuSet", and let the 
system work out the font, size, spacing, background pattern, etc.

When a stack has a menuSet assigned, the older method of looking for a 
menu group would be bypassed and this new method invoked instead, which 
renders the menubar into a dynamically-created space between the content 
region and the title bar on Win and Linux, and into the menu bar on OS X 
as it does now.

By making this a new property, backward compatibility would be 
maintained: anyone wanting the older behavior can simply not assign 
anything to the stack's menuSet, and instead continue to assign a 
menubar group as they do now.  All current stacks would continue to work 
as they do now.


All that said, I see no harm in Jacque's approach of helping people 
better understand Rev as it currently exists.  It can be helpful to file 
a request in the RQCC, but once it's filed we're still where we are, and 
it seems most productive to go ahead and make the best use of the 
current architecture we have in hand than to wait for some future time 
when it might be changed.

Rev's menu architecture is not as convenient as some others in some 
respect, yet Rev must have enough other advantages or we'd all be having 
this conversation on a different vendor's list. :)

The overloading of the internal button class to also serve as menus may 
seem an odd choice today, but it made reasonable sense to Scott Raney 
when we wrote it and is not without a few niceties that we don't see 
commonly in other tools, like the ability to use stacks as menus so you 
have have pull-down galleries.

Sure, like most things in our imperfect world, Rev has many areas with 
some rough edges.  And being an imperfect world, once we work out an 
alternate solution and submit it to the RQCC, we also need a bit of 
patience in view of the wide range of other priorities the engine faces.

While less convenient than they could be ideally, there's little about 
Rev's menus that are seen as show-stoppers.  Personally, I'm willing to 
make the most of the menu system we have now in order to support the 
team's interest in prioritizing more thorough Unicode support and other 
enhancements for which I have no workaround.  As the wish list gets 
whittled down, perhaps there could be time for a major enhancement to 
the menu system.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv