Please Don't Use Cleint Side Window Decorations

Fabian Henze flyser42 at gmx.de
Tue Nov 16 00:55:34 PST 2010


Hello,

On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote:
> 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. 

Could you elaborate, why this makes such a big difference? While I am aware of 
this distinction, I don't think it changes the situation at all.

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

The thing I don't understand about this whole discussion is: How would this be 
a big step? Why would you want to put this kind of logic in the client?

I see numerous issues (please correct me if they are actually non-issues):
1. advanced WM features won't work, like: disallow fullscreen for certain 
windows, always maximize a certain window, resize and move using user-defined 
hotkeys, snap to window borders.
2. I just don't believe that GTK, Qt and all the minor toolkits will agree on 
standards for window decoration and behaviour. That would make the linux 
desktop even more inconsistent than it is now.
3. Freezing clients, remote clients with a hung connection, stopped clients 
(CTRL-Z) may cause unmovable windows.
4. code and bug (!) duplication in every toolkit.
5. Malware, adware or scareware easily have way too much control about the 
graphical environment.

To sum it up: I am concerned, that most features that make X11 window managers 
absolutely rock compared to Windows or OSX will be gone.

> 
> Personally, I think toolkits could do a better job of rendering
> decorations than the compositor could.

Why? and in which way?

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

While I generally agree, I would like to point out that some applications 
might not require a toolkit. The most prominent example would be 3d games, but 
I think there are also other special purpose applications, that might not want 
to use a toolkit (like proprietary ports of windows software).

btw. Has anyone ever asked the developers of the major desktop environments, 
windows managers and toolkits what they want?

-- regards,
Fabian Henze


More information about the wayland-devel mailing list