client side decorations
spitzak at gmail.com
Fri May 6 10:32:34 PDT 2011
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.
More information about the wayland-devel