On Sunday 24 of July 2005 22:46, Elijah Newren wrote: > On 7/24/05, Billy Biggs <[EMAIL PROTECTED]> wrote: > > Elijah Newren ([EMAIL PROTECTED]): > > > On 7/21/05, Billy Biggs <[EMAIL PROTECTED]> wrote: > > Lubos' KUniqueApplication example was an > > interesting one, but I haven't seen any application that does this today > > (and it could be implemented directly using the desktop switching > > hints). > > *sigh* I'm assuming you're referring to using _NET_WM_DESKTOP + > _NET_ACTIVE_WINDOW (correct me if I'm wrong) to do such a direct > implementation. And no, that would not work--at least not in all > cases. What about WMs that support both workspaces and viewports? If > the window is in part of the viewport that is off the screen, then > _NET_WM_DESKTOP doesn't put it on the screen. And if you are of the > I-don't-like-workspace-switching-as-part-of-activation crowd, then you > will probably be of the > I-don't-like-viewport-scrolling-as-part-of-activation group either. > That means the app pulled the window to the current desktop, and the > WM scrolls the viewport somewhere else. Then there's all kinds of > complaints because the app meant to pull the window to the currently > viewed area (workspace + viewport region) but it just didn't happen to > think about other policies that it needed to handle. Sure, someone > might point out that apps could specify _NET_DESKTOP_VIEWPORT as well, > but that would be missing the point. Why do apps have to do all this > work? Why are apps specifying policy? What if new kinds of UI are > introduced later to supplement or replace workspaces and viewports? > Do we have to update all apps to make them specify the right policy at > that point? And how in the world do we ensure uniformity across apps > so that behavior is consistent?
Certainly not in saying "_NET_ACTIVE_WINDOW message has actually a very vague meaning and the WM is free to do whatever it wants", which you seem to prefer. > I am becoming really worried that we are collectively messing up in > the same ways that those before us have. We saw some of those > previous mistakes and e.g. made _NET_WM_WINDOW_TYPE so that WMs could > decide policy instead of apps doing so and thus provide a consistent > environment. Yet we're providing all kinds of ways for apps to > dictate behavior and even encouraging apps to do so (e.g. Billy's > suggestion that apps could using workspace switching messages + a > activation message to get windows to the current workspace, Lubos's > exact same suggestion for gtk+ to do that for all apps that request > activation in his > http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00062.html > email, Frankly, it didn't even occur to me somebody would actually like windows to change their desktop just as a result of activation. The basic idea behind my reasoning is "don't affect the window (more than necessary)". If the window is minimized, it has to be unminimized, because otherwise there's simply no way to activate it. But moving the window to another workspace is a change that's not necessary, that's changing a property of the window that wasn't requested to be changed. That's why I also think _NET_ACTIVE_WINDOW should primarily only try to affect the activity state of the window and nothing else. > > My problem is this: if _NET_ACTIVE_WINDOW can cause windows to switch > > which desktop they're on, I have to somehow modify my code to only use > > it when I know the application is currently visible, which is hard. > > Activating a window is done so that the user can use it. One should > therefore only activate a window if the user wants to use it. The way > for a user to decide to use an app is to initiate some action, not for > the app to divine that the user should use it right now (if an app > thinks it deserves attention, it should set urgent or > demands_attention hints). I don't see how whether the application is > currently visible changes the user's intent to use the app. Feel free > to point out how it should, though--I'm just not currently > understanding how it could be so. - It is noticeably simpler for the app just to try to activate its window then to detect in which state it is and act accordingly. What if it is active and it only wants to activate its other window? - I think we should accept as a fact that some apps will try to activate themselves. The WM should detect when it's okay to activate it, and if not it should automatically refuse and make it only use the demand attention flag (which is what focus stealing prevention does). With your implementation detecting state and acting accordingly (i.e. using demands attention if not active) and simply trying to become active will be different because of moving between workspaces. Ok, let's try to make this short and simple. What do you suggest happens for: - the app trying to activate itself (transferring focus between its windows, getting a new message or whatever, I hope it doesn't make any difference) - a taskbar entry is clicked - the KUniqueApp case -- 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
