Hi, Sorry, part of my previous proposal & wording were due to me forgetting entirely about the source indication field that already exists (I was worried about distinguishing between pager and application requests for activation, as I'd like to treat them slightly different in regards to showing desktop, stacking, and transients)
> > > 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. Then we'll have to make the spec spell out a whole lot more than just what to do with workspaces (raising, showing desktop, viewports, shading, transients/siblings/ancestors, etc.). ;-) > It's the taskbar's decision what clicking the taskbar entry will do I think that's what I was disagreeing with. The only way to completely get that is to specify what _NET_ACTIVE_WINDOW does in detail when the request comes from a pager. So, whenever anyone wants to make a slightly different policy, then we have to add a new value with a really long description of the exact details that come with it. Further, if anyone comes up with some new cool UI design element that we want to use, then our spec is suddenly underspecified and if people make conflicting choices then we have to deprecate all the old ones and make new ones with more detailed policy requirements. I think the list of policies we'd need to specify is just too long. However, I'm guessing that you only really want to specify part of the behavior, and even then in a somewhat semantic kind of way (i.e. not mentioning workspaces but just worded so that it's clear how to handle it and gives the behavior you want). Something like "pager request to activate the window where it is" and "pager request to activate the window by bringing it to the user". That sounds fine to me. > , 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. The 2 and 3 thing was more because I forgot about the source indication field and wanted to differentiate between application and pager requests... Anyway, this looks like it works, but I'm kind of worried because it means apps should choose between 1 and 2--and I'm totally going to ignore what they pick because I think apps should only be specifying "do what's necessary to activate me", not specifying how the activation takes place. Is there any chance we use the source indication field to handle this extension? I.e: 0 - legacy window or pager 1 - request from an application to activate the given window 2 - legacy pager 3 - request from pager to activate the given window by bringing it to the user 4 - request from pager to activate the given window by bringing the user to it I think that'd provide what you want (pager hints about how window/user move relative to each other), and would also cover what I want (can differentiate between apps and the two kinds of pager requests). Thoughts? _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
