GNOME Bugzilla – Bug 600068
notifications for window urgency hint
Last modified: 2009-11-20 09:04:33 UTC
Created attachment 146524 [details] [review] MetaWindow::urgent property I will attach two patches that add a boolean property MetaWindow::urgent and a MetaDisplay signal "urgent-window" that track the ICCC urgent hint. This is analogous to the MetaWindow::demands-attention and MetaDisplay::demands-attention from bug 588065 and bug 597052. (Although Mutter itself does not handle the urgency hint, a plugin might want to do so.)
Created attachment 146525 [details] [review] MetaDisplay::urgent-window signal
Review of attachment 146524 [details] [review]: On one hand, yes, Moblin is "mechanism not policy" and exports various things straight through to the environment - on the other hand, I think it's sort of bad if Moblin and GNOME aren't in agreement about whether the urgency hint does something. So, what's the UI vision here? When do apps set this hint as compared to activating their windows? Few minor comments on the patch: - Commit message has typo "ICCC" rather than ICCCM - I think there should be an explicit initialization of the field in window.c ::: src/core/window.c @@ +2691,3 @@ + + if (window->wm_hints_urgent) + g_object_notify (G_OBJECT (window), "urgent"); This emission (in meta_window_show()) doesn't make any sense to me - the urgent flag isn't changed depending on whether the window is on screen or not.
Review of attachment 146525 [details] [review]: ::: src/core/window-props.c @@ +1409,3 @@ + /* + * Do not emit signal for the initial property load, let the constructor to + * take care of it once the MetaWindow is fully constructed. But you don't, this signal is never emitted if the hint is set on a newly created window
(In reply to comment #2) > Review of attachment 146524 [details] [review]: > > On one hand, yes, Moblin is "mechanism not policy" and exports various things > straight through to the environment - on the other hand, I think it's sort of > bad if Moblin and GNOME aren't in agreement about whether the urgency hint does > something. > > So, what's the UI vision here? The moblin UI vision on this is evolving (I know, it sounds bit lame, but it's true); at the moment we translate this signal into a notification with Activate/Dismiss buttons; it is possible that a future solution will be integrated with the application switcher. (On conventional Gnome desktop this is handled by the taskbar, the functionality of which is encapsulated into the shell, so having a convenient signal to hook into seems to make sense.) > When do apps set this hint as compared to activating their windows? That is a question I have no answer to, while a policy would be good, at the end of the day we might not always be able to enforce it (e.g., we run into the need to handle the urgency hint because it appears to be used by Adobe Air). > ::: src/core/window.c > @@ +2691,3 @@ > + > + if (window->wm_hints_urgent) > + g_object_notify (G_OBJECT (window), "urgent"); > > This emission (in meta_window_show()) doesn't make any sense to me - the urgent > flag isn't changed depending on whether the window is on screen or not. Indeed; this is actually removed by the second patch, I will clean this up. > ::: src/core/window-props.c > @@ +1409,3 @@ > + /* > + * Do not emit signal for the initial property load, let the constructor to > + * take care of it once the MetaWindow is fully constructed. > > But you don't, this signal is never emitted if the hint is set on a newly > created window Sorry, I think something got lost somewhere in a manual merge :(
Created attachment 147956 [details] [review] Updated patch for urgent property
Created attachment 147957 [details] [review] Update patch for urgent-window signal
(In reply to comment #4) > (In reply to comment #2) > > Review of attachment 146524 [details] [review] [details]: > > > > On one hand, yes, Moblin is "mechanism not policy" and exports various things > > straight through to the environment - on the other hand, I think it's sort of > > bad if Moblin and GNOME aren't in agreement about whether the urgency hint does > > something. > > > > So, what's the UI vision here? > > The moblin UI vision on this is evolving (I know, it sounds bit lame, but it's > true); at the moment we translate this signal into a notification with > Activate/Dismiss buttons; it is possible that a future solution will be > integrated with the application switcher. (On conventional Gnome desktop this > is handled by the taskbar, the functionality of which is encapsulated into the > shell, so having a convenient signal to hook into seems to make sense.) > > > When do apps set this hint as compared to activating their windows? > > That is a question I have no answer to, while a policy would be good, at the > end of the day we might not always be able to enforce it (e.g., we run into the > need to handle the urgency hint because it appears to be used by Adobe Air). This isn't doing it for me. Both OS X and Windows have a way of prompting the user's attention to a window: - In Windows (Vista and earlier, not sure about 7) this was similar to GNOME's tasklist flashing. - In OS X you have the bouncing icon in the dock And they have a *single* visual modality. This is presumably what the Adobe Air developers were trying to achieve. I can't imagine that they wanted the ICCCM urgent behavior where the application (not the WM) is supposed to have a UI for unsetting the urgent bit, and the WM is supposed to keep alerting the user until that bit is unset. The GNOME equivalent of this is what we do for the demands_attention state - flash in the taskbar for GNOME 2, still evolving for GNOME Shell. The way to get into that state is _NET_ACTIVE_WINDOW, with a timestamp of 0 if you never want to take focus from a different active window. You could argue that that isn't reliable - that you can't get into the demands_attention state if you are already the active window; IMO, there really isn't much reason for the active window to mark the active window as urgent. But even if we need a better way of setting the state, that's not a reason for two states and two user interfaces.
(In reply to comment #7) > This isn't doing it for me. > > Both OS X and Windows have a way of prompting the user's attention to a window: ... And they have a *single* visual modality. > > This is presumably what the Adobe Air > developers were trying to achieve. I can't imagine that they wanted the ICCCM > urgent behavior where the application (not the WM) is supposed to have a UI for > unsetting the urgent bit, and the WM is supposed to keep alerting the user > until that bit is unset. I am sure you are right, but, for better or worse, they are using a mechanism provided by the standard, and which is supported in current GNOME via the taskbar. Consequently, what I am hearing now is 'it works in Gnome, but not in Moblin', so not handling the UrgencyHint in some way is not an option. > The GNOME equivalent of this is what we do for the demands_attention state - > flash in the taskbar for GNOME 2, still evolving for GNOME Shell. > > The way to get into that state is _NET_ACTIVE_WINDOW, with a timestamp of 0 if > you never want to take focus from a different active window. > > You could argue that that isn't reliable - that you can't get into the > demands_attention state if you are already the active window; IMO, there really > isn't much reason for the active window to mark the active window as urgent. > > But even if we need a better way of setting the state, that's not a reason for > two states and two user interfaces. I pretty much agree with you on this, I too do not see any compelling reasons to have two different visual states and user interfaces, and in fact the prototype code in mutter-moblin just hooks the same callback into both the window-demands-attention and urgent-window signals. But since the demands-attention and UrgencyHint are semantically slightly different, I would prefer to keep them distinguishable on the low level.
Review of attachment 147956 [details] [review]: Sorry for giving you a hard time on this; it hadn't occurred to me (for one reason or the other) that the GNOME tasklist was already handling this hint. With that in mind, I think the addition is appropriate. ::: src/core/window-private.h @@ +131,3 @@ guint fullscreen : 1; + /* Whether the urgent flag of wm_hints is set */ I'd probably capitalize WM_HINTS here ::: src/core/window.c @@ +317,3 @@ + g_param_spec_boolean ("urgent", + "Urgent", + "Whether window urgency hint is set", Think the text from window-private.h is slightly better "Whether the urgent flag of WM_HINTS is set"
Review of attachment 147957 [details] [review]: ::: src/core/window-props.c @@ +1411,3 @@ + * take care of it once the MetaWindow is fully constructed. + * + * Only emit if the property is both set and changed. Some reason this makes more sense to me reversed as "both changed and set" ::: src/core/window.c @@ +1127,3 @@ + if (window->wm_hints_urgent) + g_signal_emit_by_name (window->display, "urgent-window", window); Forget if I commented on this in the last patch, but 'window-demands-attention' vs. 'urgent-window' seems inconsistent. I'm uncertain whether 'window-marked-urgent' would be better. I'm fine with either, though not that happy with either :-)
Comment on attachment 147956 [details] [review] Updated patch for urgent property Committed as 0ccfb0d7816990624bfa3f4ff4ffbc8e95e3b02b, with the suggested minor changes.
Comment on attachment 147957 [details] [review] Update patch for urgent-window signal Committed as 5e2c66e241ce6f9a6e4fe28290ae63b8b1520dce, after renaming the signal to window-marked-urgent.
> Sorry for giving you a hard time on this; Not to worry; I would rather be given hard time than we just piled random crud in :)