On Tuesday 26 of July 2005 18:54, Elijah Newren wrote: > On 7/26/05, Billy Biggs <[EMAIL PROTECTED]> wrote: > > Elijah Newren ([EMAIL PROTECTED]): ... > > I think the WM should map _NET_ACTIVE_WINDOW requests to demands > > attention if they conflict with the policy. > > With what policy? Our policy is if the request is too old (user has > done other stuff since requesting the activation), then set the > demands attention hint.
That's a good enough policy, isn't it :) ? > We can't figure out what time the request was > made with 0 timestamps--they're old clients and we'll break things if > we just ignore them, so we follow them. There are (or can be, at least) actually two timestamps for one window - the application's and the WM's. When KWin gets a request from a window and doesn't get a usable timestamp with it, it uses its own timestamp for the window (from the last time it detected user interaction with the window, or it got last valid timestamp for it, or whatever). > > I believe kwin implements this well, so this suggests that there is a > > reasonable middle ground. > > Really? Well, sounds like Lubos is ahead of me yet again. So, > somehow Lubos figured out a trick to workaround the problem. Thinking > about this for a while, I guess we could ignore such activation > requests if the currently active window does not belong to the same > application/group as the window to be activated. Wouldn't be perfect, > but might work well enough. It'd break old taskbars but that sounds > acceptable (I think it'd be rare for users to use the latest Metacity > with really old taskbars). It might also break some accessibility > stuff like GOK, which probably wouldn't be acceptable right now--I'd > have to look into it. > > I'm guessing this is bugzilla (either Gnome or eclipse) material now > instead of continuing on wm-spec. Though I'd love to hear any sage > advice that Lubos might have. ;-) On a somewhat related note, would anybody have a problem with the attached patch for the startup notification spec. I've already been using this in KDE for quite some time, and I've just recently noticed it's actually not explicitly said in the spec. It's used e.g. for the KUniqueApplication case - if KControl is running, you launch another one, this allows the already existing window act like it's a newly launched window. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/
--- startup-notification-0.1.txt.sav 2005-07-27 17:11:43.000000000 +0200 +++ startup-notification-0.1.txt 2005-07-27 17:18:31.000000000 +0200 @@ -352,6 +352,10 @@ _NET_STARTUP_ID, UTF8_STRING The ID used for the startup sequence for the window. If set on a group leader window, applies to all application windows in that group that do not set their own _NET_STARTUP_ID. + + If a new value for the property is set, the window manager + should update the window's status accordingly (update its virtual + desktop, etc.). Launchee failures @@ -420,3 +424,5 @@ Changes since 0.1: - TIMESTAMP field is obsoleted by including the timestamp directly in the ID. - data from "change:" messages should be used even if they precede the matching "new:" message +- Explicitly mention that updating the _NET_STARTUP_ID property on a window should trigger + window manager's actions for the new startup notification again.
_______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
