On Thursday 28 of July 2005 22:34, Elijah Newren wrote: > On 7/28/05, Lubos Lunak <[EMAIL PROTECTED]> wrote: > > On Wednesday 27 of July 2005 21:03, Elijah Newren wrote: > > > > Frankly, I as a user can't imagine virtual desktops being useful the way > > your taskbar works. > > With which preferences set? (It sounds to me like you wanted > show-windows-from-all-workspaces + restore-to-native-workspace, which > is one of the cases we happened to cover, but maybe you had something > else in mind)
I mean with taskbar entry clicking moving the window to the current desktop, like used to happen with KDE taskbar and Metacity. But then I'm not your user, so I don't really count. > > > The real reason why I reported the bug for Metacity was > > actually that it was getting really on my nerves whenever I used Metacity > > as a replacement for momentarily unstable KWin. So I suggest you're > > careful here, in case more people think the same way like I do ;). > > It actually seems to be a much nastier issue, with people wanting all > kinds of weird choices. Here's someone who tried to summarize some of > the different possible modes and part of why people might want certain > ways or another: http://bugzilla.gnome.org/show_bug.cgi?id=81222#c19. > Do you have any similar bug(s) in kde bugzilla? I really don't feel > like I understand all the ways the taskbar is used with the reasons > for why people use it that way (I use virtual desktops constantly but > I personally don't feel any need to have the taskbar show windows from > any other workspace than the current one. *shrug*) I don't maintain Kicker/taskbar, so I don't have a good overview, but, also after checking bugzilla, I don't think people have any problems with our taskbar. The only real settings affecting this are showing only minimized windows and showing windows from all desktops. I suppose most people use the default of showing all windows only from the active desktop, which doesn't concern us here. Some people, presumably mostly those who use virtual desktops extensively, like me, turn on showing windows from all desktops, and then the taskbar is acts as fast access to any window. For moving a window to the current desktop, it has to be done from the popup menu. > > Yes, I guess that could be a good solution. So another field in > > _NET_ACTIVE_WINDOW, with > > 0 - old apps > > and old pagers ;-) > > > 1 - the normal _NET_ACTIVE_WINDOW for apps > > 2 - pagers etc. > > > > I'd like to keep 0/1 in order to recognize old pagers etc. Actually > > given the way you want to make _NET_ACTIVE_WINDOW work it might be even > > more useful for you. > > Yeah, I like 0 being separate. > > > How would we define the behaviour of 2? I normal words I'd describe it > > as "leave the window as it is if possible", but that's no spec talk :). > > I.e. I think the functionality should be "make everything else come to > > the window", as opposed to yours "make the window come to the user" for > > 1. > > I'm worried that if we define it in terms of behavior then instead of > just having pagers use it we'll have apps start using it just to be > different and causing inconsistencies. That's why I said "in normal words". The problem is, your description of the functionality doesn't mean anything to me. "A request from workspace-aware pager" ... aha. I don't really know what to do actually do with that, I even don't see the difference between 2 and 3. Also, now that I think of it, "make everything come to the window" actually conflicts with what you want your taskbar to do. Although, perhaps it actually should specify the behaviour. I want KDE's taskbar to always act the same regardless of what you Metacity developers think. It's the taskbar's decision what clicking the taskbar entry will do, we just want to have to use only a single _NET_ACTIVE_WINDOW to avoid some problems like having another window activated if _NET_WM_DESKTOP + _NET_ACTIVE_WINDOW combo is used. For your taskbar-moves-the-window-to-the-current window, your taskbar could actually use 1, so your taskbar would have the "make the window come to the user". So I actually think having 0 - legacy, 1 - "make window come", 2 - "make everything come to window" should be enough. And perhaps one more, given that you see a difference between your 2 and 3 below. > > I'd like to have both a 2 and a 3, actually. If we think of the > wording for 1 as > 1 - "a request from an application to activate the given window" > then the definition for 2 and 3 would be something like the following: > 2 - "a request from a pager which has workspace/viewport-aware UI to > activate a given window" > 3 - "a request from a pager which does not have workspace/viewport-aware > UI to activate a given window" > The reason why I'd like a 2 and a 3 for this just goes back to the > rationale we have for _NET_ACTIVE_WINDOW[1] and trying to be able to > determine whether we can infer that the user made a request about all > the other windows on the current workspace and > window-to-be-activated's workspace. > > Of course, WMs would be free to treat all three request types the same > way or have different policies for each. (In particular, I might like > to make 2 and 3 different from 1 in regards to show desktop mode, as > well as having 2 different from 3 in regards to workspace switching) -- 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
