Please Don't Use Cleint Side Window Decorations

[nerdopolis]

On Monday, November 15, 2010 08:22:42 pm Dana Jansens wrote:
> 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

Hmm... I guess threading provided by a toolkit library would save users from a 
hung window because of a bug in the app that causes it to hang, but I guess 
the window can still hang if the entire procesess is suspended...

...Or if the app is rouge or something, and it does not use a toolkit and is 
written to hang a window on the screen...

but, by the looks of it, we will be able to chose cleint side or server side 
decorations which I guess is neat!