[EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Denis Washington]

Hello,

A few days ago I wrote a small patch to add a more fancy launcher
feedback animation to the GNOME panel when a compositing manager is
running [1]. For this animation, I'm using an auxiliary ARGB window into
which I draw the actual animation (a ghost effect which expands over the
panel area and thus needs an extra window). This works quite well,
however there is one problem: most compositing managers (I tried with
compiz) apply animations on mapped and unmapped windows, which takes
away the full control over the effect from me. For my effect, for
instance, the problem is that my compiz configuration does a fade-in on
my auxiliary windows although I actually want to start with a fully
opaque window fading out; the result is the window fading in while I am
already starting to fade it out from my code, leading to more like a
flash than a proper fade-out.

My proposal is to add a new window type hint, say
_NET_WM_WINDOW_TYPE_AUXILIARY (maybe not the best name), which tells
window managers not to apply any animations to it so that applications
have full control over on how they will look when appearing,
disappearing etc. I'm convinced that there are also plenty of other
effects for which this would be quite handy.

Regards,
Denis Washington

[1] Bug 479562 – [PATCH] Fancier launcher animation if compositing
manager is running (gnome-panel),
http://bugzilla.gnome.org/show_bug.cgi?id=479562

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

You're using an override-redirect window here - do compositing
managers already read hints off those? A regular WM will not touch an
override-redirect window, of course, including not reading hints and
not doing any fading effect.

Havoc
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Denis Washington]

On Wed, 2007-10-03 at 12:24 -0400, Havoc Pennington wrote:
> Hi,
>
> You're using an override-redirect window here - do compositing
> managers already read hints off those? A regular WM will not touch an
> override-redirect window, of course, including not reading hints and
> not doing any fading effect.
>
> Havoc

Yes, override-redirect windows are also faded in and out - otherwise,
fade-in effects for e.g. menus and tooltips (also override-redirect
windows according to the GTK+ API reference) wouldn't be possible. You
can try the following pygtk code snippet with compiz, the window will
still fade in:

 import gtk
       
 win = gtk.Window(gtk.WINDOW_POPUP)
 win.set_default_size(100, 100)
 win.move(60,100)

 win.realize()
 win.window.set_override_redirect(True)

 win.show_all()
 gtk.main()

Cheers,
Denis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

On 10/3/07, Denis Washington <dwashington@...> wrote:
> Yes, override-redirect windows are also faded in and out

Right, what I'm asking is whether we have any precedent for *hints* on
these windows.

It's kind of a weird thing, because override redirect has always been
the "don't mess with my window at all" escape hatch. Metacity for
example won't even create an inside-WM representation for these
windows.

For compositing managers, I guess if it didn't mess with your window
at all then the window wouldn't be drawn on the screen. But I'm
wondering to what extent the escape hatch still exists. Do we have in
the EMWH these days something like "override redirect causes the WM to
ignore a window for purposes of resizing, stacking, and window
navigation; however, override redirect has no effect on compositing
the window"?

Anyway - regarding the hint proposal, one suggestion is to come up
with a more descriptive name than AUXILIARY, such as VISUAL_EFFECT.
Then in defining what the WM should do with this window, spell out
that the CM should render the window "as is" - which is almost saying
"do the equivalent of override redirect for compositing, since
override redirect itself does not apply to compositing" - that is,
composite this window literally without overriding anything. I don't
know. Anyway, it needs to be precisely specified what you want the CM
to do and not do.

I'm not sure whether out-of-CM effects like this really work... it
seems possible to me that fancy effects spanning multiple X clients
essentially have to be in the CM.
Depends on whether you can adequately specify what an arbitrary CM
should do with the window here.

I'm sure someone who hacks on CMs will be able to address your
proposal better than I can ;-)

Havoc
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

On 10/3/07, Havoc Pennington <hp@...> wrote:
> Hi,
>
> On 10/3/07, Denis Washington <dwashington@...> wrote:
> > Yes, override-redirect windows are also faded in and out
>
> Right, what I'm asking is whether we have any precedent for *hints* on
> these windows.

I believe that is what the DROPDOWN_MENU, POPUP_MENU, TOOLTIP,
NOTIFICATION, COMBO, and DND window types are for right now.  So, this
would be an additional use-case, above and beyond these others, for
override-redirect windows.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Matthias Clasen]

On Wed, 2007-10-03 at 20:59 -0400, Dana Jansens wrote:

