Re: window frames

[Gregory Merchan <merchan phys lsu edu>]

Rather than take the 17 reasons offered as a resounding "NO!", I'm cutting
it down. Rather than repeat some things, I'm rearranging the items. Many of
them are duplicates.


On Sun, Dec 01, 2002 at 12:20:32AM +0100, dominik vogt gmx de wrote:
> On Sat, Nov 30, 2002 at 01:36:45AM -0600, Gregory Merchan wrote:
> > Is there a technical reason for a client to not draw its window frames?
<snip>
> There are many reasons not to do this:


>  1) Applications can not be trusted to honour any requests.
>  3) The application may chose to ignore parts of the request on
>     purpose.
> 16) The whole interface would be abused by some application
>     programmers.

These are so already. Any client could set override redirection and cause
havoc on the desktop.


>  4) Every application has to have the code to draw the
>     decorations.
>  8a) It forces horrendous code duplication upon the clients.
>  8b) Alternatively, it forces the client to link with the same
>      libraries as the window manager (e.g. imlib, unicode or utf8
>      libs).
> 10) The client may run on a different machine which may not have
>     the proper libraries.
> 17) Compliant applications and window managers would have both,
>     the code to use that feature and the code that ignores it.

Code duplication would be handled as it is already handled - through the
use of toolkit libraries. The duplication would be little more than there
is already because of multiple toolkit libraries. The clients would not
need to link with window manager libraries; the drawing description would
be standardized and toolkits would draw accordingly. Modern toolkit
libraries already contain frame drawing code for non-X11 backends, though
conditional compilation probably causes that to be skipped for X11.
The code to handle non-compliance should only be temporary; even now there
is similar code to handle OpenLook, MWM, and EWMH hints.


>  5) Decoration drawing can be very, *very* complex.  Huge amounts
>     of data would have to be sent to clients.
>  6) It is *slow*:  the WM sends the description of the decorations
>     to the X server.  The X server sends them to the client.  The
>     client asks the X server to do the drawing.  This is at least
>     three times slower than when the WM does the drawing.
>  7) It wastes precious resources (bandwidth, cpu, possibly X
>     server memory).

The drawing data would be stored in a property on the root window or in
pixmaps and pulled by the client at initialization. Watching for a
PropertyNotify would handle changes. There is already substantial traffic
to communicate things which the client could handle, such as drawing its
resize handles, applicable buttons, and titles.


> 11) At the time the client tries to draw the decorations, the
>     windows that it has to draw into may already have been
>     resized, moved, unmapped, destroyed etc.
> 12) Either the client has to listen for Expose events on all frame
>     windows or the WM has to ask the client to redraw the
>     decorations every time is gets an Expose event.
> 14) The window manager is forced to export internal information
>     about its windows that may be abused in any way.

The client would be drawing into its own window, not a window manager's
reparenting window. Indeed, the reparenting windows would not be needed.


>  9) It severely limits WM development:  if a WM developer codes a
>     new feature in the decorations, the clients may not even be
>     able to draw its frames.

Nobody cares about that except window manager developers.


> 13) It would make transparency effects unbearably choppy.
> 15) Shading windows would flicker a lot.

I don't know how either of these depends on what does the frame drawing.


>  2) The application may be hung or busy.

This is the only reason offered which I know to be valid.


Since so many are still calling window frame controls "decorations",
just forget I mentioned this.


Ciao,
Greg Merchan