Ruby Windows Consume Keystrokes When Focused - Focus Does Not Follow Mouse

[DanRathbun]

SketchUp Ruby API Issue

Ruby Windows Consume Keystrokes When Focused - Focus Does Not Follow Mouse

SketchUp Version: 2023 and older versions Platform: MS Windows - not sure about Mac

Reported focusing issues:

(1) It has come as a surprise that Ruby dialog windows consume keystrokes that the user intends to go to the main application window, for example to activate another tool.

(2) At least 1 user desires that the focus within SketchUp should follow the mouse cursor.

Ref public forum post:

https://forums.sketchup.com/t/sketchup-2023-selection-problem/226053/4

Glenn M. Stanton said: ... if i have the DC options or DC attributes window open, trying to select the object and move it (for example), it keeps bouncing back to the window, so i have to try it 3-4 times before it releases me. if i close the DC window, then it’s all good. so definitely something wrong with the semi-modal window.

~

[thomthom]

I'm not able to reproduce this. The Move and Rotate cursors appear fine regardless if I have Dynamic Components or Transformation Inspector open.

[gullfo]

if i have my DC options window open and selected (as if i just edited it), then press "M" to move the component, nothing happens. previously (SU 2022), doing this, the cursor would become the move cursor. now, if i manually select the component (meaning the DC window is no longer in focus), then the "M" key works as expected.

somewhere in the UI the keystrokes for commands are being consumed when the window is in focus.

window select - press M - nothing

component selected (window not focused) - press M - works as expected

sorry - the cursors are not showing up in the images, but they act as described.

i'm running W11 Home 22H2 22621.1485 and SU Pro 2023 23.0.397

[DanRathbun]

Re (1) ...

@gullfo ... somewhere in the UI the keystrokes for commands are being consumed when the window is in focus.

This is intended behavior as windows that have edit controls consume the keystrokes. Normally one of the controls or buttons in a child window interface (messagebox, inputbox or html dialog) gets the initial focus for keystrokes.

If in past versions it did not and SketchUp received the keystrokes when a dialog had focus, then this would have been a bug and extension developers would definitely have complained about SketchUp "stealing" keystrokes from their extension dialog windows.

[gullfo]

true but if i move my mouse off the dialog (and it's not modal) and press the M key (e.g.) i would expect my tool to be selected rather than having to close a non-modal window or reselect the object to get control. i understand from a dev perspective the dialog is all, but if its not modal then focus is (or should be) based on my cursor position at the very least. the other issue (and i think the Medeek plugins are experiencing it) is losing focus and not being able to actually use the dialog - and maybe this is a separate issue but alt-tabbing only marginally gets around this.

[DanRathbun]

i understand from a dev perspective the dialog is all, but if its not modal then focus is (or should be) based on my cursor position at the very least.

Mouse position is not the definition of focus. Perhaps web interfaces work this way, but not traditionally Windows desktop interfaces. For the past 40 plus years we MS Windows users have always had to explicitly give a window the focus with a click or ALT+TAB, etc.

But it is not hard and fast. For example scrolling does work on mouseover on windows that do not actually have focus. I think this mixture of behavior may lead to confusion.

What you are advocating would mean that the mouse cursor would need to always be within a dialog / child window to use it. But if this is how you would like to work, then I'd not be against an option in SketchUp's Preferences for "Focus Follows Mouse". But it would need to be a personal Preference setting not the default.

[gullfo]

i'm thinking if i'm editing the dialog then it has focus, as well as when my mouse is over it. otherwise don't consume my tool command key if i not editing (e.g. i edit something in my DC dialog, then hit enter, now i'm not editing) i move my mouse off the window and press M, the tool is enabled. or even enabled if i don't move off it, but giving the dialog preference if i'm still considering working in it (like clicking to edit another field). but agreed, doesn't have to be default behavior but certainly an option for folks who do quick edits and then need to move things... :-)

[DanRathbun]

