> From: <chuck_hines_at_VNET.IBM.COM> (Charles Hines)
> Todd> So, if we could have the following controls over the
> Todd> boarderstyles:
> I've had similar (but simpler) thoughts from time to time. But it
> always just seems to be a lot of overkill. What I would perhaps like
> to implement:
> - control over 3d look of borders (like width of shadow)
would this be 'left - right - top - bottom' independent of each other? Or
maybe just simply 'left -right' as one adjustment and 'top-bottom' as another?
> - separate control over border width and control handle width
> - titlesytles like flat, sunk, raised, & justification controls
> - Xpm/bitmaps for buttons
> - cursorstyle patch (perhaps modified for use in Style commands to
> make it per window?)
could we add 'Xpm/bitmaps for menus' ? I have a feeling that if one were to
use a '1 column' xpm/bitmap it wouldn't cause that much (maybe I'm wrong)
overhead/code/memory to display...maybe I'm wrong...
corners are a definite 'need' to be able to look like other wm's. For
instance, the corners of olvwm, or the bottom two 'thingeys' at the corners
vs nothing at the corners at the top of the 'bowman' window manager...
imho, though..
> This should allow you to get relatively close to looking like pretty
> much any window border look you want. I don't feel that FVWM should
> have to be able to look exactly like any other window manager type
> program down to the exact pixel. If you can get close, that's good.
> This approach shouldn't bloat fvwm too badly, and a lot of that list
> is already on my TO-DO list.
> Comments? Anyone think I'm way off base with that?
Well, it all depends on where the functionality is placed. If we add code
to fvwm itself to allow modules to control the styles/decorations of windows,
then we don't need most of this in the fvwm window manager itself, only
in the individual modules that implement it. However, instead of having
a bunch of differnet modules, maybe what we need is to make a 'FvwmExtraStyle'
module that allows one to, once the module is invoked, specify extra things
for styles.
I would definately use this approach..as to me, it is important to get things
to look 'pixel by pixel' exactly the same. Maybe I'm picky, but it definately
would be impressive if we could specify 'Desk1 = UseStyle Win95'
'Desk2 = UseStyle Mac', 'Desk3 = UseStyle OS2', 'Desk4 = UseStyle Olvwm'.
I know I"m taking this to the extreme, but it's just one of those 'gee it
would be nice if..' kindof deals.
I quote one of my sysadmin: "If Fvwm were to implement styles to look like
olvwm, I'll bet it would become the most popular window manager out there'.
Especially considering it's smaller memory footprint.
Here's a question, though. Are there any copyright problems if we make things
look 'pixel-by-pixel' just like another OS/window manager?
> Again, just like above, I don't think that FVWM should have to have 10
> different menu styles to look like 10 different window managers.
> Perhaps some more generic controls though could be thought up to make
> it customizable though. I haven't given as much thought to this as to
> the borders/titles "problem".
Well, the menu styles is a side issue...but related...so I brought it up.
The idea I was hoping was that it would allow a flexible enough list of
style attributes so that it could be configured to look like different
window managers, not that it would have 10 differnet configurations
hard-coded.
> A module that has it's own menuing system that sends the commands to
> FVWM instead of asking FVWM to put up the menus is an excellent idea
> though. Then you could make 10 different modules if you wanted
> without bloating FVWM at all.
Well, it is all fine and dandy that we can hard-code styles, but I was
hoping that 'style attributes' would be flexible enough, whether more
are added by a module, or they are all in fvwm, to encompass any
configuration we would possibly wish to have, all by specifying
things in the .fvwmrc file. Maybe it's not possible, but boy would it
be nice.
> What would make it even better is to make it so the module can stay
> running instead of being reinvoked every time you want to pop the
> menus up. Then there would be no more delay than popping up a normal
> menu. This will require some more thought though...
Hrm, well, what currently determines when a module dies? When it's window
is closed? FvwmAudio runs w/out opening a window, and it waits for wm events
... so isn't this what you're looking for?
> I think so. But (like I said above) I don't think that it has to
> match exactly. Would the simpler approach I suggested be ok?
Well, maybe initially. But if it is close, hopefully one could 'tweak' things
so it would be exactly right. Sorry, I'm a bit of a perfectionist, so
I like things exact...and as I said earlier, I would rather make a module
if that is what it takes, than put an 'almost' implementation in fvwm
itself..
> Todd> BTW, for those of you not following the 'wine' development
...
> At least they aren't taking the evil WABI approach of override
> redirect windows...
Actually, without the '-managed' option, that is exactly what it does.
Plus, with the '-managed' you get the joy of remembering how often windows
apps decide they need the focus....for every time they would, in windows,
pop to the 'top' and grab the focus, they also do this in X. It is really
annoying, especially if you use '-privatemap' for its own colormap..so
for ill-behaved apps there is the '-desktop widthxheight' option that has
wine pop up a window in wich the app/apps will run, and that 'wine' window
behaves as a good X app should...
--
Todd Fries...tfries_at_umr.edu
http://www.cs.umr.edu/~tfries
--
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 Fri Dec 15 1995 - 14:54:13 GMT