Please Don't Use Cleint Side Window Decorations

[nerdopolis]

On Thursday, November 04, 2010 04:39:12 am Corbin Simpson wrote:
> 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.
> 

But if the apps are programmed to draw their window decoration on one Wayland 
compositor, how will they "know" to not draw them with compositors that are 
already drawing server side ones?

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

XPRA AFAIK is not remotely rendering the apps. I think they are rendered 
locally, and then the window is exported to a remote display. I know X can 
still run as a Wayland client, but what if someone needs to run an app that 
runs on Wayland remotely?