... (e.g. i edit something in my DC dialog, then hit enter, now i'm not editing) ...

But the HTML engine in use has moved focus to the next control on the page (or in the form.) TAB also does this. It cannot know that "in your mind" that you have decided that you are done editing.

Now a developer of a Html dialog can probably code an "escape" listener that either when the mouse leaves or when a certain key is pressed will call a Ruby callback method which executes Sketchup.focus. But it would likely need to be done deliberately by the developer.

It is not likely that the Trimble SketchUp Team will want to make any more changes to the DC extension. This comes from their continued ignoring of DC bug complaints and pleas for added DC features. (They've decided to put their money and time into Live Components.)

I'm not sure I can come up with a hack to fix the DC dialogs or all WebDialogs ... perhaps I'll need to think on it. I might be able to inject an onMouseOut/onMouseLeave listener that gives the SketchUp application window the focus. But I don't know if I can do the opposite cross platform. I again I'll need to think on it.

[gullfo]

or leave the option to use the "broken" version so things operate like they do in SU 2022... :-)

[DanRathbun]

I am on Win 10 and SU 22.0.1 works the same as SU 23. I have it open right now and tested it.

In fact it works the same as SU 21, etc.

When any child window has the focus, it consumes keystrokes. Pressing M or any other shortcut does not (and should not) "bubble up" to the application. Whatever the current tool is remains the active tool.

... if i have my DC options window open and selected (as if i just edited it), then press "M" to move the component, nothing happens. previously (SU 2022), doing this, the cursor would become the move cursor.

Do you have 2022 still installed ? What version ?

SketchUp v22.0.1 Release Notes:

• (Win) Fixed an issue where keyboard input into an extension window would activate shortcuts.

Trimble is NOT going to undo a fix for a bug that only inadvertently occurred in one release.

What you describe is a "hiccup" in SketchUp history. It's over and done with. Most of us have happily moved on.

[gullfo]

i'm good with fixing issues where i'm entering information into a dialog and not having the tools all switching around etc. and its not only the DC dialog but also the model info dialog etc which if its open and recently focused, makes my ability to rapidly do things with tools and so on harder because i have to click on the component again to tell the app i'm not focused in the dialog, or close the dialog, so i can switch tools etc. so if this is the fix, i'll just have to learn to close any dialogs before attempting to return to the object i'm working on.

[DanRathbun]

It not that it is a "fix" ... it has always been thus with Windows child windows that have focus, in any application. (The "clunky" switch to the Qt framework for SU2023 introduced quite a few nasty focusing issues, some of which have not yet been corrected.)

There is a MS Windows system shortcut to close any window with focus ... ALT+F4

However ... most of the SketchUp non-Ruby child windows will close via the ESC key. This includes:

• Ruby Console
• Model Info
• Preferences
• Toolbars...
• About SketchUp
• Manage Trays...
• Print Setup
• Print Preview
• and the SaveAs, Import and Export dialogs
• message boxes

Windows that do not (because they are Ruby windows):

• Welcome to SketchUp
• Extension Manager
• Extension Warehouse
• 3D Warehouse
• Generate Report

In HTML forms within Ruby windows the ESC key usually has another purpose, which is to abandon the current edits for the control that has the focus.

[DanRathbun]

Re (1) - Works as intended. Child windows with focus consume keystrokes.

• The inadvertent bug in release 23.0.0 was fixed in release 23.0.1

Re (2) - "Focus Follows Mouse" would be a feature request.

[gullfo]

thanks Dan. just after using SU for 20 years now, and having the UI behave the way it is behaving, is annoying and time consuming. hopefully the upcoming updates will handle whatever other UI etc behaviours are left.

[DanRathbun]

just after using SU for 20 years now, and having the UI behave the way it is behaving, is annoying and time consuming.

Sorry about this. But it is how MS Windows is designed and worked for going on 37 years now.

But your "focus follows mouse" desire is a feature request for the core GUI. I would encourage you to open a topic in the public forum's SketchUp > Feature Request category.

[DanRathbun]

I've recaptioned this issue to be all about dialog keystroke consumption and a future focus follows mouse feature.

I removed mentions of the core issue regarding native tool cursors as it detracted from the main discussion of window focus.

---

So with regard to focus following the mouse, I have been working on a "hack" of the UI::HtmlDialog and UI::HtmlDialog classes that will add "Focus Follows Mouse" functionality to Ruby dialogs. It's sort of a superclass shoehorning hack.

Anyway, there are still a few things to overcome.

(1) If the mouse is moved out of 1 dialog and into another very quickly, the JS events fire out of order and the mouseenter of the 2nd dialog fires before the mouseleave of the first dialog. This results in SketchUp getting the focus even though the cursor is within the 2nd dialog (which should have the focus.) If the mouse movement is slower then focus is correctly given to the 2nd dialog. (Ie, focus properly shifts from the 1st dialog to SketchUp then to the 2nd dialog.)

(2) If remote URLs are loaded and then the user navigates to another remote webpage (or is redirected,) the focusFollowsMouse JS object will not (yet) likely get injected into the new webpage.

(3) If the user manually switches to another application, either via mouse click or ALT+TAB, then moving the mouse back into SketchUp and over a Ruby dialog will not refocus SketchUp or the dialog (even though Sketchup.focus is called.) This is a Windows security feature to try to prevent malware. What happens is the SketchUp taskbar icon will flash to let the user know that the application "wants" focus. It is up to the user to manually give focus back to SketchUp. What happens in this case before SketchUp actually regains focus is that the dialogs get confused over what has focus. I'm not sure that (3) can ever be "fixed", unless we get a AppObserver callback to know when the SketchUp application loses focus (onBlur) and regains it (onFocus).