You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modifier keys like Shift, Ctrl, Alt only work when Gromit-MPX is toggled on over other XWayland windows, but are ignored for drawing over pure Wayland windows. For instance, when toggled over an xterm, all works, but over a gnome-terminal, it does not.
gtk_window_new (GTK_WINDOW_TOPLEVEL); instead of gtk_window_new (GTK_WINDOW_POPUP); and set stay-on-top and set sticky?
with X11 session: still goes to background, sticky also not working
same under wayland with xwayland
-> ⛔
look into GKD_WINDOW_TEMP, which is used for gtk_window_new (GTK_WINDOW_POPUP);
there is no special xwayland handling in GTK/GDK -> ⛔
difference between X11 session and Wayland session using XWayland is that the latter is rootless. Might this be the reason? Can we maybe set an additional property to our GTK_WINDOW_POPUP so that it eats modifier events as well in that case?
As a workaround, would it be possible to have a command line option that starts drawing? E.g.
gromit-mpx --draw
That way I can bind F9 im my desktop environment to run that command.
One option would be registering global shortcuts in the desktop environment itself, but I have no idea if there is a standard way of doing this that wouldn't involve different code for kde/gnome/etc.
As a workaround, would it be possible to have a command line option that starts drawing? E.g.
gromit-mpx --draw
That way I can bind F9 im my desktop environment to run that command.
One option would be registering global shortcuts in the desktop environment itself, but I have no idea if there is a standard way of doing this that wouldn't involve different code for kde/gnome/etc.
What you mention has already been tackled in #27 with 6501486 - this here is about the modifier keys only.
Bug behaviour
Modifier keys like Shift, Ctrl, Alt only work when Gromit-MPX is toggled on over other XWayland windows, but are ignored for drawing over pure Wayland windows. For instance, when toggled over an xterm, all works, but over a gnome-terminal, it does not.
Things tried so far
looks good, but is for wayland, not xwayland:
ask modifiert state from slave device? -> ⛔
gtk_window_new (GTK_WINDOW_TOPLEVEL);
instead ofgtk_window_new (GTK_WINDOW_POPUP);
and set stay-on-top and set sticky?look into GKD_WINDOW_TEMP, which is used for
gtk_window_new (GTK_WINDOW_POPUP);
difference between X11 session and Wayland session using XWayland is that the latter is rootless. Might this be the reason? Can we maybe set an additional property to our GTK_WINDOW_POPUP so that it eats modifier events as well in that case?
have a look at xcape features (double bind modifiers) swaywm/sway#719
https://stackoverflow.com/questions/1925568/how-to-give-keyboard-focus-to-a-pop-up-gtk-window
xwayland keyboard grabs? --> https://unix.stackexchange.com/a/607473/80396 and https://gitlab.com/Remmina/Remmina/-/issues/2106 -> hmm well no, that seems for grabbing the whole keyboard with XGrabKeyboard(), not XGrabKey() ⛔
The text was updated successfully, but these errors were encountered: