> > a) With eXceed only the left-hand quarter of a window would be
> > repainted (this is a regression from the previous behavior where
> > the sizes would be all over the place).

Ah, this one seems to be a trivial oversight on our part.  In
awt_Toplevel.c in shellEH() ReparentNotify processing in the case of
OTHER_WM is entirely conditional on ifdef __linux__ and so frames got
some ridiculous insets (like 144 for bottom and right) and so swing
would obey and won't paint in those areas.

Removing the ifdef fixes this: e.g. SwingSet2 uses the whole frame.
ifdef __linux__ must die in WM related code!

N/A

Commit to fix in merlin-beta3 (serious painting problem, CAP).  
  xxxxx@xxxxx   2001-08-19




  xxxxx@xxxxx    2001-09-04

Ok, here's the problem.  All WMs I saw could be classified into a
single-reparenting and double-reparenting.

. single-reparenting
    The WM frame is a direct parent of a client top-level.
    Examples are: twm, olwm, sawfish, eXceed "native" WM.

. double-reparenting
    The client top-level is reparented to a window of exactly same
    size as the client itself.  That "lining" parent window is in turn
    a child of a WM frame for the client.
    Examples: dtwm, fvwm2, kwin, icewm ...

Linux default (OTHER_WM) is for double-reparenting WM, so it fails for
eXceed (a single-reparenting WM).  And the "default" case doesn't take
into account various ways that WM can use to shuffle the client into
its place.

Hmm, we *could* try to guess if we are under double-reparenting WM by
checking if the size of the parent matches the size of the window, but
that would probably give false positives for undecorated top-levels
under single-reparenting WMs.

======================================================================