On 7/21/05, Lubos Lunak <[EMAIL PROTECTED]> wrote: > > In particular, the activation section of the spec explictly states (as > > pointed out to me by Matthias): > > "In the X world, activating a window means to give it the input focus. > > This may not be possible if the window is unmapped, because it is on a > > different desktop. Thus, activating a window may involve additional > > steps like moving it to the current desktop (or changing to the > > desktop the window is on), deiconifying it or raising it." > > I've always understood the last sentence as "activating a window means also > the following things may happen". Even now thinking of it I still find it > ambiguous (which might be because I'm not a native speaker, but anyway).
Yes, and it lists "moving [the window] to the current desktop" which is what we want to do. In fact, the writing suggests that whoever wrote the spec expected that this would be the more common case since it only listed "changing to the desktop the window is on" in parentheses. > > So we feel that the spec doesn't prohibit switching of the workspace > > of a window in order to activate it, and further that if the spec were > > to specify policy in this manner it would cause inconsistency among > > applications[1]. So we intend to soon switch back to having Metacity > > change a window's workspace to the current workspace when receiving a > > _NET_ACTIVE_WINDOW message, unless someone can point out an error in > > our thinking or some large problem. > > One error in that thinking would be that you'd break anything non-GNOME, > which you have no control over, and you'd fix something that you have control > to fix elsewhere. If changing back would be considered "breaking" non-Gnome things, then they were already broken for forever. We only snuck in the change just barely before Gnome 2.10, which is fairly new and still having point stable releases (i.e. we can still revert so that official 2.10 behavior is still the old one). And, I disagree with the claim that it would break anything. I don't see moving windows selected in a window list[1] or window selector[2] to the current workspace as an invalid policy. In fact, gnome-panel/libwnck have a preference valid when windows from all workspaces are shown in the window list, which allows the user to choose whether selecting a window from the window list will move it to the current workspace or move the user to the workspace where the window is. (However, this is a stupid preference in my opinion--I don't see how the value outweighs the costs and we should just make it always move the windows to the current workspace). In each and every 2.x.y release of Gnome (including the recent ones where metacity changed to your behavior), the default is to move windows to the workspace where the user is. > Also for backwards compatibility it might be better if the > default old behaviour would be the one of "world minus GNOME". Assuming a > change is really needed, because while I agree with your reasoning about the > policy, I don't see any reason why _NET_ACTIVE_WINDOW should work like it > used to in GNOME. > > For example, the minion&king example in the bugreport > (http://bugzilla.gnome.org/show_bug.cgi?id=166379#c20) is flawed. For > starters, the minion doesn't come to the palace but he's there all the time, > and he's in a place assigned to him. If I was that king, told a minion to be > somewhere and he started running all around my palace and even came to my > concert hall, he might be unlucky and end up beheaded. Enough of minions, > let's start discussing windows. > > When I put a window somewhere, I want it to be there, that's why I've put it > there in the first place. If a user has 3rd virtual desktop called > 'Mail&News', why should KMail ever come to 'Development'? When a window is > supposed to be activated, it should be activated, and that's about it. It > might be unminimized, because indeed you cannot activate it otherwise, but I > don't see a reason why it should move somewhere else. Sounds like you're arguing your world view for the policy you have chosen. Sounds like a perfectly fine policy. It doesn't sound like the only valid policy. > What use cases do you have for _NET_ACTIVE_WINDOW also moving a window > to the current desktop? I think your view of the minion analogy is fine, but we view it differently. The king should be allowed to request the minion to come to him where he and his guests (other windows the user is working with) are currently at. The king should not have to go and get the minion and bring him back to where the guests are. The king should not have to bring all the guests with him to the minion. Even if the king doesn't have guests, maybe he just likes his little throne and doesn't want to be bothered to move. If the minion doesn't want to come when beckoned, he should be beheaded. Yours is a palace where the King is a control freak that wants to place everyone in certain places and remembers where they all are and doesn't want them interacting with each other or seeing something they shouldn't. Ours is a palace where the king is a lazy leech that enjoys what he is doing with the company he has, doesn't want to be bothered with remembering where everything and everyone is, and wants to beckon people to him. Dropping the analogies in order to be clear: The user is likely on a given workspace for a reason. They are likely interacting with several windows. If we make _NET_ACTIVE_WINDOW move the user to another workspace, then they have to do the additional step of manually moving the activated window back to the other workspace in order to be able to use both the activated window and the windows that had been on their original workspace. That's a pain. > An example I can think of is e.g. KUniqueApplication, i.e. > when you have already let's say KControl running, and you're in another > virtual desktop and you try to launch it again, then it makes sense to move > the already running instance to the current virtual desktop and activate it, > but this is not really just activation. This is making the already running > instance look like it's been just launched, and I don't see any problem there > with the app also moving the window to the current desktop. I agree that according to your policy for activation it makes sense to be able to distinguish activation-for-newly-launched-window and activation-for-existing-window. I believe an addition to the spec to make it easier to distinguish the two would be useful, though our policy would be to treat both cases by bringing the window to the workspace where the user is. > > We may well need a separate hint for moving to a given workspace and > > activating a given window on that workspace (for pagers), which was > > the issue that brought this all up in the first place. (Though > > perhaps _NET_CURRENT_DESKTOP + _NET_ACTIVE_WINDOW is good enough as > > long as we don't worry about races in message order?) > > I don't see any race in messages order here, but I see another problem, which > I mentioned already when requesting that Metacity changes its behaviour. If a > try to activate a taskbar entry, how do you know to which virtual desktop to > switch to? If you have just one window for the entry, that's simple. But what > if the window has a modal dialog, for example? I don't see how there's any problem with Metacity here. If a user somehow places a modal window and its parent on different workspaces, and then clicks on the parent window, then we bring the modal window to the workspace where the parent is and focus/raise it instead. Why should the _NET_ACTIVE_WINDOW message case be any different than the user clicking on the window? We don't see how it should, so we just bring the modal window to where the parent window is and have it focused/raised. Also, note that it's only for the window selector (well, other than the stupid preference for the window list that I already mentioned needs to be nuked) where we currently allow a switch-workspace-then-activate. See [1] and [2] for reasons. However, given that this does feel like a third kind of activation, I do see value in adding some kind of activation-from-pager-that-is-workspace-aware hint to go along with the activation-for-newly-launched-window and activation-for-existing-window hints mentioned above. In addition to not seeing your particular case as a problem for our policy, I can't see how to possibly get correct behavior with your policy. Since your policy is to not change any window's workspace when activating, I don't see any option other than one of the following four cases: a) Change to the workspace where the parent window is. Notice it has a modal window. Change to the workspace where the modal window is and focus/raise it. Results in ugly flickering. b) Recognize that the parent window has a modal child, change to the workspace where the modal window is and focus/raise it. Result: Why in the world can't the user see the parent window for which they are being asked a question in the modal dialog? c) Change to the workspace where the parent window is and just sit there. Result: Why can't the user interact with the window? d) Break policy. Either move the child to where the parent is and go there, or move the parent to where the child window is and go there. I personally don't like any of those options. Summary: I don't see how our changing back would break anything. I think not being allowed to change puts policy into the spec that will cause inconsistent behavior among apps. I believe it may be valuable to add activation types in the spec (such as activation-from-pager-that-is-workspace-aware, activation-for-newly-launched-window, and activation-for-existing-window). I might still be in error--please point out any mistakes that I have made. Elijah [1] The window list is a taskbar applet with lots of buttons, with one window icon/title being shown in each; clicking on a button activates the given window. In the current Gnome implementation, it only shows windows on the current workspace by default, and when windows from all workspaces are shown they are not grouped according to workspace. [2] The window selector is a taskbar applet with a single icon. Clicking on it brings up a menu that lists all windows on all workspaces, and the windows are grouped by workspace. _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
