Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window manager "Urgency" hint is ignored for domU windows #2642

Open
keepiru opened this issue Feb 18, 2017 · 10 comments
Open

Window manager "Urgency" hint is ignored for domU windows #2642

keepiru opened this issue Feb 18, 2017 · 10 comments
Labels
C: desktop-linux C: gui-virtualization P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience

Comments

@keepiru
Copy link

keepiru commented Feb 18, 2017

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

Any


Expected behavior:

Taskbar icon ("Window Button") blinks when WM_HINTS urgency bit is set.

Actual behavior:

Urgency is handled correctly for dom0 windows, but ignored for domU.

Steps to reproduce the behavior:

Repro (a):

urgent_hello.c.txt
In an AppVM:
$ gcc -L/usr/X11R6/lib -lX11 urgent_hello.c
$ ./a.out

When the window opens, alt-tab away so it is backgrounded. After two seconds the urgency hint will be set. Observe that taskbar icon does not blink.

Copy a.out to dom0 and repeat. Observe that the taskbar icon blinks as expected.

Repro (b):
Launch xterm in dom0.
Control-middle_click, check "Enable Bell Urgency"
$ sleep 2 ; echo -e '\a'
Alt-tab to background the window.
Observe blinking taskbar icon.
Repeat in AppVM. Observe non-blinking taskbar icon.

General notes:

https://github.com/QubesOS/qubes-issues/files/784748/urgent_hello.c.txt
https://tronche.com/gui/x/icccm/sec-4.html#WM_HINTS
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#URGENCY


Related issues:

@andrewdavidwong
Copy link
Member

@marmarek, is this intentional?

@marmarek
Copy link
Member

Clearly this window manager hint is not supported, but I'm not sure if it should be. For example, will it make easier for application to steal the focus?

@keepiru
Copy link
Author

keepiru commented Feb 21, 2017

I think it should be supported. Many applications use it: Email and IM clients to indicate new messages are waiting; terminals to indicate a bell.

My use case is instant messaging. I'm failing to notice PMs when the window is hidden.

The flag is used for window decoration and taskbar highlights to attract the user's attention, but focus is not automatically changed; the user has to do so manually, at least in every window manager I've used. XFWM4 certainly doesn't use it to change focus. You can test this by setting the flag on dom0 windows.

@andrewdavidwong andrewdavidwong added the T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. label Feb 21, 2017
@andrewdavidwong andrewdavidwong modified the milestones: Far in the future, Release 3.2 updates Feb 21, 2017
@marmarek
Copy link
Member

Something very similar is supported: _NET_WM_STATE_DEMANDS_ATTENTION flag:
https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html

Maybe support for "urgency" flag could be plugged into the same feature?

@aidecoe
Copy link

aidecoe commented Apr 28, 2018

@marmarek Could you suggest in which component it should be implemented, please?

@marmarek
Copy link
Member

Dom0 part: https://github.com/QubesOS/qubes-gui-daemon/
VM part: https://github.com/QubesOS/qubes-gui-agent-linux/
Related protocol part: https://github.com/QubesOS/qubes-gui-common/blob/master/include/qubes-gui-protocol.h#L198-L204
Not sure how "Urgency" is different from "Demands attention", but if they are in practice the same, maybe this thing could be merged? I.e. at gui-agent side set the flag if either of them is set and in gui-daemon - set both. This would reduce number of possible flags combinations controllable by VM (Xorg is full of corner cases),

@donob4n
Copy link

donob4n commented May 15, 2018

Maybe this could be handled from dom0 like fullscreen. Only trusted domains are allowed to steal focus.

@marmarek
Copy link
Member

I think no qube should be allowed to steal focus. This is a bit tricky, even without this urgency flag implemented (see various window manager settings), but lets not make things even worse.

@aidecoe
Copy link

aidecoe commented May 15, 2018

Urgency has nothing to do with stealing focus, IIUC. Window notifies window manager that it needs attention, but the window is not brought up. In e.g. dwm, awesome or i3 the effect is that window title and tag on which the window has signaled "urgency" is highlighted. Nothing more. "Urgency" would be implemented similarly as "demands attention".

@keepiru
Copy link
Author

keepiru commented Aug 12, 2018

UrgencyHint is defined in ICCCM, and is only cleared by the application.

_NET_WM_STATE_DEMANDS_ATTENTION is defined by EMWH, and is cleared by the WM when the window receives focus.

In all other respects they're essentially the same thing. XFCE4 already implements both flags, so I think all that's required is for qubes-guid to copy the flags back and forth.

@andrewdavidwong andrewdavidwong removed this from the Release TBD milestone Aug 13, 2023
@andrewdavidwong andrewdavidwong added the P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. label Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: desktop-linux C: gui-virtualization P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience
Projects
None yet
Development

No branches or pull requests

5 participants