Page 1 of 1

Dictionary error for Grab command?

Posted: Thu May 25, 2023 4:27 pm
by dunbarx
This came from an observation in another thread:
https://forums.livecode.com/viewtopic.p ... 99#p223499

The dictionary states:
You can only grab a control when the mouse pointer is within the control's rectangle at the time the mouse is clicked. I
Is this a literary bug? The grab command does seem to work if the pointer is a couple of pixels off the line graphic, on either side, but no more than about three. It certainly does not work within "...the control's rectangle..."

Perhaps it missed line graphics, and refers only to solid graphics, like a rectangle or circle?

Craig

Re: Dictionary error for Grab command?

Posted: Thu May 25, 2023 5:48 pm
by FourthWorld
Good catch. The more accurate word would be "region", which also reflects the terminology underlying the graphics primitives subsystem.

If they wanted to be really precise they for say "display region plus slop region", the latter part being the forgiveness area a few pixels beyond the actual displayed object, commonly used in hit testing with the pointer tool for the convenience of user interaction.

But that's probably a mouthful of trivia uninteresting to most readers. I suspect just replacing"rectangle" with "region" would suffice. :)


Fun trivia for Mac advocates:

Submenus are physically more difficult to use than primary menus, requiring the user to slow down and change mouse direction from downward to horizontal, being careful to remain close to both the primary and submenu, before resuming downward motion. This relative clumsiness is why the Mac HIG and others recommend keeping submenus to a minimum, avoiding them entirely wherever practical.

But have you ever felt that accessing submenus felt even more onerous on Windows?

That's because they are. By design.

And it's all about the slop region:

From the earliest days, the authors of the Mac Menu Manager were very sensitive to the inconvenience inherent in trying to access submenus, so they built in a generous slop region at the juncture where the submenu is drawn adjacent to the primary menu. It's an expanding trapezoid almost extending the height of the first menu item. This allows us to be several pixels off as we change navigation direction, giving the transition about an easy a feel as it could have.

The Windows design team apparently felt different. If you pay close attention to each, you'll see that the Windows slop region for accessing submenus is much smaller, far close to a rectangle then an expanding trapezoid, requiring slowing down much more and moving the mouse with greater precision.

Whether that choice stems from a desire to be more precise, or just weaker user testing methodology, only those who were in the room at the time it was decided can say.

All we can know is that accessing submenus on Mac not only feels less uncomfortable, but the underlying reason can be measured.

Of course all this became far less of an issue when all the OSes standardized on persistent drop-down, where we no longer need to keep to mouse button pressed to keep the menus rendered.

But if you're a Mac snob, you often have good reason to be. There are many details like this that distinguish the two platforms.

Re: Dictionary error for Grab command?

Posted: Thu May 25, 2023 7:09 pm
by stam
Is this slop region editable? if so, it would be the natural response to the thread Craig points to.

But to this thread: I am accustomed, as a long-term Mac user, to some minor forgiveness in the accuracy in exactly where you click and thanks to Richard for explaining this is by design and promoting Mac-smugness!

Given that for all intents and purposes knowing the actual rect of a control has no meaning influence of where the user actually clicks it seems a little bit academic anyway. I think we all understand that the dictionary means you have to click on the border or (if exists) the content of a control to grab it. If your OS allows a bit of flex, then great!

Re: Dictionary error for Grab command?

Posted: Thu May 25, 2023 7:25 pm
by richmond62
My last example, with an underlying image, can be adapted so one can be as sloppy as one likes.

Re: Dictionary error for Grab command?

Posted: Thu May 25, 2023 7:35 pm
by richmond62
And, what's the 'region' round something on a Linux distro, and is that desktop environment dependent?

Gnome
KDE
XFCE
LXDE
Cinnamon

Re: Dictionary error for Grab command?

Posted: Thu May 25, 2023 8:13 pm
by FourthWorld
stam wrote:
Thu May 25, 2023 7:09 pm
Is this slop region editable?
Not in LiveCode, and anyone working in a lower-level language rarely has any reason to even think about it, as the OS APIs handle that for us in most cases.

The LC engine, using Skia for its graphics primitives rather than OS-specific routines, probably does manage that itself, but in C++. That is, for object selection with the pointer tool; the submenu business I described earlier is baked into what used to be called the Menu Manager (now part of the Cocoa framework), and there's rarely any need for a developer to override it.

It's possible that LC could add a way for users to define regions using polygons, and set the hit test boundary to it, but that would be a non-trivial effort with little upside.


More fun Mac trivia:

Calculating regions is far more complex than calculating rectangles, as you might guess. And with Macintosh OS 1.0, there was very little CPU power and RAM available to do it efficiently.

Knowing that, here's a tale of Bill Atkinson's work in creating the first region calculations in the QuickDraw subsystem:

https://www.folklore.org/StoryView.py?s ... =QuickDraw

Re: Dictionary error for Grab command?

Posted: Thu May 25, 2023 8:19 pm
by FourthWorld
richmond62 wrote:
Thu May 25, 2023 7:35 pm
And, what's the 'region' round something on a Linux distro, and is that desktop environment dependent?
I haven't spent as much time doing lower-level work on Linux as I used to do on Mac, so while I can guess on some things from my reading Linux System Programming (a fun adventure tale), it would be only a guess.

Hit-testing is likely part of the GTK libraries, so the best I could offer for that would be to dive into that source and its documentation in event handling.

Regions in general may be part of GTK, but more likely part of the underlying renderer, formerly XWindows and currently Wayland. But I'll admin the relationship between Wayland and GTK is not one I've had much occasion to explore, so if you go hunting take a pith helmet, a machete, and a snack - you may be exploring for a while.

Re: Dictionary error for Grab command?

Posted: Fri May 26, 2023 10:57 am
by richmond62
Might there not be a way to detect the grabble region inwith LiveCode?

Re: Dictionary error for Grab command?

Posted: Fri May 26, 2023 2:49 pm
by FourthWorld
richmond62 wrote:
Fri May 26, 2023 10:57 am
Might there not be a way to detect the grabble region inwith LiveCode?
Interactively. :)

Re: Dictionary error for Grab command?

Posted: Fri May 26, 2023 6:11 pm
by jacque
dunbarx wrote:
Thu May 25, 2023 4:27 pm
The dictionary states:
You can only grab a control when the mouse pointer is within the control's rectangle at the time the mouse is clicked.
Is this a literary bug? The grab command does seem to work if the pointer is a couple of pixels off the line graphic, on either side, but no more than about three. It certainly does not work within "...the control's rectangle..."
A few releases ago, LC changed how line graphics can be selected. The release notes just say he made lines easier to select. The dictionary wasn't updated, maybe because the change was so minor and only applies to lines.

Re: Dictionary error for Grab command?

Posted: Fri May 26, 2023 6:17 pm
by richmond62
Where is that change documented?

Re: Dictionary error for Grab command?

Posted: Fri May 26, 2023 7:32 pm
by FourthWorld
richmond62 wrote:
Fri May 26, 2023 6:17 pm
Where is that change documented?
Probably in the Release Notes with all the others.

Re: Dictionary error for Grab command?

Posted: Fri May 26, 2023 7:58 pm
by jacque
I can't remember which LC version the change happened in but it wasn't very long ago. Maybe 2-3 releases ago. And as I said, "in the release notes."