GNOME Bugzilla – Bug 120406
urgent "flashing" support
Last modified: 2020-11-07 12:36:02 UTC
I've created a patch for metacity cvs that adds in window blinking in response to the URGENT window hint. Its not very polished, but functional. I guess in the end it would need a configuration option. This is useful for instant messengers (like gaim, which I am using right now).
Created attachment 19417 [details] [review] Metacity CVS DIFF
Do we want to flash the frame or just the window list button? Implementation-wise, if the window is destroyed while the timeout is installed this will crash.
Re the flashing, I think that both the window frame and the task button look good (a la win32). This gives a visual cue that they are related and allows you to click whichever is convenient without scanning the entire screen for the matching window. The implementation hasn't caused any crashes when I experimented with closing the window (either by clicking or with the application), but I do see where the initial window->frame call could cause it. I will work on a safer check.
How does this patch interact with the user-configurable system bell? Cc'ing Bill here as I don't have any bright ideas about how it actually should, and I'm sure he'll have something to say about the flashing too :)
Comment on attachment 19417 [details] [review] Metacity CVS DIFF Seems to be a crash issue and a design question or two pending here, putting patch in needs-work.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Created attachment 33596 [details] [review] Metacity 2.8.6 diff Same patch just updated for v2.8.6. This patch suffers from the same bugs as the previous, so it still "needs work". Also not sure if DEMANDS_ATTENTION is suppose to cooperate with it or not.
Created attachment 35579 [details] [review] Metacity 2.8.8 diff Fixed crashing bug (hopefully) Also, bug #120439 for libwnck is similar if you are interested.
It seems to me that the urgent 'flash' and the 'visual bell flash' should be the same code/implementation, at least when the visual bell is configured to flash the frame and not the whole screen. It looks to me as though the patch is doing this (reusing the visual-bell flash code), is that correct? And has it been tested with visual-bell enabled? See Calum's comment #4. Thanks!
Re comment #9. I just tested it with visual bell + frame enabled. From the user's point of view, it makes the frame flicker and then resume where it left off in the 1 second flashing. It might be a bit inconsistent depending on when the bell occurs though: The visual bell code: Turns frame inversion on, then 100ms later turns it off. The flashing code: changes the inversion variable every second. So the corner case is if the bell comes right before the flash code changes the invert variable to on. This would result in: inversion off -> (bell) inversion on -> (flash) inversion off -> (bell) inversion off. So if they occurred in that order closely you would see little effect. However, in any case you still get an interruption in the normal flashing and would be noticeable. Also note that the bell affects the active window and usually the active window wouldn't be marked urgent (at least for its intended use here).
I'm not a developer but I came across this problem when I'm trying to use Gaim. In KDE the "urgent" hint works fine but it doesn't work in Gnome. I thought that the problem may have been something having to do with Gaim. I learned that it actually because Gnome's Metacity doesn't yet support the "urgent" hint. A lot of people use Gaim and Gnome so it'll be nice to have the "urgent" hint work. I know I'd appreciate it. Anyway, I hope this bit of information is of some help to you. I really appreciate all the hard work you developers put into making Gnome better.
RE:comment #10, this might actually turn out to be a common case, since apps may very well choose to 'beep' just before setting the 'urgent' hint. I suggest we try to support that case more gracefully...
Gaim is likely to implement setting the UrgentHint by default in the 2.0 release, so it'd be nice to see support for it in Metacity as well as libwnck's task list.
Now that bug #120439 is closed, should the demands_attention hint perform the flashing in addition to the "urgent" hint?
Kind of a tangent, but if the window's on another workspace, and the user is only choosing to show windows on the current workspace in their window list, should the appropriate window (or workspace) flash in the workspace switcher too...?
sounds to me like flashing the workspace would be the best choice (flashing a window in a workspace might be too small to attract attention). Nice catch Calum!
Flashing the pager has already been discussed on #305979, it needs to happen in libwnck. I'm not sure about the implementation status of that though.
Created attachment 52927 [details] [review] Updated version of Matthew's patch Sorry for the slow response. Anyway, the old patch had a small conflict and I updated it, and also made a small cosmetic change or two (fixing spacing or tab vs. space stuff to match the style elsewhere in the code). I can't test at the moment, but to answer your earlier question (assuming Havoc wants both the titlebar and tasklist to flash): yes we'll need this patch to support demands attention and have it do exactly the same thing as the urgent hint. Thanks for your work!
Re comment 15 & 16: An alternative would be to stick the task in the tasklist anyway when it has the urgent or demands attention hint (after all, we do the same thing for windows that are "starting up").
Okay, I tested the patch; it seems to work okay (though do we want something that looks more like the taskbar flashing?). I'm going to mark the patch as needs-work, though, since it does need to do the same thing for windows with the demands-attention hint set.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.