Regression for lxqt-runner: no focus if not clicked by mouse #1653
Comments
|
Just wanted to add that lxqt/lxqt-runner#277 doesn't have any problem in labwc 0.7.1 — I'm using them — and just sets the layer at the top. |
|
We've made quite a few changes to layer-shell keyboard-interactivity recently (#1599). I do really appreciate you reporting this, because there isn't much 'standard implementation' to go on and the protocol is quite vague on on-demand handling. I have taken "Request regular keyboard focus semantics" to mean that the surface gets focus when receiving mouse-button-press, but not whenever the surfaces changes its keyboard-interactivity to 'on-demand'. I'm quite happy to revert 6990ff7 because I think it's highly likely that the only time a layer-shell surface changes its interactivity to on-demand is on map (or shortly after). The only consideration I can think of before reverting is that this means that any layer-shell client with on-demand interactivity will 'grab' the keyboard when started (assuming that's when it sets the interactivity to on-demand, which is most likely the case). Appreciate help in thinking through if there are cases when this is not desirable... to avoid chasing our tail on this one. As a side-note, I'm in the process of creating a In terms of the described issue, please could confirm:
|
lxqt-runner starts hidden. It's made visible by a shortcut and gets hidden when it launches an app, or when its Qt window gets inactive (e.g., by clicking into another window), or when Escape is pressed. The problem with git labwc happened every time it was shown: no focus, unless the user focused it by clicking into its window. With labwc 0.7.1, it's focused when shown, as expected.
According to @stefonarch's tests, "exclusive" didn't make a difference (sorry, I can't test now, using the latest stable labwc). The code is a simple layer-shell-qt code like this; layershell->setLayer(LayerShellQt::Window::Layer::LayerTop);
layershell->setKeyboardInteractivity(LayerShellQt::Window::KeyboardInteractivityOnDemand);
LayerShellQt::Window::Anchors anchors = {LayerShellQt::Window::AnchorTop};
layershell->setAnchors(anchors);
...EDIT: The original code uses "on-demand", as above. |
Yes (although I edited my above comment to emphasize that it does). The problem with git labwc is that it doesn't get focus automatically when shown. |
|
Lets not revert 6990ff7. But maybe the logic isn't right, the comment states that A Basically the question is if a newly mapped client with ON_DEMAND set should get focus or not. Just mapping and then requesting ON_DEMAND after the fact (e.g. when it was the default NONE before) would be correct to not give keyboard focus, you'd need to change to EXCLUSIVE for that.
Is this still the case? |
Consolatis
added
bug
If EDIT: made a test run still with
I don't use other launchers like wofi or rofi, how do they handle show/hide? |
|
Interesting. Exclusive + top layer should always give you keyboard focus unless there is some other layershell client with exclusive. So maybe this is about a map / unmap / map cycle of a layershell surface. A |
|
I did the following, got a quite big file:
|
|
Edit: |
|
Ooops, sure. Here a more compact log. |
EDIT: looks like with "Exclusive" it's working now, not sure why it didn't yesterday. |
Alright, the log looks clean otherwise. (
|
|
Does this fix it with diff --git a/src/layers.c b/src/layers.c
index a18bc4fa..5d863dc1 100644
--- a/src/layers.c
+++ b/src/layers.c
@@ -348,6 +348,8 @@ handle_map(struct wl_listener *listener, void *data)
* Processing of keyboard-interactivity changes is done in the
* commit-handler.
*/
+ layer_try_set_focus(&layer->server->seat,
+ layer->scene_layer_surface->layer_surface);
}
static void |
It does, but I need better triple testing ;) |
Sweet, thanks for confirming. Thoughts @johanmalm ? Note that this might also apply for use-cases like notification daemons (usually in top or overlay layers) when they use |
If something like pcmanfm was giving focus would that make it show up in the window switcher |
The desktop of git pcmanfm-qt doesn't show up in switcher. It's completely ready for Wayland. EDIT: I mean pcmanfm-qt's desktop; its windows are normal. |
|
layershell clients generally don't show up in the window switcher (or in panels using the foreign toplevel protocol). |
|
I know a layer-shell shouldn't show up, but I have no idea how well implemented qt's version is. |
...for the following reasons: 1. We interpret 'normal input-focus semantics' for clients with on-demand keyboard interactivity to means that a surface receives input focus on cursor-button-press AND on map (the latter previously missing), just like a normal window would. In this regard, we do not differentiate between layers. 2. Most layer-surfaces set the keyboard interactivity at a similar time to their first (and normally only) map, so the absence of an explicit attempt to focus on map does not make a difference. However, for a long-running layer-shell client (such as lxqt-runner) which sets the interactivity on launch and then maps/unmaps many times throughout its lifetime, a specific focus-attempt is required on map to avoid the client itself having to keep resetting its interactivity to grab the keyboard on map. 3. Compositors like sway and river process focus (for clients with keyboard-interactivity) in their map-handlers, so this makes for a common approach. Fixes: labwc#1653
My mind was heading towards the map-handler too last night. Thanks for patch + testing. See #1656
I'm pretty easy on this, have taken your patch as is based on the fact that if we're applying 'normal input-focus semantics' to mean mouse-clock or map, then it's more consistent to not differentiated between layers. If a desktop client like
Agree. Hope we don't break something else with this. I checked sway+river map-handlers and they both try to focus if the client has keyboard-interactivity (which includes on-demand), so adopting the same approach seems sensible. |
...for the following reasons: 1. We interpret 'normal input-focus semantics' for clients with on-demand keyboard interactivity to means that a surface receives input focus on cursor-button-press AND on map (the latter previously missing), just like a normal window would. In this regard, we do not differentiate between layers. 2. Most layer-surfaces set the keyboard interactivity at a similar time to their first (and normally only) map, so the absence of an explicit attempt to focus on map does not make a difference. However, for a long-running layer-shell client (such as lxqt-runner) which sets the interactivity on launch and then maps/unmaps many times throughout its lifetime, a specific focus-attempt is required on map to avoid the client itself having to keep resetting its interactivity to grab the keyboard on map. 3. Compositors like sway and river process focus (for clients with keyboard-interactivity) in their map-handlers, so this makes for a common approach. Fixes: #1653
|
Should be fixed in latest master, thanks for the report, debugging and testing :) |
...for the following reasons: 1. We interpret 'normal input-focus semantics' for clients with on-demand keyboard interactivity to means that a surface receives input focus on cursor-button-press AND on map (the latter previously missing), just like a normal window would. In this regard, we do not differentiate between layers. 2. Most layer-surfaces set the keyboard interactivity at a similar time to their first (and normally only) map, so the absence of an explicit attempt to focus on map does not make a difference. However, for a long-running layer-shell client (such as lxqt-runner) which sets the interactivity on launch and then maps/unmaps many times throughout its lifetime, a specific focus-attempt is required on map to avoid the client itself having to keep resetting its interactivity to grab the keyboard on map. 3. Compositors like sway and river process focus (for clients with keyboard-interactivity) in their map-handlers, so this makes for a common approach. Fixes: labwc#1653
In current master
lxqt-runnerwhich is launched only by shortcut doesn't receive focus anymore automatically.Keyboardinteractivity was set originally to
OnDemandbut even setting it toExclusivedoesn't change behavior - launching it and typing the typed keys go to the open document or terminal.Reverting 6990ff7 solves.
Runner is still a PR: lxqt/lxqt-runner#277
The text was updated successfully, but these errors were encountered: