On Monday 25 of July 2005 20:44, Elijah Newren wrote:
> 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.
But we do specify some things that must be done, otherwise there would be no
point in having a spec.
>
> _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>
>
> 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
...
Ok, I see we both have good theoretical backing for our reasoning :). So
let's skip vague theories talk.
> > 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.
>
> > 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.
No. We need something that would work everywhere. That's why we have a spec.
Kicker's taskbar should work even with Metacity.
>
> > - 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).
I was expecting some more practical answer, something more along the lines of
"the app sends _NET_ACTIVE_WINDOW to activate the window". It especially
interests me for the case below, because frankly I didn't get what you mean.
> > - 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.
> [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.
--
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