> On 10/3/07, Havoc Pennington <hp@...> wrote:
> > Hi,
> >
> > On 10/3/07, Denis Washington <dwashington@...> wrote:
> > > Yes, override-redirect windows are also faded in and out
> >
> > Right, what I'm asking is whether we have any precedent for *hints* on
> > these windows.
>
> I believe that is what the DROPDOWN_MENU, POPUP_MENU, TOOLTIP,
> NOTIFICATION, COMBO, and DND window types are for right now.  So, this
> would be an additional use-case, above and beyond these others, for
> override-redirect windows.

Yes, indeed. GTK+ sets these hints on the corresponding
override-redirect windows that it creates, for the benefit of
compositing managers.

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Wednesday 03 of October 2007, Havoc Pennington wrote:
> Hi,
>
> On 10/3/07, Denis Washington <dwashington@...> wrote:
> > Yes, override-redirect windows are also faded in and out
>
> Right, what I'm asking is whether we have any precedent for *hints* on
> these windows.

 Yes, right in the spec, since some time :). There's e.g. a short
section "Override-redirect windows" mentioning them.

> It's kind of a weird thing, because override redirect has always been
> the "don't mess with my window at all" escape hatch. Metacity for
> example won't even create an inside-WM representation for these
> windows.
>
> For compositing managers, I guess if it didn't mess with your window
> at all then the window wouldn't be drawn on the screen. But I'm
> wondering to what extent the escape hatch still exists. Do we have in
> the EMWH these days something like "override redirect causes the WM to
> ignore a window for purposes of resizing, stacking, and window
> navigation; however, override redirect has no effect on compositing
> the window"?

 No, there's nothing like that in the spec, but it's kind of logical that a WM
wouldn't resize or Alt+Tab to an override-redirect window. However, in fact,
probably having something like that stated explicitly would be against the
usual spirit of X of not forbidding anything just in case one day somebody
comes up with a way of doing it that makes sense ;).

> Anyway - regarding the hint proposal, one suggestion is to come up
> with a more descriptive name than AUXILIARY, such as VISUAL_EFFECT.
> Then in defining what the WM should do with this window, spell out
> that the CM should render the window "as is" - which is almost saying
> "do the equivalent of override redirect for compositing, since
> override redirect itself does not apply to compositing" - that is,
> composite this window literally without overriding anything. I don't
> know. Anyway, it needs to be precisely specified what you want the CM
> to do and not do.

 I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally all
such effects should be in the CM, but in reality I would be fine with having
this VISUAL_EFFECT.

> I'm not sure whether out-of-CM effects like this really work... it
> seems possible to me that fancy effects spanning multiple X clients
> essentially have to be in the CM.
> Depends on whether you can adequately specify what an arbitrary CM
> should do with the window here.
>
> I'm sure someone who hacks on CMs will be able to address your
> proposal better than I can ;-)

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Denis Washington]

On Thu, 2007-10-04 at 13:20 +0200, Lubos Lunak wrote:

> On Wednesday 03 of October 2007, Havoc Pennington wrote:
> > Hi,
> >
> > On 10/3/07, Denis Washington <dwashington@...> wrote:
> > > Yes, override-redirect windows are also faded in and out
> >
> > Right, what I'm asking is whether we have any precedent for *hints* on
> > these windows.
>
>  Yes, right in the spec, since some time :). There's e.g. a short
> section "Override-redirect windows" mentioning them.
>
> > It's kind of a weird thing, because override redirect has always been
> > the "don't mess with my window at all" escape hatch. Metacity for
> > example won't even create an inside-WM representation for these
> > windows.
> >
> > For compositing managers, I guess if it didn't mess with your window
> > at all then the window wouldn't be drawn on the screen. But I'm
> > wondering to what extent the escape hatch still exists. Do we have in
> > the EMWH these days something like "override redirect causes the WM to
> > ignore a window for purposes of resizing, stacking, and window
> > navigation; however, override redirect has no effect on compositing
> > the window"?
>
>  No, there's nothing like that in the spec, but it's kind of logical that a WM
> wouldn't resize or Alt+Tab to an override-redirect window. However, in fact,
> probably having something like that stated explicitly would be against the
> usual spirit of X of not forbidding anything just in case one day somebody
> comes up with a way of doing it that makes sense ;).
>
> > Anyway - regarding the hint proposal, one suggestion is to come up
> > with a more descriptive name than AUXILIARY, such as VISUAL_EFFECT.
> > Then in defining what the WM should do with this window, spell out
> > that the CM should render the window "as is" - which is almost saying
> > "do the equivalent of override redirect for compositing, since
> > override redirect itself does not apply to compositing" - that is,
> > composite this window literally without overriding anything. I don't
> > know. Anyway, it needs to be precisely specified what you want the CM
> > to do and not do.
>
>  I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally all
> such effects should be in the CM, but in reality I would be fine with having
> this VISUAL_EFFECT.

