jlindgren90 / qmpanel

A Minimal Qt-Based Desktop Panel
GNU Lesser General Public License v2.1
13 stars 6 forks source link

Wayland issue list (help wanted) #7

Closed jlindgren90 closed 4 months ago

jlindgren90 commented 8 months ago

Keyboard focus:

Menu positioning:

Micellaneous:

Tested with:

stefonarch commented 8 months ago

screen_area_ven_20:02:37_

johanmalm commented 8 months ago
* Panel grabs focus from the active window at startup (but the active
  window's titlebar is still the active color)

This is intentional. If panels get activated when pressed, foreign-toplevel minimize-raise action does not work, because the action logic relies on the target window being activated.

I haven't checked what other compositors / window-managers do and might be wrong with the approach, but nonetheless it is intentional.

* After switching focus back to another window, panel loses keyboard
  focus and clicking the applications menu does not grab focus (cannot
  type to search)

With https://github.com/labwc/labwc/pull/1599 you should be able to set interactivity to "on-demand" and get keyboard focus whenever the panel receives a cursor-button-press.

If you're talking about opening a panel-menu with a short-cut (without mouse) then, that's a different discussion. Quite frankly, I'm not sure what the right answer it to that. There are solutions of course, but none of them seem particularly clean or native to me.

jlindgren90 commented 8 months ago

This is intentional. If panels get activated when pressed, foreign-toplevel minimize-raise action does not work, because the action logic relies on the target window being activated.

Right, I agree the panel shouldn't get "activated" -- it shouldn't get focus at all though. Not until a menu is opened.

With labwc/labwc#1599 you should be able to set interactivity to "on-demand" and get keyboard focus whenever the panel receives a cursor-button-press.

That would certainly be an improvement. I'll try it out when I get a chance.

The ideal behavior, in my mind, would be what happens under X11 -- the panel get focus only when a menu is opened, and loses it/gives it up again when the menu is closed. I don't know the correct mechanism for this under layer-shell.

If you're talking about opening a panel-menu with a short-cut (without mouse) then, that's a different discussion. Quite frankly, I'm not sure what the right answer it to that. There are solutions of course, but none of them seem particularly clean or native to me.

qmpanel doesn't actually allow opening the menu via a shortcut currently. Maybe it should...

jlindgren90 commented 8 months ago
  • Notifications are fine here with lxqt-notificationd with layershell support, did you try dunst or mako?

This could be a solution for notifications specifically, but I think the problem is more general -- X11 windows that have the "skip taskbar" hint set, are not skipped when using wlr-foreign-toplevel. Maybe something we could fix on the labwc side.

stefonarch commented 8 months ago

Maybe something we could fix on the labwc side

I don't think xwayland notifications will ever work fine. I used layershell also in its version 5 forlxqt-notificationd. Placement and skip taskbar and switcher can be solved with rules but focus stealing which is really annyoing atm only in hyprland if I remember well.

    <windowRule identifier="lxqt-notificationd" skipTaskbar="yes" skipWindowSwitcher="yes">
      <action name="SnapToRegion" region="notifications"/>
    </windowRule>
jlindgren90 commented 8 months ago

With https://github.com/labwc/labwc/pull/1599 you should be able to set interactivity to "on-demand" and get keyboard focus whenever the panel receives a cursor-button-press.

Click-to-focus seems to be working fine since https://github.com/labwc/labwc/pull/1594 actually. Thanks!

Consolatis commented 8 months ago

Maybe something we could fix on the labwc side

I don't think xwayland notifications will ever work fine. I used layershell also in its version 5 forlxqt-notificationd. Placement and skip taskbar and switcher can be solved with rules but focus stealing which is really annyoing atm only in hyprland if I remember well.

    <windowRule identifier="lxqt-notificationd" skipTaskbar="yes" skipWindowSwitcher="yes">
      <action name="SnapToRegion" region="notifications"/>
    </windowRule>

There is also https://github.com/labwc/labwc/pull/1490 on the labwc side which could automatically create rules for specific xwayland window types.

johanmalm commented 8 months ago

Panel grabs focus from the active window at startup (it should not get focus until a menu is opened)

Panel does not give keyboard focus back to the active/top application after a menu is closed

Looks like we only ever set interactivity to on-demand in qmpanel (which is the way it should be in my opinion): https://github.com/jlindgren90/qmpanel/blob/631a7b9a6bcf7ed4c35cd1f9056b9d2d351bdc04/panel/mainpanel.cpp#L77

Any chance of verifying the two points above against the latest version for labwc? We just merged six layer-shell related commits trying to sort out focus issues :smile: (mostly in response to feedback from the LXQt team - as well as obviously trying to handle layer-shell stuff in the most correct way possible).

jlindgren90 commented 8 months ago

Any chance of verifying the two points above against the latest version for labwc? We just merged six layer-shell related commits trying to sort out focus issues 😄 (mostly in response to feedback from the LXQt team - as well as obviously trying to handle layer-shell stuff in the most correct way possible).

It looks like qmpanel no longer grabs focus at startup with latest labwc master, nice! Focus is still not returning automatically to the topmost/active application when the panel menu closes.

johanmalm commented 8 months ago

It looks like qmpanel no longer grabs focus at startup with latest labwc master, nice! Focus is still not returning automatically to the topmost/active application when the panel menu closes.

On the topic of keyboard interactivity, the protocol says: “This setting is inherited by child surfaces set by the get_popup request.”

The behaviour you describe probably requires “none” when popup not open, and “exclusive” when pop up is open (rather than on-demand all the time)

Technically we may be able to force exclusive when popups are mapped (but feels like that goes against the protocol specification).

Alternatively the client could set exclusive before opening a popup. Some panels have done that (xfce4-panel and sfwbar IIRC).

Open to suggestions here.

jlindgren90 commented 8 months ago

The behaviour you describe probably requires “none” when popup not open, and “exclusive” when pop up is open (rather than on-demand all the time)

This sounds like the least ambiguous way to communicate the intent to the compositor, if perhaps a bit of a pain to implement on the panel side. If other panels are doing similar (switching to exclusive when opening a popup menu), I guess it is probably the way to go.

stefonarch commented 8 months ago

I see a similar issue with fancymenu (mainmenu would be the same I guess). It opens but no way to use keyboard, also after clicking around in the menu. We don't have yet own globalkeys working, but this opens it but is useless:

    <keybind key="A-w">
        <action name="Execute" command=" qdbus org.kde.StatusNotifierWatcher /global_key_shortcuts/panel/fancymenu/show_hide org.lxqt.global_key_shortcuts.client.activated"/>
    </keybind>

Under kwin_wayland it works, but kwin doesn't respect keyboardactivation set by client.

jlindgren90 commented 4 months ago

I'm closing this since most of the issues have been fixed and the remainder are mentioned in the README now. Thanks all!