Sam Spilsbury wrote:
Actually, I'm pretty sure in 99% of the cases out there the amount of code required for individual applications to have a window border using decorations done on the window manager side is going to be pretty much nil.
Size? Resize rules? Name? Icon name? Icon? Layer? Window group? Parent Window? Window role? Desktop? Hardly "nil". Take a look at how many pages of stuff is in the freedesktop.org window manager hints.
I really don't think this is an issue to do with client side decorations. If the window management policy can't handle the Gimp case correctly, then we need to revise our window management policy, where of course I'm open to ideas here.
"Window management policy" should also be client-side. I may not have been clear about that. The wayland compositer almost NEVER moves or raises or resizes a window. Clients do this in response to clicks or whatever. This would have made it TRIVIAL to implement Gimp the way they intended, as at no time would an image window raise above their toolbars, since they control both of them.
I think it is disgusting that for 30 years now we have been forced to not use overlapping windows, primarily due to the idiotic idea that the system should implement "click to top" (especially idiotic because of the incredible triviality of making the client do that). Every major application (including Gimp...) has been forced to use a single window with a "tiled" interior, and perhaps some pop-up "child" windows, because of this bug and am really really hoping Wayland will finally fix it.
To handle locked windows the compositor certainly can move, raise, lower and unmap them. It can do this if the user holds down certain keys, or if it detects the application is locked up, or if the user picks menu items.
On windows all we see is that applications can draw widgets inside the existing window border style. This works well in every case I've seen it - chromium, firefox, office, you name it.
No on Windows an application can add drawings to the title bar. It is pretty clear that applications are assuming the default Vista colors and button sizes and layouts when making these drawings, thus defeating theming.
We still have the problem of not having a universal toolkit to handle these things, and the reality of the matter is that a lot of proprietary applications are not going to want to use these toolkits.
I have no idea why you think that making the window borders match is all that is needed. What about the buttons and menus and toolbars and scroll bars and how editing is done? If this is important I would much rather see a solution that addresses all of these, rather than somehow saying the window borders are "special".
You cannot assume that there will be a universally adopted method to styling because we see on every single platform that there will *not* be one. The best way to enforce styling is to enforce it at the window manager level, so that the applications on the system actually obey what the user wants them to do, not some crazy idea that the application developer had.
And this is true on X and Windows today. People bypass the system and draw their own window borders. And the result is far worse than if the system was designed for this from the start. Lets not repeat these mistakes.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