Yes, VISUAL_EFFECT is definitely a better name.

Cheers,
Denis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Denis Washington]

> > Anyway - regarding the hint proposal, one suggestion is to come up
> > with a more descriptive name than AUXILIARY, such as VISUAL_EFFECT.
> > Then in defining what the WM should do with this window, spell out
> > that the CM should render the window "as is" - which is almost saying
> > "do the equivalent of override redirect for compositing, since
> > override redirect itself does not apply to compositing" - that is,
> > composite this window literally without overriding anything. I don't
> > know. Anyway, it needs to be precisely specified what you want the CM
> > to do and not do.
>
>  I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally all
> such effects should be in the CM, but in reality I would be fine with having
> this VISUAL_EFFECT.
>

The VISUAL_EFFECT type should be probably defined as "compositing
windows should not perform visual tranformations on this type of window"
or the like. But I'm no spec writer, somebody who knows what I mean will
likely find a better way to state that in the spec. ;)

Denis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tuomo Valkonen]

On 2007-10-04, Lubos Lunak <l.lunak@...> wrote:
>  I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally all
> such effects should be in the CM, but in reality I would be fine with having
> this VISUAL_EFFECT.

I think it is simplest, cleanest, and most compatible for a compositing
manager to _ignore_ override_redirect windows, just like the window
manager does, _unless_ it has further information to the contrary. That
is, it should only mess with their presentation if something like a
_NET_WM_WINDOW_TYPE attribute has been set to indicate that the window
is really a menu or something else that the application wants the rest
of the world to know about and mess with.

(I also think that menus should actually be managed by the window
manager or fit within their parent window to avoid grabbing all
input. That doesn't really leave many cases of override-redirects
that the compositing manager should mess with.)

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Denis Washington]

On Fri, 2007-10-12 at 11:59 +0000, Tuomo Valkonen wrote:

> On 2007-10-04, Lubos Lunak <l.lunak@...> wrote:
> >  I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally all
> > such effects should be in the CM, but in reality I would be fine with having
> > this VISUAL_EFFECT.
>
> I think it is simplest, cleanest, and most compatible for a compositing
> manager to _ignore_ override_redirect windows, just like the window
> manager does, _unless_ it has further information to the contrary. That
> is, it should only mess with their presentation if something like a
> _NET_WM_WINDOW_TYPE attribute has been set to indicate that the window
> is really a menu or something else that the application wants the rest
> of the world to know about and mess with.

That might really be a nice and clean solution. Maybe this needs a
clarification in the current EWMH spec? (compositing managers _must_
deal with all windows to display them if I understand that correctly, so
override-redirect should not only mean "ignore this window" as
compositing managers can't ignore them completely, but "don't do
anything with them")

Denis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Friday 12 of October 2007, Tuomo Valkonen wrote:

> On 2007-10-04, Lubos Lunak <l.lunak@...> wrote:
> >  I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally
> > all such effects should be in the CM, but in reality I would be fine with
> > having this VISUAL_EFFECT.
>
> I think it is simplest, cleanest, and most compatible for a compositing
> manager to _ignore_ override_redirect windows, just like the window
> manager does, _unless_ it has further information to the contrary. That
> is, it should only mess with their presentation if something like a
> _NET_WM_WINDOW_TYPE attribute has been set to indicate that the window
> is really a menu or something else that the application wants the rest
> of the world to know about and mess with.

 I would agree that it's the simplest and cleanest solution, but I'm not sure
about most compatible. Currently many applications still don't support the
new window types and e.g. fading them as the same way like doing with
applications that do set the types would be desireable for consistency. The
cases when one would want to avoid that should be rare.

 Also, _NET_WM_WINDOW_TYPE_NORMAL is such a strange vague thing :(, I don't
see how such rule would fix this specific case anyway. Let's say Plasma wants
to create such animation toplevel override-redirect window. Since none of the
specific window types fits, it will be _NET_WM_WINDOW_TYPE_NORMAL and KWin
will apply effects to it anyway. Whereas with _NET_WM_WINDOW_TYPE_EFFECT it
will be clear that nothing like that should happen.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tuomo Valkonen]

On 2007-10-12, Lubos Lunak <l.lunak@...> wrote:
> Currently many applications still don't support the
> new window types

So? They don't support that shit, so the compositing manager doesn't
really know what it should do to their windows. Tough. Better not mess
with them then.

The originally proposed AUXILIARY type as opposed to EFFECT seems
more suited to working around crappy toolkits or such forcing a
window type being specified. override-redirect windows _are_
normally "auxiliary" windows that the WM or the compositing
manager shouldn't mess with. (Although some of them, such as
menus, would arguably be better as managed windows.) So an
AUXILIARY type would simply tell it again that "yes, this really
is an auxiliary override-redirect window that you shouldn't mess
with although this hint is set for some strange reason".

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Denis Washington]

