Hi, in current XFCE when a window that currently has focus receives the "urgent" flag, you need to do all kinds of funny things to remove it again, like minimize and maximize the window. That's really annoying. What I'm used to from »awesome« is that focussed window get rid of the urgent flag immediately. This way you can e.g. use mutt or irssi together with the Xdefault setting *.urgentOnBeep, which will then notify you if new messages arrive. With the current XFCE this also works, but it is really annoying if you are currently already in that window. Summary: If window is focussed, then discard urgent flag immediatly. Please add a setting! Niklas
> in current XFCE when a window that currently has focus receives the "urgent" > flag, you need to do all kinds of funny things to remove it again, like > minimize and maximize the window. That's really annoying. Nope, works fine here. There are two things to consider: 1) Urgency, this is managed by the application, and therefore the application sets/unsets the urgency flag (and not the window manager). 2) Demands attention, there was a bug where the demand attention flag was not cleared in some (rare) cases, and that's fixed in git (head branch only). But again, the window manager does not (and should) not set/unset the urgency flag, the application does.
OK, I only know that it's the way that 'awesome' handles it, and that it's very nice to be notified of new messages this way (I'm using RXVT-Unicode as my terminal). How do you propose should mutt and irssi message notification work in XFCE? The urgentOnBlink obviously doesn't seem to be an option. If I e.g. try to go past the last message in my mutt inbox, this triggers the Bell, which again triggers urgent, which is hard to get rid off again.
> How do you propose should mutt and irssi message notification work in XFCE? There is no special way for xfce, just the standard. Set the urgency flag when needed, unset it when not. > The urgentOnBlink obviously doesn't seem to be an option. Can you elaborate? > If I e.g. try to go past the last message in my mutt inbox, this triggers the > Bell, which again triggers urgent, which is hard to get rid off again. The apps you are talking about are console apps (irssi and mutt) they are not graphical apps and therefore do not manage their window in X. They run from a terminal, maybe your problem is there, but from a pure WM stand point, your description does not make much ssense to me. Can you describe your problem more precisely, actual result/expected result. Are you talking about window decorations or taskbar? Can you provide an xprop of the window when the problem occurs?
Created attachment 2688 mutt xprop
Irssi and mutt can both notify the user through a console "beep" if a new message arrives. This beep is catched by the .Xdefaults setting *.urgentOnBeep (I use RXVT-Unicode as my terminal emulator). The terminal sets the urgent flag, such that an user in a graphical environment gets notified of the new messages. So if I'm working on workspace 1 and mutt is on workspace 4, I still notice when new mail arrives. The problem arises now when mutt currently has focus and new mail arrives (or something else triggers a console beep, like trying to go beyond the last message). The taskbar starts blinking and you have to give focus to another application first before the notification in the taskbar disappears. In the WM I've been using before the urgent was cleared immediatly, in case the window had focus. Okay, mail doesn't arrive that often, but it's even more confusing in irssi, where people use this to get notified when someone mentions their nickname. Xprop of mutt terminal window is attached (taskbar was blinking).
WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x2e00006 The urgency hint bit is set ^^^^^^^^^^^^^^^^^^^^^^^^^^^ So that is normal, the flag is setby the application (rxvt in that case) The spec says: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.4 The UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user. The window manager must make some effort to draw the user's attention to this window while this flag is set. The window manager must also monitor the state of this flag for the entire time the window is in the Normal or Iconic state and must take appropriate action when the state of the flag changes. The flag is otherwise independent of the window's state; in particular, the window manager is not required to deiconify the window if the client sets the flag on an Iconic window. Clients must provide some means by which the user can cause the UrgencyHint flag to be set to zero or the window to be withdrawn. The user's action can either mitigate the actual condition that made the window urgent, or it can merely shut off the alarm. Rationale This mechanism is useful for alarm dialog boxes or reminder windows, in cases where mapping the window is not enough (e.g. in the presence of multi-workspace or virtual desktop window managers), and where using an override-redirect window is too intrusive. For example, the window manager may attract attention to an urgent window by adding an indicator to its title bar or its icon. Window managers may also take additional action for a window that is newly urgent, such as by flashing its icon (if the window is iconic) or by raising it to the top of the stack. (In reply to comment #5) > Irssi and mutt can both notify the user through a console "beep" if a new > message arrives. This beep is catched by the .Xdefaults setting *.urgentOnBeep > (I use RXVT-Unicode as my terminal emulator). The terminal sets the urgent > flag, such that an user in a graphical environment gets notified of the new > messages. But that seems to be precisely the source of the problem, how does rxvt know when to remove the Urgency flag? The window manager will not and must not change the flag itself, so unless rcvt removes the urgency flag, the flag remains.
Okay. Now that we know that you are obeying the specs, is there a possibility to get what I want? How are other people doing it (afaik there are still a lot of people using console applications in todays world)? You're saying that RXVT should monitor if it has focus, and in that case not set the urgency flag? So apparently the awesome (http://en.wikipedia.org/wiki/Awesome_(window_manager) , in case you don't know it) guys have decided to deviate from the standards. And I got used to it. Damn.
And the answer is in the urxvt man page: "urxvt resets the urgency hint on every focus change" Anywaqy, the taskbar is not the window manager, it's a widget of its own, so this bug is invalid in xfwm4.
Ask xfce4-panel guys to add an option to ignore urgent-flag if window has focus?
It's not the panel, it's a widget from libwnck. But the proper fix imho is for rxvt not to set the flag for windows when focused.
Well, I have the same problem with PIDGIN, btw. I use the message-notification plugin to let Pidgin set the urgent flag when there is a new message. But it also does so if the window already has focus. I found no better way than setting the urgent flag to get notified of new pidgin messages (I don't want the window to pop in front of what I'm doing, I just want new messages indicated in the taskbar). I think asking the libwnck guys might be easier.
(In reply to comment #11) > Well, I have the same problem with PIDGIN, btw. I use the message-notification > plugin to let Pidgin set the urgent flag when there is a new message. But it > also does so if the window already has focus. > > I found no better way than setting the urgent flag to get notified of new > pidgin messages (I don't want the window to pop in front of what I'm doing, I > just want new messages indicated in the taskbar). > > I think asking the libwnck guys might be easier. pidgin might be different, could be demand attention, check xprop.
Devel panel won't start blinking if the urgent window is active.
Oh, great, I think it's time for a new stable release ;-))
Devel branch has been merged in master. A 4.7.0 release will follow soon. If you think this bug is not fixed? Feel free to reopen the bug.