fvwm-workers@fvwm.org wrote:
In the next days I'll start to restructure the layout of the fvwm
frames. Specifically, the decor_w (decor window) will go away.
But I'm not yet sure what the correct new layout is. This is the
current situation:
The frame window has two children, the decor window and the parent
window:
An important attribute of the frame and parent windows is that they use
the root visual, the decor window uses the fvwm visual which may not be
the same. The root visual is necessary to allow transparent clients
(like rxvt) to work. If we remove the decor window the frame window will
have to change to the fvwm visual. I think this may upset some users
with old software that assumes the root visual is pseudocolor but maybe
it's time to move on and make them use something like VNC to handle
their old apps.
- Introduce 8 (eight) new windows, each two pixels thick and as
long as the border is thick. Although they'd sum up to only a
few pixels, there certainly is a memory penalty for eight
additional windows for each frame. On the other hand, window
shading and opaque resizing will become absolutely prefect (not
counting what the application does with its own windows).
I prefer the second solution, but I'm unsure about the memory
penalty.
I'm not sure of the point either, applications flicker like mad during
opaque resizing and unshading. How about filling the border with the
XorPixmap? There doesn't seem to be any usability in having 3D looking
borders during a resize, you can't press the border. Having the
XorPixmap/XorColor in the border would give a similar look to non-opaque
resizes.
If you are going to rewrite the border stuff could we have colorsets
supported?
Cheers,
Tim.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