On Sat, 2007-10-13 at 10:08 +0000, Tuomo Valkonen wrote:

> On 2007-10-12, Lubos Lunak <l.lunak@...> wrote:
> > Currently many applications still don't support the
> > new window types
>
> So? They don't support that shit, so the compositing manager doesn't
> really know what it should do to their windows. Tough. Better not mess
> with them then.
>
> The originally proposed AUXILIARY type as opposed to EFFECT seems
> more suited to working around crappy toolkits or such forcing a
> window type being specified. override-redirect windows _are_
> normally "auxiliary" windows that the WM or the compositing
> manager shouldn't mess with. (Although some of them, such as
> menus, would arguably be better as managed windows.) So an
> AUXILIARY type would simply tell it again that "yes, this really
> is an auxiliary override-redirect window that you shouldn't mess
> with although this hint is set for some strange reason".
>

The problem currently is that we desire many windows which are defined
as override-redirect windows (menus for instance) to be animated anyway
(e.g. menus and tooltips should fade in and out). So, in the current
situation, an AUXILIARY/EFFECT window type would might be a redundancy
semantically speaking, but a needed one.

Denis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On so 13. října 2007, Tuomo Valkonen wrote:
> On 2007-10-12, Lubos Lunak <l.lunak@...> wrote:
> > Currently many applications still don't support the
> > new window types
>
> So? They don't support that shit, so the compositing manager doesn't
> really know what it should do to their windows. Tough. Better not mess
> with them then.

 No, not really. Pretending some applications don't exist may be an acceptable
practice for Ion, but I don't think I'd get away with it in KWin, and I don't
think I'd be alone.

> The originally proposed AUXILIARY type as opposed to EFFECT seems
> more suited to working around crappy toolkits or such forcing a
> window type being specified. override-redirect windows _are_
> normally "auxiliary" windows that the WM or the compositing
> manager shouldn't mess with. (Although some of them, such as
> menus, would arguably be better as managed windows.) So an
> AUXILIARY type would simply tell it again that "yes, this really
> is an auxiliary override-redirect window that you shouldn't mess
> with although this hint is set for some strange reason".

 Are we still talking about ignoring windows that don't have any window type
set and applications that don't set those window types, including any
possible new extension like AUXILIARY?

 Besides, I still don't see how all this should solve the TYPE_NORMAL problem
I mentioned in my previous mail, which I actually consider to be more
important part of it.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tuomo Valkonen]

On 2007-10-13, Lubos Lunak <l.lunak@...> wrote:
>  Besides, I still don't see how all this should solve the TYPE_NORMAL problem
> I mentioned in my previous mail, which I actually consider to be more
> important part of it.

I guess you didn't read what I wrote. But, oh, well, go ahead and
design your highly specific ultra-complex kludgy WIMPshit crap like
you've always done. After all, world domination by Gnome and KDE
shit is more important than keeping things nice, clean and abstract,
and fostering alternatives.

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Sat, Oct 13, 2007 at 07:19:02PM +0000, Tuomo Valkonen wrote:
> I guess you didn't read what I wrote. But, oh, well, go ahead and
> design your highly specific ultra-complex kludgy WIMPshit crap like
> you've always done. After all, world domination by Gnome and KDE
> shit is more important than keeping things nice, clean and abstract,
> and fostering alternatives.

