I guess wayland just *do not* want to render *anything*. Just composite composite composite composite composite composite composite<br><br><br><div class="gmail_quote">2010/11/16 Fabian Henze <span dir="ltr"><<a href="mailto:flyser42@gmx.de">flyser42@gmx.de</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello,<br>
<br>
On Tuesday, 16 Nov 2010, 01:22:42-UTC, Dana Jansens wrote:<br>
> I think it is important to point out that this conversation has been<br>
> predicated entirely on the idea that window decorations and window<br>
> managers are the same thing.<br>
><br>
> Window management is - at its core - a filter for focus and window<br>
> manipulation requests. It does not require that the WM also draw the<br>
> window decorations. A window can initiate an move/resize just as well<br>
> as the WM itself can, via a request to the WM.<br>
<br>
Could you elaborate, why this makes such a big difference? While I am aware of<br>
this distinction, I don't think it changes the situation at all.<br>
<br>
> I think it would be a<br>
> big step to make this separation clear from the start, and have window<br>
> decorations separate from the WM functionality, wherever they end up.<br>
<br>
The thing I don't understand about this whole discussion is: How would this be<br>
a big step? Why would you want to put this kind of logic in the client?<br>
<br>
I see numerous issues (please correct me if they are actually non-issues):<br>
1. advanced WM features won't work, like: disallow fullscreen for certain<br>
windows, always maximize a certain window, resize and move using user-defined<br>
hotkeys, snap to window borders.<br>
2. I just don't believe that GTK, Qt and all the minor toolkits will agree on<br>
standards for window decoration and behaviour. That would make the linux<br>
desktop even more inconsistent than it is now.<br>
3. Freezing clients, remote clients with a hung connection, stopped clients<br>
(CTRL-Z) may cause unmovable windows.<br>
4. code and bug (!) duplication in every toolkit.<br>
5. Malware, adware or scareware easily have way too much control about the<br>
graphical environment.<br>
<br>
To sum it up: I am concerned, that most features that make X11 window managers<br>
absolutely rock compared to Windows or OSX will be gone.<br>
<br>
><br>
> Personally, I think toolkits could do a better job of rendering<br>
> decorations than the compositor could.<br>
<br>
Why? and in which way?<br>
<br>
> Secondly, there seems to be a belief that people would write wayland<br>
> applications without any toolkit - that wayland would be a toolkit in<br>
> essence, like Xlib is. Also, similar to the demo apps that are<br>
> currently given. But from what I see of the project, it would be<br>
> expected that applications would be developed using a reasonable<br>
> toolkit such as Qt or GTK, and thus those toolkits can provide all the<br>
> functionality clients are concerned about - such as threading for<br>
> window interaction and so on. I don't see any reason to try push any<br>
> of that onto the compositor/WM.<br>
<br>
While I generally agree, I would like to point out that some applications<br>
might not require a toolkit. The most prominent example would be 3d games, but<br>
I think there are also other special purpose applications, that might not want<br>
to use a toolkit (like proprietary ports of windows software).<br>
<br>
btw. Has anyone ever asked the developers of the major desktop environments,<br>
windows managers and toolkits what they want?<br>
<br>
-- regards,<br>
<font color="#888888">Fabian Henze<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</font></blockquote></div><br>