Re Pulldownmenu button bug on Windows

[Richard Gaskin]

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