On 7/24/05, Billy Biggs <[EMAIL PROTECTED]> wrote: > Elijah Newren ([EMAIL PROTECTED]): > > > On 7/21/05, Billy Biggs <[EMAIL PROTECTED]> wrote: > > > Isn't the only application-class where you want this > > > jump-to-current-desktop behaviour 'gaim' or other apps which have a task > > > bar item, you click on it, and the gaim window appears on your current > > > desktop? > > > > Personally, no. > > What's the other example?
It sounds like you're asking for my policy preferences or perhaps for the Gnome usability team's policy preferences (which don't always jive...), but that is perhaps better discussed elsewhere. Yes, it's reasonable to ask considering that's how the rest of the thread has gone, I guess, but it seems weird to me that we're spending time on what policy people like and why and that we're doing that more than on how to make the spec so that WMs can do their job and apps can work and be consistent. And if you'll permit me, I'd like to object to the question for a secondary reason in that I feel it is leading. It could be fixed by asking for examples instead of "the" example, but a much easier question for me to answer would be "Where don't you want an application's workspace to change as part of activation?" (for us, the answer to that question is only for-pagers-which-have-workspace-aware-UI, while for other WMs it could be under-no-circumstances-whatsoever) > 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? 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, and my suggestion for using _NET_CURRENT_DESKTOP + _NET_ACTIVE_WINDOW to get the don't-change-window's-workspace behavior wanted by the pager regardless of the WM's policy for _NET_ACTIVE_WINDOW) > I'm sorry, I don't understand your response. What's the third policy > I have introduced? My understanding of everyone's suggested policy (correct me if I'm wrong): Lubos' policy: don't change any window's workspace as part of activating it Gnome's policy: change windows' workspaces in order to activate unless the request came from a pager-with-workspace-aware-UI Your suggestion: don't change any window's workspace as part of activating it except for requests that come from pager-with-workspace-unaware-UI > 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. Cheers, Elijah _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
