Well put. I wonder what the real world effect of the order of messages is, and whether or not it could be compensated for by send in time?
Sent from my iPhone > On May 7, 2022, at 13:44, Richard Gaskin via use-livecode > <use-livecode@lists.runrev.com> wrote: > > It's definitely an inconsistency, but the bug's status as requiring "EXPERT > REVIEW" prompts us to consider why these differences exist, and which, if > any, should be considered "wrong" or "right". It may not be as simple as it > seems at first glance. > > > Background: > ---------- > MetaCard (the engine we now call LiveCode) was born on Unix, later ported to > Windows, Linux, and then MacOS. > > On all platforms menus are implemented as selector buttons, buttons which > provide the appearance and behavior of OS-provided menu objects. > > And until the port to MacOS, all platforms behaved consistently. > > So why the Mac change? > > Mac is unique among popular GUI OSes in its use of a global menu bar, > attached to the top of the display; other OSes place the menu bar attached to > the top of the window. > > Internally, LC menus are implemented as temporary dynamically-instantiated > nameless stacks, which may seem counterintuitive until you realize that a > menu is in essence a highly specialized form of window, a viewport > independent of other windows with its own buffer, contents, and like all > windows needs to use a common compositor for rendering them all together. > (Indeed you can even use stacks as menus explicitly when you need a > non-standard look, like a graphical picker, but that's another topic). > > So the engine's method of using a subclass of the stack object for rendering > menus worked well and consistently for a great many years - until the port to > MacOS. > > The Mac global menubar required a deep rethink on how menus are handled, not > only in terms of detaching them from the window but also in terms of the > nuances of display and interaction. > > So Dr Raney special-cased menus on MacOS, so the engine uses OS routines to > render those, fed by the menu button properties for things like the menu name > as parameters to those OS routines. On every other platform you're > interacting with a LiveCode object, but on Mac you're interacting with a > system object into which the engine has inserted some hooks to tie it in with > your scripting so you can at least know when an item has been selected. > > This rewiring of properties and messages is no small feat, and has pervasive > effects. So from time to time you'll find Mac-specific things needed to > conform to that platform like adding an "About" item to a menu that doesn't > exist in your stack (the Mac's "Application" menu belongs to the OS). > > It's not surprising that messages related to menu objects also have some > inconsistencies along with everything else. > > If we consider that on all other platforms the menu object we're interacting > with is a button, and the menus that appear are a stack, the messaging you > see with Windows and Linux is consistent with other button object messaging: > once the mouse leaves the control the mouseLeave message is sent. > > On Mac we have an exception to LC's normal button messaging because we're not > interacting with an LC button at all, but with a system object, into which > the engine devs have grafted just enough messaging to trigger actions from > scripts. > > I have no opinion on qualitative labels like "right" or "wrong" on this; that > seems a matter of personal familiarity and taste. It may even be somewhat > philosophical: is a menu a single thing that expands, or two things (menu and > items) where one triggers the appearance of the other? > > All I can do is help describe the under-the-hood parts to help makes sense of > how the difference came about. > > > > The Here-And-Now: > ---------------- > Whether or not we prefer it, the menu architecture is what it is, at least at > the moment. Changing the behavior on all other platforms to be like Mac, or > Mac to be like all other platforms, would be a scope of work that I'd guess > the team would not be in a position to make a priority any time soon, even if > they felt strongly about this one way or another. > > They have a lot on their plates, and for all the questions we see regarding > Mac-specific menu differences (like the auto-migration of the "About", "Help" > and "Preferences" items to system menus separate from the menu objects where > we're asked to put them), I can't recall seeing a message here before about > mouseLeave. > > I'm not saying it isn't important. It might well be. But observably this > affects few; AFAIK this is the first such request in the 23 years I've been > using this engine and participating in its communities. Just the same, let's > roll up our sleeves and see what can be done: > > > > Looking Forward: > --------------- > Edge case or not, let's see what we can do to get a solution for you sooner > than the engine team would be able to even thinking about revisions as > sweeping as would be needed to satisfy the engine request. > > What do you need from mouseLeave during a menu drop? What are you doing in > response to that message? > > There are some clever people on this list. I'll bet we can find a solution > for your need once we more fully understand the goals. > > -- > Richard Gaskin > Fourth World Systems > > > > Neville Smythe wrote: > > The pulldownmenu bug I reported has been confirmed: bug 23693 > > <https://quality.livecode.com/show_bug.cgi?id=23693> > > > > To remind the reader: On a Mac, when a user select a menu item from > > a pulldown menu button, the menuPick message is sent first followed > > by a mouseLeave message (generated as the mouse leaves the button > > rect to select the menu item). On Windows, the mouseLeave is sent > > immediately, followed by menuPick. > > > > The Mac order is correct, the mouseLeave should be delayed until the > > displayed menu is dismissed. > > > > Linux has the same incorrect behaviour as Windows. > > > > The same situation applies to popupmenus and option menu buttons: > > the Mac has the correct order, Windows and Linux incorrect. > > > > However for the combobox button, all three platforms give the wrong > > message order! > > > > And one last twist, although the Mac implementation gives the correct > > order for 3 menu buttons, it sends the mouseLeave message twice, once > > immediately after the menuPick, and then again when the mouse is > > released. > > > > Neville > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
