unity-design team mailing list archive

[Cody Russell <bratsche@xxxxxxxxx>]

On Thu, 2010-06-10 at 10:28 +0800, Sam Spilsbury wrote:
> If you're talking about reparenting, then pretty much every window
> manager does this. Including metacity and mutter. Compiz sort of does
> in upcoming versions, although for a while now it has used a hack
> where decorations are drawn as an auxiliary texture around windows.
> 
> In every usecase where this applies (remember that there is always the
> fallback "i can't do this" ewmh hint that wouldn't be read), I'm sure
> that for every window manager that draws a decoration window, it is
> not incredibly difficult to draw a few more pixels.
> 
> Unlike adding a bunch of workarounds to cope with CSD. 

I'm not developing a window manager, and so I guess maybe my perspective
is a little different than someone who approaches from the angle that
applications are always drawn that way.  I guess what I was getting at
is that it seems unintuitive to me that an "application window" is drawn
by two different processes.  That is, the window geometry and the pixels
that are within that geometry are determined by two separate processes.
In the model that seems more intuitive to me, the WM would be
responsible more for controlling (positioning, resizing, maintaining
z-order), the toolkit and theme engine would be responsible for
determining the window's desired geometry and content to reflect the
application state.

There are certain things theme-wise which are not obvious (to me,
anyway) how to do when two processes are drawing the application window.
You might want to have a subtle gradient that is slightly curved in a
')' shape the full height of the window, and that curve's control points
are determined by the shape of the window.  To manage something like
that between two processes sounds slightly tricky to me, but to do it in
a generic way which is easily done by a theme sounds even trickier, and
then to further try to do it in a way which is in any way compatible
with different window managers is probably next to impossible.  This is
open source, so nothing is really impossible.. but trying to solve those
kind of problems sounds like much more work to me than solving the issue
of exporting regions to the WM which describe where a close button
exists for the situation of when the application freezes.

But perhaps it makes sense for CSD if we try to make an additional spec
hint that asks the WM whether it's okay for the application to draw its
own decorations.  This would be separate from the MWM hint that specify
to turn decorations off (for reasons which hopefully become clear soon).
Then KWin could implement this simple hint so as to politely tell the
application, "No, you will not function as you're expecting to in this
environment if you try to handle decorations yourself."  Then GTK+, in
an effort to be a good citizen, would refuse to run in CSD mode when
this happens, and even if the current theme implements CSD features GTK+
would fall back to traditional WM decorations.  Then Gnome and Ubuntu
could have a little freedom to experiment with CSD in GTK+ and Mutter,
and we wouldn't be stepping on anyone else's toes.

/ Cody