Re Pulldownmenu button bug on Windows

Tue May 10 15:50:54 EDT 2022

What a very kind thing of you to say. Thank you.

After 30 years as a recipient of so much wisdom and lore shared with me, 
I've felt compelled to share some of that forward. In recent years most 
of what I write seems ignored, so I've been spending my time elsewhere. 
Your encouragement may see me checking in on LC stuff more often. Thank you.

--
  Richard Gaskin
  Fourth World Systems

Craig Newman wrote:

> 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 at 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 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
>>> 