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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
