On May 7, 2022, at 13:44, Richard Gaskin via use-livecode <use-livecode at
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
