Please Don't Use Cleint Side Window Decorations

Corbin Simpson mostawesomedude at gmail.com
Thu Nov 4 01:39:12 PDT 2010


On Wed, Nov 3, 2010 at 7:14 PM, nerdopolis
<bluescreen_avenger at verizon.net> wrote:
> Seeing how the old mailing list is going to soon be shut down, I
> wanted to continue this discussion here.
>
> The latest information that I know about if Client Side
> Decorations will actually be used, is that it still has to be
> decided.
>
> I hope that you choose to not use Client Side window decorations, and here are
> a few reasons why:
>
> First, there is a good list here why client side window decorations should not
> be used: http://www.google.com/url?sa=D&q=http://blog.martin-
> graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-
> decorations/&usg=AFQjCNHGkwQHTa1YkBLEVn3P_PF53KhEdA
>
> 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).
>
> Not only that, but I think even window movement could be inconsistant, (such
> as edge resistance) because you are relying on the app to provide window
> movement. Could multple virtual desktops even be supported? What will manage
> effects like window wobbliness?
>
> These features are what many Linux/Unix users are now spoiled by, and IMHO
> make window managment better then Windows,
>
> 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.
>
> Lastly, with server side window managment, I think thats how XPRA
> http://en.wikipedia.org/wiki/Xpra is able to export apps windows, rootless on
> a remote display. In the other mailing list, someone suggested that this type
> of approach could be used to support something similar to ssh -X with wayland.
> seeing that XPRA relies on its own virual window manager, I don't know if this
> would be doable if it was cleint side.
>
> Sorry for the length. I don't mean to be overly critical with this, I just
> wanted to bring these issues into consideration, before its too late.

I think that you don't really get the point of Wayland. As I said
before, one could definitely build a Wayland-based compositor that
draws its own decorations instead of having its clients do it. There's
no reason that it must be one way or the other.

Additionally, Wayland doesn't have remote rendering because that would
defeat the entire purpose of being direct-rendered. If you want
network transparency, keep using X -- it's not like X is being
abandoned or deprecated. One can also run X *inside* of Wayland.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>


More information about the wayland-devel mailing list