Please Don't Use Cleint Side Window Decorations

[Justin Lee]

2010/11/4 nerdopolis <bluescreen_avenger at verizon.net>:
> I hope that you choose to not use Client Side window decorations, and here are
> a few reasons why:
>
> As I understand, you lose lots of customisation, such as special buttons to
> put on the windows (like window shade), changing the order of the buttons, or
> the appearance on the titlebars because now you are relying on the apps to
> provide them (and could result in different titlebars between QT/GTK apps).

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

> Client side window decorations also leave windowing "exposed" to glitchy apps
> or other problems. From what I can tell in Windows (that has client side
> window decorations) when an app freezes, its windows will be unable to move,
> unless a workaround is implanted (which you can see in Windows), and in
> Windows a modal window (like a progress window) prevents its parent window
> from moving.

libWinDeco should be designed to be easy to use in order to make
programmers willing to follow the convention therefore glitchy apps
become rare.

According to "Open Letter: The issues with
client-side-window-decorations"
(http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/):
> Closing hung applications: Currently there is an easy way to close a hung application.
> You click the close button in the decoration and the window manager will notice that
> the application does not response any more and will offer to forcefully close the
> window. With client-side window decoration this is impossible. The close button is
> part of the hung application
> and so the click event cannot be recognized. I do not expect users to know shortcuts
> like ctrl+alt+esc to forcefully close a window and so they will be stuck with an
> unresponsive application. In case the application is caught in an endless loop this
> would render the system unusable and an unexperienced user has only one choice:
> force the system to reboot by the power switch.

With client-side window decoration and libWinDeco, I think it's
possible. Because libWinDeco as a library can do almost anything,
including forking processes and creating threads. libWinDeco can
create an UI thread which is only responsible for handling UI events
such as closing window, moving window etc. and user's code should be
run in another worker thread. So even if user's code hangs, the UI
thread is still running and able to handle closing event then forcibly
terminate the app.