client side decorations

[Sam Spilsbury]

On Fri, May 6, 2011 at 8:18 AM, 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.

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. What we currently have is a situation where
applications are re-parented at an offset into frame windows (which is
a good idea for a number of other window management policy reasons)
and all those applications ever need to care about is drawing their
content. With the solution I proposed, we're going to have the
situation where either (a) windows don't claim to support the window
manager drawing their background, so we just revert to the old
behaviour of re-parenting the application in at an offset to make room
for the decoration or (b) the application claims to support the
specification, and does NOT draw it's background (only widgets on a
transparent surface), specifies either a background pixmap or uses the
default and gets reparented into the frame window at 0x0 so it can
draw whatever it wants in the titlebar area.

I really don't think lines of code is a fair comparison here,
especially for ICCCM window objects since this specification handles a
lot more than just decorations (it also handles a lot of the
client-to-window manager communication, which are really just
work-a-rounds for broken design in X).

I would imagine that in most cases, most clients are only going to
want a simple decoration, consistent with everything else to provide a
close, minimize and maximize button and then call it a day. It's only
in extremely rare cases where we have clients the try to differentiate
themselves by "optimizing" the chrome in ways that they think fits the
UX. And even in this case, I believe it is the role of the window
manager to confine how much this should be done and how much
consistency there is for the user. Sure, chromium is easy to use these
days because the chromium developers are interested in ensuring that
there is consistency in their application. However, there are still
applications which present a broken user experience to the user
(canonical example: windows media player), OR there are times when the
window manager wishes to change policy on how things are positioned
(eg, the famous "buttons on the left" case) and then we need to wait
on every single application to play catch-up to be consistent. Even if
we had a separate library to describe and even draw the decorations,
there is no way that we can enforce applications to use this library,
and the chances are that there are going to be popular applications
that will *not* use this library.

>
> 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.

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.

>
> 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.

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.
>
> 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.

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.
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.

Kind Regards,

Sam

>



-- 
Sam Spilsbury