fvwm-workers@fvwm.org wrote:
In the end all I have to do is to reactivate the code that we had
before I introduced the decor_w.
Don't do that, there were lots of minor bugs with the drawing of
FvwmBorders and noinset and hiddenhandles. I seem to remeber this all
started when someone (possibly me) removed the 1 pixel border (X-window
border not FVWM border) around the fvwm frame window for FVWMBorder
style windows. That was done to get rid of some of the wandering window
features of the 2.0 series of FvwmWinlist etc.
Removing the x-window border caused FvwmBorder windows to be drawn wrong
and the easiest way to fix the mess was to do all the drawing in one
window. Maybe it's time to ditch FvwmBorder style (I don't think it was
ever designed, it just turned out like it did and some people liked it).
This won't give you perfect unshade looks because the side handle
windows height will have to be the height required for unshaded looks
and so some of the handle marks won't show up.
No, this should work fine. If I set a tiled background pixmap,
the server always knows what to draw. We don't even need to
select Expose events on the border.
Agreed, not getting Expose events would be good.
If the corner handles are
set to normal size it will look a bit screwy in the first steps of
unshading.
The handle marks would have to be drawn into the corners. The
horizontal marks must be disabled when the window is shaded.
Oh I see. I thought that the sides would have a top and bottom shadow
around them. If the mark is drawn competely in the corners then it all
works fine.
The only problem I can think of is that the corners will have to be made
slightly bigger than they are. It will look the same but the point at
which the cursor changes from side to corner will be changed (no-one
will notice ;-)
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]
