Re: window frames

[dominik vogt gmx de]

On Sat, Nov 30, 2002 at 06:29:09PM -0600, Gregory Merchan wrote:
[snip]

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

And some applications actually do that and the users hate it.  So,
my guess is that fewer users would be unhappy if the
override_redirect feature would have never been written.  Now, may
I remind you that you said "Nobody cares about that except window
manager developers."  Therefore you have to admit that users have
even more right to say "Nobody cares about that except application
developers".

That is no reason to make things worse.  You reason like "murder
already happens every day, so why not make it legal".

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

Not every user has the resources to install and use a toolkit.
Not everyone has a machine that is fast enough to use toolkit
code.  Not everyone wants to bloat her machine with tons of
features that she does not use.  Not every application uses the
toolkit, and thus, every window manager must support both.  And
since not every window manager supports the toolkit, every
application must support both.

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

Okay, maybe the application or window manager does not need to be
linked with each and every library, but the libraries still have
to be present on the system.  Even a small application like xeyes
would require that imlib, a utf8 lib, a unicode lib, gettext, etc.
are present on the system.

> The code to handle non-compliance should only be temporary; even now there
> is similar code to handle OpenLook, MWM, and EWMH hints.

You seem to believe that thousands of X applications and fifty or
more window managers will would eagerly adapt such a standard.
What makes you think that?

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

In what way does storing the data in a property reduce
communication?  Even if a single pixel in the decorations changes,
the whole property has to be written from scratch.  Or you scatter
the information over an awful lot of different properties which
does not help either.  And the client still has to fetch the new
data from the X server and tell the X server what to do.

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

Reparenting is *the* central feature that almost all window
managers share for very good reasons.  Without it:

 - Every client window must run at the highest possible depth
   used by the toolkit.  It will become impossible to save
   precious X server memory but using just black and white to
   draw the window contents (unless you like b/w window
   decorations, that is).
 - Likewise, all applications have to share the same colour map,
   especially if you want the WM to prepare pixmaps for use by the
   clients.
 - Likewise, all applications hae to use the same visual (same
   reason as above).
 - Window manager and application will compete for mouse and
   keyboard events on the client window.  It *may* be possible to
   make it work with button events (although I am sceptical), but
   it totally fails for keyboard events.  Let us assume the user
   has bound ctrl-m over a window bound to "move window".  The
   user presses ctrl-m over a shell window and the window manager
   starts moving the window.  But, oops, what is this?  The shell
   has already processed the ctrl-m (which is equivalent to
   pressing the "return" key).
 - I gues you will not care about this point, but huge parts of
   all compliant window managers would have to be rewritten from
   scratch.  Furthermore, since applications are allowed to ask
   the window manager to draw the decorations for them, they must
   be prepared to be resized just for the kicks of changing their
   decorations.  THey do not even have a reliable way to find out
   what their current client part geometry is.
 - You completely lose the ability to receive EnterNotify and
   LeaveNotify events on the decorations.  To find out in which
   part of the decorations the pointer is, MotionNotify events
   have to be tracked.  This forces horrendous amounts of data
   being sent from the X server.
 - Applications can not even assume that drawing the pixel at
   (x, y) two times changes the same pixel in their client part.
   Actually, they can *never* be sure that *any* drawing request
   has the desired effect because the wm might change the size of
   the decorations right before the X server processes the drawing
   request.
 - Applications can no longer use the XClearWindow() function as
   it will wipe out the decorations too.

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

Just curious:  are you trying to convince mostly WM developers on
this list that your ideas are good by saying "I do not care if it
hampers your work".  I mean, implying that we are all retarded if
we do not agree with you is not *really* going to help your cause.

Personally, I think many users would be very unhappy if I told
them: "Sorry, I can not write this feature because the ToOlKiT(TM)
does not support it.  Yes, I know it could easiliy be written
with plain Xlib calls."

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

Transparency effects would flicker because of the long
communication paths.  With X's inability to handle transparency
directly on the server, it must be calculated and set by either
the application or the window manager.  Since the communication
to trigger redrawing takes three network hops instead of one, the
transparency updates when a window is moved are considerably
slower.  This is most annoying when moving windows.

A good, flicker free implementation of window shading depends on
each part of the decorations being drawn into a separate window.  
In each step of the animation, each part of the decorations may
have to be redrawn.  Any such information has to be communicated
in each step of the application.

Now I almost hear you saying:  but it's only the thin vertical
borders that have to be changed.  But that is not true.  First,
there are several window managers that support window titles not
only at the top of the window but on the other three sides too.
And second, shading windows does not necessarily mean that the
window is shaded towards the title.  In fvwm you can shade a
window in any of the eight compass directions - and I find that
feature extremely useful.

> >  2) The application may be hung or busy.
> 
> This is the only reason offered which I know to be valid.

--

Anyway, since you propose such radical changes, it seems odd to me
that you do not propose to abandon the idea of window managers
completely and to move the corresponding code into a toolkit.
That would warrant some thoughts.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de