client side decorations

[Russell Shaw]

On 07/05/11 03:32, Bill Spitzak wrote:
> 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.

"not use overlapping windows" ?

Many applications use a bunch of top-level windows instead of MDI windows
within windows. That's a limitation of the widget toolkits. It can be done
ok with Xlib. If "internal" windows need maximize/minimize buttons on a
title bar, the application or widget toolkit will need to draw and manage
them itself.