client side decorations

[Bill Spitzak]

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.