Re: [Ayatana] Fwd: Open Letter: The issues with client-side-window-decorations

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

On Wed, Jun 9, 2010 at 9:52 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
> On Wed, 2010-06-09 at 12:28 +0800, Sam Spilsbury wrote:
>> > On Wed, 2010-06-09 at 10:18 +0800, Sam Spilsbury wrote:
>> >> As far as I know, with martin's NETWM idea to have the decorator paint
>> >> the "behind" of the window, this basically means that the window can
>> >> be reparented at 0x0 in the decoration, rather than the offset of the
>> >> decoration. This means that they are free to draw whatever they want
>> >> on top of the decoration (tabs, particles, etc) and have it all blend.
>> >>
>> >> Developers would be nice though *cough*.
>> >
>> > First, Sam thanks for explaining this.  I was confused on the NETWM
>> > idea.  And I guess that I still am a little.  If the application can
>> > draw over the decorations, what gain in consistency is there by not
>> > having the application theme draw the decorations themselves?  It seems
>> > like having two theme engines just for fun at that point.
>>
>> It allows for consistency of decorations while allowing consistency
>> between the application and the decoration. The whole idea is to have
>> a NETWM (or EWMH as it goes by) spec which the application sets when
>> only painting it's decoration on a window with an alpha channel (and
>> then not painting the usual grey or cream colored background). With
>> this setup, you'll get a consistent background look to all the
>> applications and a consistent background look between the decoration
>> and the window, whilst retaining the benefits of having the window
>> manager reparent the window into a decoration and have a consistent
>> control for all the windows.
>
> It seems like you'd still need two deeply integrated theme engines
> though.  And, in the case of multiple toolkits, deeply integrated
> between them as well if this was ever going to look in anyway
> reasonable.
>
> I just don't understand why having two theme engines is better than one.

Easy, we list out what the things we want with CSD are and what the
things that we don't want from CSD.

What we want with CSD:

 * Applications can draw stuff in the menubar area (windicators, tabs, etc)
 * Consistency between the application window area and the decoration area

What we don't want from CSD:

 * Windows not being re-parented properly, which leads to missing
functionality on most window manager (for example, KWin's window
tabbing feature absolutely depends on this). Nothing does so as far as
compiz goes as of yet, except for the "2D" mode, but I don't see the
difficulty in implementing kwin-like tabbing if there was demand for
it.
 * Inconsistency in window decorations
 * User unable to manage the window if it misbehaves
 * etc.

Now, we come up with a solution where we can get the stuff we want
with CSD, without actually having the design level drawback that CSD
introduces.

In this case, the solution is that the window manager (or window
decorator in the case of compiz), draws an opaque or semitransparent
stylized window which is the size of the window and the decorations
behind the application window. The decorator knows exactly what this
window looks like, so it handles all the blending between the
background of the window and the borders etc.

Next, the application draws all of it's controls, widgets, text boxes,
web views, text, etc, on to a transparent layer, which then gets
re-parented into 0x0 on the window decoration. The application knows
the correct offset of the titlebar and everything else and draws
widgets accordingly. The application would (presumably) know where the
offsets were because it would read window properties which specified
what these offsets were (something that can be worked on in EWMH
surely). The two seamlessly blend together.

Of course, there is the issue of the application just blending crap
because of inconsistencies with the window style and the application
style. Because in 99% of all usecases, the window style is just really
some kind of gradient or color behind the window, the application can
specify this in the window property, and the decorator will draw
appropriately.

What we have now is a solution where there are two windows - one which
is controlled by the window manager and can handle things such as
tabbing, closing locked up applications, specifying which buttons go
where etc while the application can draw whatever it wants wherever it
wants and have that blend in, and the application can also specify
certain background colors etc.

I'm not going to deny that this is more complex than the CSD route.
But I believe with some careful development, it could be implemented
reasonably easily in most window managers, ironically bar compiz, for
which the development branch I maintain. Pretty much every other
window manager does some form of reparenting and decoration drawing
already, this only need be extended to read/write a few hints,
reparent the window at 0x0 and draw into the entire "decoration
window", instead of just drawing into the visible borders where the
applications is not re-parented into.

This is all quite difficult to explain if you haven't really worked on
a window manager, but if you require clarification as to how the
decoration process works I'll be glad to explain it to you.

Kind Regards,

Sam.

>
>                --Ted
>
>



-- 
Sam Spilsbury