After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 120406 - urgent "flashing" support
urgent "flashing" support
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
AP4
Depends on:
Blocks: 340691
 
 
Reported: 2003-08-21 17:54 UTC by Matthew Eaton
Modified: 2020-11-07 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Metacity CVS DIFF (4.81 KB, patch)
2003-08-21 17:55 UTC, Matthew Eaton
needs-work Details | Review
Metacity 2.8.6 diff (3.91 KB, patch)
2004-11-09 19:43 UTC, Matthew Eaton
none Details | Review
Metacity 2.8.8 diff (4.73 KB, patch)
2005-01-06 21:06 UTC, Matthew Eaton
none Details | Review
Updated version of Matthew's patch (5.23 KB, patch)
2005-10-02 03:52 UTC, Elijah Newren
needs-work Details | Review

Description Matthew Eaton 2003-08-21 17:54:35 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).
Comment 1 Matthew Eaton 2003-08-21 17:55:08 UTC
Created attachment 19417 [details] [review]
Metacity CVS DIFF
Comment 2 Havoc Pennington 2003-08-29 14:46:56 UTC
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.
Comment 3 Matthew Eaton 2003-08-29 17:36:07 UTC
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.

Comment 4 Calum Benson 2003-09-01 11:04:36 UTC
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 5 Havoc Pennington 2004-05-05 04:27:12 UTC
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.
Comment 6 Calum Benson 2004-10-21 16:41:43 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 7 Matthew Eaton 2004-11-09 19:43:51 UTC
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.
Comment 8 Matthew Eaton 2005-01-06 21:06:26 UTC
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.
Comment 9 bill.haneman 2005-01-07 12:11:59 UTC
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!

Comment 10 Matthew Eaton 2005-01-07 15:31:07 UTC
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).
Comment 11 PK Lam 2005-03-06 20:24:07 UTC
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.
Comment 12 bill.haneman 2005-03-07 20:12:23 UTC
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...
Comment 13 Robert McQueen 2005-05-31 16:30:47 UTC
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.
Comment 14 Matthew Eaton 2005-06-20 01:13:50 UTC
Now that bug #120439 is closed, should the demands_attention hint perform the
flashing in addition to the "urgent" hint?
Comment 15 Calum Benson 2005-06-21 16:55:57 UTC
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...?
Comment 16 bill.haneman 2005-06-21 19:16:48 UTC
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!
Comment 17 Robert McQueen 2005-06-24 07:33:12 UTC
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.
Comment 18 Elijah Newren 2005-10-02 03:52:56 UTC
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!
Comment 19 Elijah Newren 2005-10-02 03:54:28 UTC
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").
Comment 20 Elijah Newren 2005-10-03 22:21:42 UTC
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.
Comment 21 Calum Benson 2006-04-26 17:14:09 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 22 André Klapper 2020-11-07 12:36:02 UTC
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.