GNOME Bugzilla – Bug 646506
give visual feedback of while holding ctrl (to launch new instance)
Last modified: 2021-07-05 14:16:42 UTC
You can ctrl-click to launch a new instance of a running app (and hopefully you'll be able to ctrl-enter soon; bug 635501) but you don't get any visual feedback. It would be nice if the there's-an-instance-already drawing would change for the hovered-over item (or the best-match/default item if none hovered) while ctrl is held.
Whoops, that bug/link was supposed to be bug 613082.
We should at least change the pointer icon to have a plus mark when it is hovered over an running app and ctrl is held down.
I'm looking into this and should come up with a patch relatively soon.
I've looked into several approaches towards implementing this behavior but am now somehow stuck between them. The affected class is AppDisplay.AppWellIcon. It is used in Dash as well as in SearchResults which originate from AppSearchProvider. First way, initially implemented for AppWellIcons in Dash, is to catch enter and leave events on the AppWellIcon, set key focus on them when this occurs, and then wait for the Control button to be pressed. This works for icons in Dash, but the problem is taking the key focus. This ruins current design and is also a bit desperate IMO. This approach also fails when AppWellIcon is placed in SearchResults. Search entry should keep the key focus so the search could be updated/restarted or just to move around search results. The AppWellIcon taking the focus is really messing this up. The second and in my mind a more elegant way is to put a key press handler in Overview, looking for Control key presses. If they occur, we check if the actor's delegate is an instance of AppWellIcon and then indicate through that actor that on activation, a new window would be created. The problem is that currently there aren't any cases in the GNOME Shell's JavaScript code of acquiring the actor currently under pointer. The Clutter-equivalent function would be clutter_input_device_get_pointer_actor. Is this method even acceptable? So, to sum things up: - I don't want to set key focus on the AppWellIcon, it can backfire - The best place to catch for Control key press seems to be Overview, the event would then indirectly affect the actor under pointer (if actor's an instance of AppWellIcon) What I'd like to hear are some comments, suggestions and thoughts about the problem, especially doing the whole actor-under-pointer shenanigans.
Noticing that ctrl is pressed does not require grabbing keyboard focus. All mouse events carry a state field that contains the current modifier state.
(In reply to comment #5) > Noticing that ctrl is pressed does not require grabbing keyboard focus. > > All mouse events carry a state field that contains the current modifier state. I understand this, but as said, all the mouse events ... this requires further mouse movement after Ctrl key has been pressed. I don't think only checking for the modifier state would present a complete solution.
The other tricky thing about this bug is knowing when it is possible for the app to open a new window - it isn't universal.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.