Richard. So glad to have you in this world.
Craig > On May 7, 2022, at 5:35 PM, Bob Sneidar via use-livecode > <use-livecode@lists.runrev.com> wrote: > > 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 _______________________________________________ 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
