On 7/25/05, Lubos Lunak <[EMAIL PROTECTED]> wrote: > On Sunday 24 of July 2005 22:46, Elijah Newren wrote:
<snip> > > 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. Huh? That doesn't make sense to me. We don't specify how WMs must handle _NET_WM_WINDOW_TYPE_DIALOG windows. Some WMs don't decorate such windows; others do. Some may feel they should appear in the alt-tab list; others don't. There's a whole list of properties WMs are free to associate with this--it conveys a semantic property type, not a set of policy rules. This enables uniformity across apps because apps don't specify the policy. Sure, the behavior of those apps are different when under one window manager than another, but under a given window manager all such windows from all apps regardless of the toolkit they are implemented with behave the same. That's the goal. _NET_ACTIVE_WINDOW is similar. Different environments want to provide different activation policies. Having it be vague, i.e. only convey a semantic action type, is _exactly_ what allows a given window manager to provide consistent behavior for all apps regardless of the toolkit they were developed with. <snip> > 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. The idea behind our reasoning was actually very similar. We treat _NET_ACTIVE_WINDOW as a "do what's necessary to activate this window" request from the user and we feel it is important that we "don't affect more than necessary to get the window activated." So, how do we interpret that? Focusing the window seems an obvious need for activation. The user didn't explicitly request the window to be unminimized, but it falls under "do what's necessary to activate this window". If the window is a transient, we unminimize its parent(s), as we feel the window doesn't make sense to be shown alone. We leave show_desktop mode if it is on (since show desktop means windows aren't shown). We unshade the window if shaded (doesn't make much sense to us to activate the titlebar only). Raising the window is sort of similar to unminimizing, though it may depend on another preference (one that we currently don't support anyway, so raising unconditionally is fine for us for now)[1]. We don't support viewports and thus don't have to worry about them. Now, if the window is on a different workspace, there are two choices: - change the window's workspace - unmap a bunch of unrelated windows (i.e. windows from different applications than the window-to-be-activated) and map a lot of other unrelated windows The user didn't request anything to be done with all those other applications, therefore changing the window's workspace provides the least amount of change. <snip> > - 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. I agree; I don't see why an app should ever need to detect its state before trying to activate one of its windows. > What if it is active and it only wants to activate its other window? If an application window is active and wants another window from the application to be activated, why wouldn't the user want both windows on the same workspace? > - 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). I agree and I think you hit the nail on the head here, Lubos. Billy has mentioned the "user gets surprised by window getting pulled to users desktop" stuff before with relevant bug reports, but those were all before Metacity 2.10.x--i.e. before focus stealing prevention was turned on in Metacity. I'm betting that his real annoyance was with Metacity unconditionally following _NET_ACTIVE_WINDOW requests but he placed the blame on what what he saw (i.e. the activation behavior) without realizing there was something deeper. Billy: could you verify (in other words, were the problems your users were experiencing only occuring when an activation message was sent when no window from the application was active anymore)? > 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. Activation could also be different in other window managers due to handling of related ancestor/sibling/child windows, show_desktop state, shading (maybe activating a shaded titlebar has special uses in another WM?), alternative forms of hiding like shading, existence of an orthogonal raise option, viewports, and perhaps other UI things that people haven't yet thought of. So? > Ok, let's try to make this short and simple. What do you suggest happens for: Note that my suggestions are for what Metacity does, and I think it would be bad to require other WMs to do the same. > - 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) Use all the policy decisions previously listed (includes moving the window to the current workspace). > - a taskbar entry is clicked Depends on whether the taskbar arranges windows in a workspace aware way[2]. If it does, changing to the workspace where the window is sounds fine. Otherwise, the window should be brought to the current workspace. All policy decisions not related to the workspace are as previously listed. Note that Gnome's taskbar ("Window List" applet) does not list windows from other workspaces by default. If the user turns on a preference to list windows from all workspaces, Gnome's taskbar does not take workspace into account in any way when arranging the windows. > - the KUniqueApp case Use all the policy decisions previously listed. Cheers, Elijah [1] I suspect there are likely do-not-raise-on-click people (namely those who use the feature for real reasons instead of as a cop-out workaround for do-not-raise-on-initial-click-of-DND, i.e. those who truly want an raising to be ortogonal to all other actions) who are going to take exception to raising being a necessary part of activation. They would likely prefer activation to only imply raise-if-totally-obscured. [2] If the taskbar has UI that arranges windows in some kind of workspace aware way then the WM could infer (this is a nested policy choice here) that the user actually did make a request about all the unrelated windows on the current desktop and window-to-be-activated's desktop and thus decide to change to the workspace of the window-to-be-activated. _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list