GNOME Bugzilla – Bug 305979
selector needs to notify of needs-attention windows too
Last modified: 2018-01-24 13:28:16 UTC
This is related to #120439, which should fix it in the case of the libwnck tasklist, but there are two other cases which occur with varying degrees of common-ness that should be addressed somehow. These are mentioned in http://mail.gnome.org/archives/wm-spec-list/2005-May/msg00050.html. Case one is: you're not on the desktop that has the application who tried to raise or created a new window, so you don't see the the tasklist flashing. Case two is: you don't have a tasklist - I don't! I use only the drop-down window menu in the top right. The first is pretty important I think, the 2nd perhaps less so, but they could both be solved if Metacity included some way of indicating withdrawn windows that demand attention. Maybe the first could be solved in the pager though.
*** Bug 305976 has been marked as a duplicate of this bug. ***
I think this basically requires libwnck changes. We can flash the workspace switcher, or flash the icon of the window menu. In the end we aren't going to jump through a lot of hoops for nonstandard configurations, though. I think case one is standard but case two is at least somewhat in the "don't do that then" or "the window menu should have a feature for this" category.
I'd be happy with the workspace switcher flashing - should this be sent over to libwnck then? Adding eg bold on the window menu probably requires a trivial patch to window-menu.c in the panel's wncklets dir - I can open a seperate bug on that if necessary.
Yeah, it should be moved to libwnck. What do you guys mean by the "window menu"? Are you referring to the "Window Selector" applet? I'm guessing not because it looks like libwnck/selector.c:wnck_selector_get_window_name() already appears to handle that, but I don't see what else you would be referring to...
My apologies, I was talking about the "Window Selector" applet, but was looking at the wrong version of the code. Unless we want to (probably not) make the "Window Selector" applet's current icon blink (or flash the icon of the window that demands attention, complete crack?) the only thing to be fixed off this bug is the workspace switcher issue.
This does, of course, assume the user has a workspace switcher or window selector. I can't imagine the desktop would be very useful without any of these three applets, but theoretically I would say metacity itself should ensure the windows are seen and not depend on other, optional, components. Perhaps I accidentally remove my panel losing all the applets. Perhaps I'm running a "failsafe" Xsession and the first thing I run is "metacity&." Maybe I use metacity without a desktop environment at all. I realize these are fringe cases that don't really deserve careful consideration. I think really I personally just don't like the pop-under behavior at all. I'd prefer new windows to be raised but not focused.
Sean: Havoc has stated elsewhere that Metacity is designed for use with a task list, and if you use desktops, a pager. The session manager should guarantee there's always a panel (just as it guarantees metacity will be restarted). No functionality will be added to further accomodate users who don't have these, unless it can also be justified for normal users. Something such as flashing the window border (as in bug 120406) would probably be desirable (and also aid support for URGENT) even so. As an aside, things like extra notification actions for windows with DEMANDS_ATTENTION or URGENT, or raising them, would probably be doable using a seperate process. For example, http://www.burtonini.com/blog/computers/devilspie adds window matching functionality which Metacity intentionally doesn't include, and could feasibly be made to match and modify windows according to hints such as these, or a seperate process could do this and notify the user with any number of methods (libnotify, xosd...?).
Yeah, I can completely understand that. My scenarios were poor excuses at rationalizing having Metacity raise but not focus new windows. I suppose I just personally can't imagine being less annoyed by a square obnoxiously blinking in my panel until I make a point of fishing through all my open windows to find the new one and close it than I would be with my "SomePerson has added you to his buddy list" dialog popping up on top but not stealing my keystrokes. Additionally, whereas a window blinking in the taskbar applet clearly says "This window needs your attention," I don't think it's obvious that a workspace blinking in my workspace switcher says "a window on this workspace needs attention." The best way to make sure the user knows about a window is to show it to him. In the thread that spawned this bug, Havoc wrote: "In metacity yes, we try to maintain that the window on top is always focused - at least in click-to-focus mode. This is a deliberate implementation choice though and is not dictated by the spec. " I've used Gaim's "raise conversation on new message" with Metacity and have never had the focus stolen. I suppose that's actually a consequence of a Metacity bug in that case. I realize that my want requires changing this implementation choice, which isn't likely to happen. Oh well. Y'all know what you're doing better than I do, anyway. Thanks!
*** Bug 317550 has been marked as a duplicate of this bug. ***
*** Bug 167643 has been marked as a duplicate of this bug. ***
Created attachment 57313 [details] [review] Make demands-attention windows unconditionally appear in the tasklist This handles the first case in the original comment (also described in bug 167643) only. Dirt simple patch. Might be slightly unintuitive given the tasklist option and default to only "show windows from the current workspace" but few probably know they have that preference set anyway. Anyway, thoughts?
Alright I committed that; I'll leave this open for add-demands-attention-notification-to-the-selector since I don't see another bug open about that right now (though I could have sworn there was one somewhere...) * libwnck/tasklist.c (tasklist_include_window_ignoring_skip_taskbar): include demands-attention/urgent windows unconditionally in tasklist; this should help users not miss important windows on other workspaces. #305979
The "selector" you mention is the drop-down menu from the panel that shows all the windows, right?
Federico: yes :-)
*** Bug 319335 has been marked as a duplicate of this bug. ***
*** Bug 329634 has been marked as a duplicate of this bug. ***
*** Bug 332180 has been marked as a duplicate of this bug. ***
Created attachment 60811 [details] [review] Fix this a bit This is a proposal for a libwnck patch to draw urgent windows specially. It might very well not be the best possible solution, but at least it's something. Please comment. What I did is two things: 1. Draw urgent with the GTK_STATE_ACTIVE colors. 2. Draw the window outline (not the bg or icon) on top of all other windows, so that urgent windows are at least half visible even if they aren't on top. The way I did isn't exactly perfectly elegant, but as I said, at least it's something.
(note that the patch is for the pager, which might also be a good idea - I didn't review it yet)
*** Bug 358449 has been marked as a duplicate of this bug. ***
I don't really see much of a resolution with regard to the selector. In terms of indicating URGENT, I can see three methods immediately: 1. Flashing the background of the selector similar to how an entry in the window list is flashed. 2. Alternate the display of the currently active window's icon in the selector with the icon(s) of the urgent windows. 3. Alternate the display of the currently active window's icon in the selector with an attention icon. The windows marked urgent remained bolded in the selector. What are people's thoughts on these solutions? I'll happily put together a patch, if it doesn't step on people's toes. I see above that having the selector be the only method of choosing windows is considered "non-standard", but this bug indicates at least two users are doing it...
Scott: Any of those solutions sound fine to me; thanks for working on this. :)
I'm working on a patch implementing solution #2 against libwnck 2.16.0. Rationale: (Against #1) The glow code is tasklist.c specific, and generalizing the code would be a fairly intrusive patch. I'm not a GNOME developer, so this just makes me nervous. (Against #3) To implement #2 or #3, I end up writing similar code. #2 seems more useful. I'm implementing in the 2.16.0 codebase as I'm running Ubuntu Edgy, and this is my only test environment. I hope the codebase has not diverged so far that my patch can still be merged into HEAD. Let me know if you think the version difference will be an issue. Taking a look at CVS, it appears to be no issue at all.
Ok, I got #2 working but not I'm reconsidering my decision. The issue is that when there are multiple windows with a needing attention status, there needs to be a way to discern easily between the active window icon and the ones that are needing attention. This seems a little silly, but it bothers me. Yes, you're already using the active window so strictly speaking this isn't an issue. I'm starting to think #3 would be a better idea, and using a single alert icon. But, at that point, porting across the glow code seems appropriate... Thoughts?
Scott: my personal opinion would be option #1 :-) But we can commit option #3 now (if you attach the patch you made for option #2, since it's only about changing which icon to use) and let you more time to work on option #1 if you want. Thanks for working on this!
Created attachment 91358 [details] [review] Make the selector glow like the tasklist buttons This patch makes the selector behave like the tasklist buttons (ie, it glows the same way). It's a bit buggy, though: + if you change the active window, there's a grey area around the icon. + I don't know how GtkMenuItems are drawn, but the glowing area is a square, while it should have round corners (like when you select the menu item).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/47.