Please Don't Use Cleint Side Window Decorations

[Dana Jansens]

On Mon, Nov 15, 2010 at 7:47 PM, nerdopolis
<bluescreen_avenger at verizon.net> wrote:
> On Sunday, November 14, 2010 07:06:51 pm you wrote:
>> On Sun, Nov 14, 2010 at 11:55 PM, nerdopolis
>>
>> <bluescreen_avenger at verizon.net> wrote:
>> > On Sunday, November 14, 2010 07:53:40 am Sam Spilsbury wrote:
>> >> On Sun, Nov 14, 2010 at 8:25 PM, Fabian Henze <flyser42 at gmx.de> wrote:
>> >> > Hi all,
>> >> >
>> >> > I am rather new to all this and I don't know all the facts, so please
>> >> > forgive me, if my concerns are stupid or not valid at all.
>> >> >
>> >> > On Thu 04 Nov 2010 04:22:37-PDT, Justin Lee wrote:
>> >> >> In considering consistent look and feel issue of window decorations
>> >> >>
>> >> >> due to client-side window decoration, maybe we shouldn't let the
>> >> >>
>> >> >> toolkit (Qt/GTK) render decorations nor let the app render its
>> >> >>
>> >> >> decoration directly. Rather, there should be a separate, independent
>> >> >>
>> >> >> library (may be called libWinDeco) dedicated to render window
>> >> >>
>> >> >> decorations. Whenever an app needs to render its decoration, it calls
>> >> >>
>> >> >> libWinDeco to help the job. Then this becomes a programming
>> >> >>
>> >> >> convention/protocol to each Wayland app that Wayland app should use
>> >> >>
>> >> >> libWinDeco to render decoration by default (unless the app want to be
>> >> >>
>> >> >> maverick, it can disregard the convention and render its decoration
>> >> >> by
>> >> >>
>> >> >> itself directly). If all Wayland apps follow the convention, they
>> >> >> will
>> >> >>
>> >> >> have consistent look and feel of window decorations as all the
>> >> >>
>> >> >> decorations are rendered by the same code, i.e. libWinDeco.
>> >> >>
>> >> >>
>> >> >>
>> >> >> By this way, highly customizable window appearances are still
>> >> >> possible
>> >> >>
>> >> >> if libWinDeco is designed to be configurable. Where 'configurable'
>> >> >>
>> >> >> means behaviors of libWinDeco are controlled by a single, universal,
>> >> >>
>> >> >> system-wide config file (which specifies button attributes, title bar
>> >> >>
>> >> >> appearances etc.).
>> >> >
>> >> > [..]
>> >> >
>> >> >> libWinDeco should be designed to be easy to use in order to make
>> >> >>
>> >> >> programmers willing to follow the convention therefore glitchy apps
>> >> >>
>> >> >> become rare.
>> >> >
>> >> > This seems like a much more complicated and error-prone solution
>> >> > compared to server-side window decorations (sswd ;)). I am wondering
>> >> > what you gain compared to sswd? In other words: How is this an
>> >> > improvement over the current design of X.org?
>> >> >
>> >> > Todays X applications can already hide their window decorations and do
>> >> > their own stuff, but this technique is not used very often (at least
>> >> > for full-blown application windows) at the moment, so why make it the
>> >> > default?
>> >>
>> >> Since we don't need to re-parent windows, any compositor (for example
>> >> a mutter based or compiz based libwayland-server) would be able to
>> >> draw the window decorations and get their input just fine. The clients
>> >> don't need to worry about their own decorations. These servers can
>> >> also handle drawing the background of the window to (so the buffers
>> >> that are passed to us are actually ARGB buffers with an 100%
>> >> transparent background).
>> >>
>> >> Regards,
>> >>
>> >> Sam
>> >>
>> >> > --
>> >> >
>> >> > regards,
>> >> >
>> >> > Fabian Henze
>> >> >
>> >> > _______________________________________________
>> >> > wayland-devel mailing list
>> >> > wayland-devel at lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>> >
>> > That definantly sounds better... I already had the Terminal cleint freeze
>> > up, and become unmovable over a whole bunch of windows...
>> >
>> > But how can it insure that we won't get two titlebars? If the client is
>> > drawing its titlebar, and if the sever is drawing its titlebar?
>>
>> We will install a hint to tell the client not to draw decorations.
>>
>> > And how will the server know to not put a titlebar on windows like popup
>> > menus?
>>
>> I would imagine there'd be something similar to EWMH's window types -
>> however for wayland this isn't really relevant as the menus would be
>> part of the application's buffer space anyways.
>>
>> > Some interface probably would need to be put into the protocol in order
>> > for this to work I think. Am I right?
>>
>> I would imagine there would need to be some kind of specification, but
>> this can be worked out once we have compositing managers and toolkits
>> ported.
>
> Awesome!
> With this, and the proposed NX style remote app fowarding ability, it seems we
> won't lose many X features...

Hello,

I think it is important to point out that this conversation has been
predicated entirely on the idea that window decorations and window
managers are the same thing.

Window management is - at its core - a filter for focus and window
manipulation requests.  It does not require that the WM also draw the
window decorations.  A window can initiate an move/resize just as well
as the WM itself can, via a request to the WM.  I think it would be a
big step to make this separation clear from the start, and have window
decorations separate from the WM functionality, wherever they end up.

Personally, I think toolkits could do a better job of rendering
decorations than the compositor could.

Secondly, there seems to be a belief that people would write wayland
applications without any toolkit - that wayland would be a toolkit in
essence, like Xlib is.  Also, similar to the demo apps that are
currently given.  But from what I see of the project, it would be
expected that applications would be developed using a reasonable
toolkit such as Qt or GTK, and thus those toolkits can provide all the
functionality clients are concerned about - such as threading for
window interaction and so on.  I don't see any reason to try push any
of that onto the compositor/WM.

Cheers,
Dana

-- 
http://openbox.org/