Please Don't Use Cleint Side Window Decorations

[nerdopolis]

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...