Please Don't Use Cleint Side Window Decorations

[nerdopolis]

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?

And how will the server know to not put a titlebar on windows like popup 
menus?  

Some interface probably would need to be put into the protocol in order for 
this to work I think. Am I right?