On Wednesday 27 of July 2005 18:34, Elijah Newren wrote: > On 7/27/05, Lubos Lunak <[EMAIL PROTECTED]> wrote: > > On Tuesday 26 of July 2005 18:54, Elijah Newren wrote: > [Offtopic: Now that I think about it, I think I can fix Billy's > problem by patching gdk_window_focus() to use the most recent user > interaction timestamp whenever 0 is passed. That'll simplify > gtk_window_present() as well...]
I personally think Billy's primary problem is the fact that they use _NET_ACTIVE_WINDOW too much. When an application shows a new dialog window it shouldn't do _NET_ACTIVE_WINDOW on it just in case or for the fun of it. AFAIK all modern toolkits keep the X focus only on the toplevel window and maintain their own internal focus, for good reasons. So there should be rarely a reason to mess with the X focus. > > > 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). > > Oh, the "requestor's currently active window" field for > _NET_ACTIVE_WINDOW, right? I had never understood the reasoning for > that. No. Your problem, if I understand it correctly, is that if you get a request that doesn't include a valid user activity timestamp, you don't know what to do. To solve this you can keep your own activity timestamp for the window in the WM. You can update it from valid timestamps you get from the app, and you can also update it if you detect user activity yourself (clicking on the titlebar or whatever). If I don't understand your problem correctly then we indeed might be talking about different things. > So, am I correct in inferring that you use this as a backup in > case a timestamp of 0 is provided, making use of the WM's > last_user_interaction timestamp for that window in this case? Is > there anything else you use it for? (I'm having a hard time seeing a > use for it if a nonzero timestamp is provided, but perhaps I'm just > missing something again) > > Also, one of my main sticking points in understanding the currently > active window stuff was that (correct me if I'm wrong) apps can't > reliably know whether they have a window which is active since they > only get notified of loss of focus after it happens. Perhaps "the > requestor's most recently active window" would clarify this? Except, > that would kind of negate the need for sending None sometimes which > the spec allows... hmm... The reasoning for the current active window is here: http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00039.html - it's for the cases when an active application wants to activate another window that doesn't belong to that application. But now that you ask I'm actually unsure whether it's really needed or if just the timestamp could do as well. Hmm ... thinking ... well. It's a bit difficult to remember for me. It was quite some time ago, and being the only person in the world ;) had some unpleasant consequences like it always being me who ran into dead ends from time to time and had to try again differently or having nobody to really check the stuff. And, as you probably now know yourself, thinking about this can cause serious headache. In fact just yesterday I was debugging some problem related to this and I found out I was getting wrong results because of expecting some things about the mechanism that no longer were true. So it indeed may be the field is just nonsense. And from the log messages I cannot quite remember why it found it needed either. Hmm. I think I might know a reason though. Say that you have apps A and B running. Activate A, do something in A (that updates its user activity timestamp, in the app), activate B, do something in B (again timestamp update in the app). Now activate A just by clicking the titlebar, that makes it active, but the user activity timestamp in the app doesn't update, only in KWin. And now if A wants to activate B's window, KWin wouldn't let it, because A has more recent timestamp - only in KWin though, the timestamp in the app, and hence in the message, is old. If A adds also its active window to the message, KWin will see the request comes from the active window and will allow the activation. I guess this might have been the reason why I added it. Now, there's a rather weird details I might have missed before. Why the hell should A decide to activate B without any user activity leading to this? If the user clicks in A and that leads to the activation, the timestamp in the app will be correct. And the app shouldn't do the activation just for the fun of it. So maybe it's really nonsense. -- 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/ _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list