>>>>> "Rob" == Robert Nation 885-9815 <rnation_at_mansvr.sanders.lockheed.com> writes:
>> - control over 3d look of borders (like width of shadow)
>> - separate control over border width and control handle width
Rob> I'm not sure what the 2nd option in this list means,
I meant being able to set the sidebara to one width and the corner
(which is what I meant to type, not 'control') handles to another,
like how olwm has thick corners and thin sides with no shadow.
Rob> but please note that the mwm-style has some items (titlebar) with
Rob> a 1 pixel highlight/ shadow on the top and sides, and a 2 pixel
Rob> shadow on the bottom.
Actually, I hadn't noticed that before... I don't really use the MWM
lookalike features that often.
But I didn't mean for for the first line above to control the borders
of the titlebar & buttons, just for the sidebars & corners. The
button look could be controlled via the pixmaps for buttons, and the
titlebar via the titlebar style options (which would have to account
for the MWM style).
Rob> Also, note that any dynamic configuration (while generally good)
Rob> will slow down the redraw operatation just a little.
Right, which is why I'd like any proposed changes to be as simple as
possible, so as not to impact performance.
Honestly, I don't care if fvwm can look like any other window managers
or not. I like fvwm's look the way it is, but it was the other
features (and the fact that it was so small) that made me want to use
it initially. And I plan to keep it that way - as small as possible
and as powerful as possible too, only adding things to enhance it's
"value" without bloating it.
Rob> Now, I've been thinking about the "module to do decorations". You
Rob> could have fvwm re-parent the application window (use the 2-level
Rob> reparenting that it uses now, but leave out the title-bar,
Rob> buttons, side-bars, and corners. This would leave a decor-less
Rob> frame in which a module would work. The module would tell fvwm
Rob> how big to make the frame, and where to put the window inside the
Rob> frame, and the module could create its own windows within the
Rob> frame for decoration. This would not be unnecessarily slow, since
Rob> the module would do its own redraws, and get expose events for
Rob> its own windows. Note that the module would also have to handle
Rob> receipt of and processing for all the actions that are bound to
Rob> window decorations.
Rob> This is a very complicated undertaking, of course.
Yes, it certainly doesn't seem trivial...
I was thinking about just adding the window id's for the titlebar &
buttons to the module communication protocol, to allow the modules to
play with those windows. I was hoping that would be almost enough,
but perhaps not.
Chuck
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Dec 18 1995 - 10:26:08 GMT