Menu Builder Woes?

[thatkeith]

Thanks Richard – the UG doesn't seem to say exactly the same here, but your words make more sense.

From the User Guide:
Next, you set the menubar property of your stack to the name of the group. This does two things: it displays the menus in the menu bar at the top of the screen, and it shortens the stack window and scrolls it up so that the group of menu buttons is not visible in the window. Since the menus are in the menu bar, you don't need to see them in the stack window as well.

Your quote (which I can't find in the UG but explains the actual behaviour better):
When menus are moved to the global OS menu bar only the stack size changes, not the card, so you can use the rect of the stack for anything requiring the apparent rect, or the rect of the card for anything requiring metrics for objects within the window.

My gripe is that the behaviour, even though documented (sorta) is definitely questionable. Okay, in my mind.
It's changing behaviour which should be out-and-out reliable: the rect of the card is not consistent, the height of the card is not the same as the height of the stack. This is WEIRD. It really feels like unexpected consequences of a workaround are being glossed over.

[BvG]

I agree, the menu system was hacked together willy nilly a very long time ago, and sadly none of the people with access to the source code ever cared enough to fix menus properly.

[FourthWorld]

Thanks Richard – the UG doesn't seem to say exactly the same here, but your words make more sense.

Thanks - I just submitted an enhancement request to include that in the menubar discussion in the User Guide and Dictionary:
http://quality.runrev.com/show_bug.cgi?id=11881

My gripe is that the behaviour, even though documented (sorta) is definitely questionable. Okay, in my mind.
It's changing behaviour which should be out-and-out reliable: the rect of the card is not consistent, the height of the card is not the same as the height of the stack. This is WEIRD. It really feels like unexpected consequences of a workaround are being glossed over.

The docs often use the phrase "scrolling the card" to describe what's happening, and that seems a good metaphor, allowing us to visualize the difference between the card and stack rects.

If all platforms worked the same it wouldn't be needed at all. Windows and Linux put menus at the top of the window, so it's just the ~10% using Mac who need special accommodation.

Personally, I find the LiveCode solution ingenious: it lets us build one stack for use on all platforms, which runs unmodified on 90% of them, and for Mac it takes care of moving the menu bar to the global menu bar for us automatically. I can't imagine how much more difficult it might be if we had to create a separate menubar object just for Mac, and manually handle the removal of the menubar from the stack when running on that OS.

As you spend more time with LC you'll find it handles other Mac-specific anomalies automatically too:

On all other platforms the About item is by convention the last item in the Help menu, Quit/Exit is that last item in the File menu, and Preferences is the last item in the Edit menu. On Mac, all three of those are in the application menu, which doesn't even exist on the other platforms. So once again, automatic accommodation to the rescue: just put those items where 90% of the world expects them, and LC automatically creates an application menu and moves those items into it for you.

This can be confusing at first, esp. to those who haven't spent much time on platforms other than Mac. But once you get the hang of it it's quite nice to have those generic things done for us, so we can just focus on the stuff that makes our app unique.

[thatkeith]

Hmm. I was going to include menus in the tutorial I'm doing now, but there are too many oddities going on for me to do that now. The core part of the project is a scrolling field that resizes with the window, plus a few other elements that slide along at the bottom of the window. Having to explain the resize issue and then the workarounds wouldn't exactly fill the reader with confidence – even if I had the room to go into that much depth.

Please don't get me wrong: I think LiveCode is simply *awesome* (with a capital AWESOME), but this menu behaviour introduces a weird inconsistency at a fairly basic level. I really hope it does get addressed at some point in the future.

[FourthWorld]

Hmm. I was going to include menus in the tutorial I'm doing now, but there are too many oddities going on for me to do that now. The core part of the project is a scrolling field that resizes with the window, plus a few other elements that slide along at the bottom of the window. Having to explain the resize issue and then the workarounds wouldn't exactly fill the reader with confidence – even if I had the room to go into that much depth.

If you use the card coordinates you don't need to think about the changing stack size, just write the code once and it should work everywhere. If you run into any snags post the code and we'll get you going in no time.

Please don't get me wrong: I think LiveCode is simply *awesome* (with a capital AWESOME), but this menu behaviour introduces a weird inconsistency at a fairly basic level. I really hope it does get addressed at some point in the future.

From time to time various alternative means of handling the Mac 10% have been discussed, but so far none of the proposals have been satisfying.

Any suggestions on how it could be handled differently in a way that would be easier to work with across platforms?

[thatkeith]

If all platforms worked the same it wouldn't be needed at all. Windows and Linux put menus at the top of the window, so it's just the ~10% using Mac who need special accommodation.

Heh. Fully understood, and I appreciate the problem it's tackling.

However, I wonder whether it would have been better approached by having the menu button group placed at -22px vertically from the card and leaving the card's 'scroll' alone. I'm sure I'm simplifying massively and misunderstanding stuff, but leaving the user's layout environment alone should be a top-level priority. Working on an OS-specific fix for just what's identified in the menuBar property would seem to me to be a much neater approach.

It isn't possible to scroll the card myself, is it? When I saw that mentioned in the User Guide I thought "bingo", but I don't seem to be able to do that myself.

once you get the hang of it it's quite nice to have those generic things done for us, so we can just focus on the stuff that makes our app unique.

Agreed. Although workarounds for shifting cards is also on my list of things I'd like to not have to do.

[thatkeith]

I have a field called "work" that I want to resize with the window. I've been doing this in a resizeStack handler, storing the height and with of the stack in handlers and then running this and similar lines:

Code: Select all

set the rect of field "work" to 0,0, theW, theH - 20

But everything shifts up. I know I can simply do slightly different math (and do this conditionally depending on what the menubar property contains), but as I said it does complicate explaining it to someone new.

Is there a way to set up the resizing-with-window behaviour so it works the same with or without a menubar set?

[FourthWorld]

If all platforms worked the same it wouldn't be needed at all. Windows and Linux put menus at the top of the window, so it's just the ~10% using Mac who need special accommodation.

Heh. Fully understood, and I appreciate the problem it's tackling.

However, I wonder whether it would have been better approached by having the menu button group placed at -22px vertically from the card and leaving the card's 'scroll' alone. I'm sure I'm simplifying massively and misunderstanding stuff, but leaving the user's layout environment alone should be a top-level priority. Working on an OS-specific fix for just what's identified in the menuBar property would seem to me to be a much neater approach.

It may be that I'm just pre-coffee, but whether the menus are placed -22 or the stack scrolls -22 seems pretty much the same thing, no?

After all, on most computers we'd still need to see those menus, requiring that we then invent some way to grow the stack for that 90% rather than shrink for the Mac's 10%.

Did I miss something? Coffee brewing only now...

It isn't possible to scroll the card myself, is it? When I saw that mentioned in the User Guide I thought "bingo", but I don't seem to be able to do that myself.

No, unlike SuperCard neither stacks nor cards have a scroll property. In LC there's a bit more flexibility than we used to have with SC: In SC we could make an entire window's content region scroll, but in LC we can do that or any smaller portion of it, or any number of smaller portions, by using groups.

once you get the hang of it it's quite nice to have those generic things done for us, so we can just focus on the stuff that makes our app unique.

Agreed. Although workarounds for shifting cards is also on my list of things I'd like to not have to do.

Respectfully, if it feels tedious I suspect there's a simple adjustment or two we can make to your scripts so it feels more with-the-grain. Feel free to post any troublesome scripts and we'll give it a go.

[FourthWorld]

I have a field called "work" that I want to resize with the window. I've been doing this in a resizeStack handler, storing the height and with of the stack in handlers and then running this and similar lines:

Code: Select all

set the rect of field "work" to 0,0, theW, theH - 20

But everything shifts up. I know I can simply do slightly different math (and do this conditionally depending on what the menubar property contains), but as I said it does complicate explaining it to someone new.

Is there a way to set up the resizing-with-window behaviour so it works the same with or without a menubar set?

If you define theH as "the height of this cd" it should work nicely.

[thatkeith]

It may be that I'm just pre-coffee, but whether the menus are placed -22 or the stack scrolls -22 seems pretty much the same thing, no?

The current behaviour seems to involve moving the entire card 22px up underneath the window title bar, whereas I'm wondering about moving the menu group itself up by that much so it is 22px above the top of the card.

Is what happens in Windows and Linux simply that the menubar group sits at the top of the card, taking up 22px of height - and in the Mac OS it doesn't? Or rather, to avoid having a blank at the top of the card on the Mac, the whole thing is shifted up?
It is a conundrum. I see how the current solution solves part of the problem, but it doesn't seem good enough to be an across-the-board answer. There may not BE a perfect answer, but I have to admit the '10%' argument, while logical, is putting even *me* off a little...

Did I miss something? Coffee brewing only now...

I should probably mention that I'm dosed up with cough mixture today. Nothing too heavy, but I'm probably (even) more likely to miss things myself.

[thatkeith]

If you define theH as "the height of this cd" it should work nicely.

Better, thanks, but the field "work" still slips under the window title bar. Hmm.

Code: Select all

on resizeStack
   put the height of this card into theH
   put the width of this card into theW
   set the rect of field "work" to 0,0, theW + 1, theH - 20
   set the rect of field "count" to 0, theH - 20, theW, theH
   set the bottom of group "options" to theH
   set the right of group "options" to theW - 30
end resizeStack

[FourthWorld]

0,0 is the topleft of the card, where the menu bar sits. 0,22 is probably what you're looking for.

[thatkeith]

Yep, exactly.
I'm not being dense (although I did just switch to nighttime cough mixture ) – I was wondering whether there was any alternative to saying "when you set up your menus you'll have to add 22 pixels to the top of objects that are placed near the top of the card or they will slip part-way underneath the window's title bar."

But you know what? It's probably more elegant than telling people to set up clickable buttons instead of the menubar thing! I'm a little sad about this area of inelegance... but I understand the reasons fairly well now (thanks!) and I appreciate that it does actually help with cross-platform development.

[FourthWorld]

Yep, exactly.
I'm not being dense (although I did just switch to nighttime cough mixture ) – I was wondering whether there was any alternative to saying "when you set up your menus you'll have to add 22 pixels to the top of objects that are placed near the top of the card or they will slip part-way underneath the window's title bar."

But you know what? It's probably more elegant than telling people to set up clickable buttons instead of the menubar thing!

I don't know what that means. In LC you can still have clickable buttons, but if you want a menu bar it's probably best to put it at the top of the window where users expect it, and put any other buttons below it.

I don't ever "add" anything extra - I just lay out my controls as I want them with the menu bar at the top where we would expect it, and as a bonus I get the menus moved to the global menu bar when it runs on a Mac.

Maybe I've just spent too much time moving between different OSes all the time, but to me this seems easy enough once the scrolling behavior is grasped; actually, somewhat marvelous in its simplicity.

I'm a little sad about this area of inelegance... but I understand the reasons fairly well now (thanks!) and I appreciate that it does actually help with cross-platform development.

It would be great if someone could come up with something even easier, and I'm sure it's possible, it just hasn't bee found yet.

When I first started using LC (back then it was MetaCard), coming from many years of exclusively-Mac work with SuperCard, I didn't like the menu system either. But as I spent more time with other OSes, I've come to appreciate that any menu bar solution can't work if it's for Mac only, that there needs to be a way to have them at the top of the window for the other 90%. I gave some thought to some means of making it more SC-like, in which menus have no relationship with windows at all, but I never managed to come up with anything that was as graceful for all the platforms LC runs on. Maybe you will. I look forward to seeing what you come up with.

[thatkeith]

I don't ever "add" anything extra - I just lay out my controls as I want them with the menu bar at the top where we would expect it, and as a bonus I get the menus moved to the global menu bar when it runs on a Mac.

And that, I think, is the key: laying everything out, including the menu buttons, right from the start. I've been coming at this from a Mac-only point of view, and that *does* make sense for much of what I do. But if I design for multiple platforms then menus have to be built right there in the window - so when the Mac version slides up the layout looks more Mac-like.

I'm going to deal with this by having people start by making the topleft resize value 0,22, so it'll Just Work when the menu is added. I'll also see how I can bring the menu building process earlier in the tutorial.

Thanks for your patience! Time to sleep now...