client side decorations

[Bill Spitzak]

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.