client side decorations

[Kristian Høgsberg]

Bill,

Thanks, you've basically made all my points for me.  I would add that
there are also lower level benefits to having the clients render the
decorations: when the entire window is in one texture, gl can do
bilinear filtering along the edge between the decorations and the
window contents, and we avoid jagged edges when the window is
transformed.

Also, the concern about not being able to close and moving hung apps
just seems blown out of proportion.  Yes, it's a neat feature that X
WMs can deal with this, but it's just about the only good thing in
that approach and it comes at the cost of all the complexity of trying
to sync the look and feel of two apps living in the same window.  And
realistically, how often is this really a problem?  I can't remember
when I last had to deal with an unresponsive application, and I think
I might have killed it form the panel or command line instead.  And
it's possible to work around this to some extent, by letting the app
specify a rect where the compositor should grab button 1 and start a
move, for example.  Perhaps a rectangle (ie, the close button) where
the application has to acknowledge buttons clicks within a second or
so, or it will be assumed unresponsive and the compositor can pop up
the "This guy is not responding, force quit?" dialog.

These ideas are still somewhat ad-hoc, clumsy, but still a lot simpler
than all the mechanisms we have now to enable the out-of-process
decorations model.

Kristian

On Thu, May 5, 2011 at 8:18 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> I believe client-side decorations are an absolute must.
>
> The amount of code necessary for an application to use an async protocol to
> describe how the window border should appear is greatly larger than that
> needed to just draw and handle events in the window border itself. In FLTK I
> would estimate the ICCCM code for the window object is about 5 times larger
> than the code for an otherwise similar MDI-like frame where FLTK draws
> everything. Handling resize and other events cleanly is a real mess, too,
> due to the async nature of them.
>
> Also such designs lock the user interface ideas into whatever existed at
> that time, an excellent example is Gimp's being forced to give up any
> attempt to make multiple windows because of window managers failing to
> implement the many controls it would need. Whether Gimp's idea is right or
> wrong, it would have been trivial to implement it if Gimp itself could
> control the appearance and raising and mapping of windows without the window
> manager messing with it.
>
> Attempts to make this api expandable makes things worse. On Windows it is
> possible to add some icons to them, and programs are doing so, but those
> icons are not obeying the "style" at all, and are making assumptions about
> the dimensions and colors of what is there, so the end result is that it is
> *less* possible to customize the window border appearance.
>
> The claim that users are confused by mismatched window borders is not backed
> by evidence either. It is pretty clear users can operate their media players
> and games despite them bypassing the system window borders, and are not
> having trouble with Chromium either.
>
> As for making them all look alike, this can and should be solved by whatever
> mechanism is used to make the buttons and scroll bars inside applications
> look alike. An "appearance library" that reads user configuration and has
> calls to draw buttons, window borders, etc, would work for this. Obviously
> the api complexity and inability to innovate problems would be there but at
> least they would synchronous! Also there would be many levels of access,
> allowing new api ideas to be implemented.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>