Umm, Tuomo, wtf.  AFAICT in regards to _EFFECT vs. override-redirect,
you're arguing *against* having clients provide fine-grained
information to the WM (i.e., letting the WM distinguish between "I am
a legacy override-redirect window, which could have any number of
intended semantics" and "I am *this sort* of override-redirect
window").  This approach gives the WM strictly more ability to make
intelligent and flexible policy decisions.  What you would prefer is
to take away that information, and then to handle the use case stated,
you want the spec to impose the one policy (!) that should be used for
o-r windows in all cases.  And this is in the name of abstraction and
fostering alternatives?  I don't get it.

(And ftr, I'm one of those people who prefers the alternatives.)

-- Nathaniel

--
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

Nathaniel Smith wrote:

> Umm, Tuomo, wtf.  AFAICT in regards to _EFFECT vs. override-redirect,
> you're arguing *against* having clients provide fine-grained
> information to the WM (i.e., letting the WM distinguish between "I am
> a legacy override-redirect window, which could have any number of
> intended semantics" and "I am *this sort* of override-redirect
> window").  This approach gives the WM strictly more ability to make
> intelligent and flexible policy decisions.  What you would prefer is
> to take away that information, and then to handle the use case stated,
> you want the spec to impose the one policy (!) that should be used for
> o-r windows in all cases.  And this is in the name of abstraction and
> fostering alternatives?  I don't get it.

I agree with you entirely, though some points have been made (or
almost made, at least) that should not be ignored. The window manager
should not be concerned with override-redirect windows at all, and
these composite manager features really have no business in the
wm-spec. Composite managers should have their own spec.

For that matter, why are window managers being made with composite
managers built in, anyway? The world would be a much better place if
people could choose composite effects independently from the window
manager (you wouldn't believe how often I get asked "can I use fluxbox
in beryl/compiz?"). With that goal in mind, what information is the
composite manager relying on that it can't get from EWMH? Making this
information available should be our primary focus, IMO.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Sat, Oct 13, 2007 at 03:52:13PM -0700, Mark Tiefenbruck wrote:
> I agree with you entirely, though some points have been made (or
> almost made, at least) that should not be ignored. The window manager
> should not be concerned with override-redirect windows at all, and
> these composite manager features really have no business in the
> wm-spec. Composite managers should have their own spec.

Actually, I disagree with you on this (though my previous probably
should have been more careful with throwing around the word "WM").  I
think there should be one spec that describes the interface between
"managers" (i.e., things that impose policy on how disparate
apps interact to create a single UI) and "clients" (i.e., things that
policy is imposed on, and that provide the hints needed to make that
policy smart).

EWMH is already a spec for WMs, pagers, taskbars, alt-tab-style
task-switchers, icon boxes, etc.  Historically there's been major flux
in the extent to which these different UI elements are managed within
a single process or not.

> For that matter, why are window managers being made with composite
> managers built in, anyway? The world would be a much better place if
> people could choose composite effects independently from the window
> manager (you wouldn't believe how often I get asked "can I use fluxbox
> in beryl/compiz?"). With that goal in mind, what information is the
> composite manager relying on that it can't get from EWMH? Making this
> information available should be our primary focus, IMO.

The problem is... which composite effects are you talking about?
Wobbly windows, so WMs should start exposing "estimated velocity of
window movement" via EWMH-hints?  (It'd be an awesome task-switching
storm too :-/.) Windows on the face of a see-through cube, so we need
to start exposing "3d geometry of virtual desktop layout" through
EWMH, I guess as some kind of triangle-mesh?

I don't think it makes sense to draw a bright line and say WMs and CMs
are different, and always shall be.  (And more to the point, I don't
think it's a spec like EWMH's job to draw that line.)  Compositing is
really just another primitive in our display model; if the WM is the
best place to use that primitive to achieve certain effects, then so
be it.

-- Nathaniel

--
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tuomo Valkonen]

On 2007-10-13, Nathaniel Smith <njs@...> wrote:
> Umm, Tuomo, wtf.  AFAICT in regards to _EFFECT vs. override-redirect,
> you're arguing *against* having clients provide fine-grained
> information to the WM

Forced fine-grained information adds complexity, and isn't needed in
this case. But the EWMH folks -- well, all of FDO really -- have never
cared about such things. EWMH and FDO shit (XEmbed is another example)
is all about highly WIMPshit-specific fine-grained information from
WIMPshit apps to WIMPshit WMs, with little regard for abstraction
and simplicity.

The model I propose, where override-redirect windows are not messed
with by the compositing manager unless additional information is
available, is precisely one where the information at the highest
level is abstract, but more fine-grained hints may be provided.
But what the folks here want is that apps must always provide
the high-specific EWMH information for the CM to not arbitrarily
mess with their override-redirect windows.

(Override-redirect should be the exact opposite of managed windows:
managers don't mess with them, whereas they're free to do what they
want with managed windows -- an extremely wise decision in the ICCCM,
one that probably wouldn't be made to day -- no, they Windows-inspired
kids would just let apps manage their own windows. Many programs do
indeed fight against this user-friendly (sic) policy these days,
thinking they should manage their windows, and yet don't make them
override-redirects. Of course, override-redirect should not be used
to simply write your application-specific WM.)

--
Tuomo

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list