client side decorations
spitzak at gmail.com
Thu May 5 17:18:23 PDT 2011
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
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.
More information about the wayland-devel