It's been what -- three days since fvwm 2.0.44 has been released???
(feels like two months :-)
On Fri, 17 Jan 1997, Paul D. Smith wrote:
> I think one of the reasons it's confusing is that it's not clear at all
> what the distinction between a Decor and a Style is, when you should use
> one or the other, and basically why they are two different things and
> what each is good for.
> Also, it seems that everything _except_ Style has gone to the new
> "AddTo" format (with the "+" lines), which is inconsistent.
The reason that some things have gone global is because there aren't any
more style flags (yet). There is a slight confusion between Style and
ButtonStyle, for example, but this is due to the flag limitation, which is
to be addressed by Chuck after version 2.1.
Many of the things you've mentioned I've been forced to think about at one
time or another during implementation, but factors which caused me to make
certain decisions include backwards compatibility, practicality, and being
able to _not_ use any of the options (most important).
> And why is there only one AddToFunc, AddToMenu, AddToDecor, but there's
> a distinction between ButtonStyle and AddButtonStyle? I don't get that.
Functions, menus and decors do not belong to anything. They are only
assigned or called from other things. In this respect, they are global.
Button/title/border styles belong to decors.
> And, as I said before, some of the syntax uses this new (), --, !
> notation and some doesn't (like Style doesn't use !, it has multiple
> values for the opposite "flag" types). That's also confusing.
It's not entirely consisitent, but once you get the hang of it it's not
bad. I did this since it made code a bit smaller and more convienent.
Might be something too look into after 2.1.x though -- more consolidation
of parsing.
> Why do you define the colors to HilightColor as <c1> <c2>, but the
> colors to the Style Color option as <c1>/<c2>? There's just a lot of
> inconsistency and even some redundancy, I think, in the config file
> language now.
HilightColor has always been like that, unless someone changes it. There
has always been a lot of inconsistency and redundancy, and it won't go
:-). Part of the problem is retaining some sense of backward
compatibility for fvwm2.
You can't expect perfection -- no one works on this stuff full-time (also
it would take much longer :-). These things are meant to be practical,
i.e., you write something in the RC and it operates in a particular
manner. If you want more you could always go with gwm or something. If I
wrote a window manager from scratch I'd probably include something close
to a Turing-complete language written in lex/yacc.
The main reason that for example ButtonStyle has become somewhat complex
is simple: it still works with original button definitions.
> I think that somewhere there needs to be a very short overview: "Use
> ButtonStyle to define buttons on the window frame border; use
> AddButtonStyle to modify attributes of an existing ButtonStyle; use
> AddToDecor to make a new Decor; use UseDecor to apply a Decor to a
> Style; use UseStyle to `duplicate' a style", etc.
This is reasonable, and I think would probably be most effective. Let me
see if I can come up with a man page section for that. If you can, I'll
send it to you for comments.
I really didn't think there would be as much interest in this Decor stuff
when I wrote it. It is just a feature, and you can use it or ditch it.
However, since do seem to be interested, the future is wide open.
The idea behind UseDecor is that you can make sets of window
title/button/border/windowfont/hilightcolors and assign them to any
window. That's it. It's a lot of stuff which does take some time getting
used to.
I wouldn't expect anyone to understand everything in one day about decors
any more than I'd expect anyone learning everything about Emacs in 1 year.
I wrote the Decor stuff and even I haven't learned everything about it;
I've seen examples which I've never thought of being posted recently.
Let me see if I can explain the AddButtonStyle to you a bit more. Imagine
a stack of styles, each painted on top of one another. If I give a
ButtonStyle command with a style in there, than it clears the stack; i.e.:
ButtonStyle 1 Solid Blue
This would give me a solid blue button. Say I wanted a pixmap over that
blue button. Then I can say:
AddButtonStyle 1 Pixmap a.xpm
And say I wanted a second left justified pixmap over that, yielding a
stack which holds three styles:
AddButtonStyle 1 Pixmap b.xpm -- left
Then, a fourth style say is added, which is the default vector button of
button 3:
AddButtonStyle 1 Default 3
Resulting in the full definition (this does the same thing for all button
states since no state is specified for any definition):
ButtonStyle 1 Solid Blue
AddButtonStyle 1 Pixmap a.xpm
AddButtonStyle 1 Pixmap b.xpm -- left
AddButtonStyle 1 Default 3
That's it. The same is possible with TitleStyle if EXTENDED_TITLESTYLE is
enabled.
Say I wanted to use the TitleStyle for button 1 without clearing the
abutton stack:
ButtonStyle 1 -- UseTitleStyle
To get rid of UseTitleStyle
ButtonStyle 1 -- !UseTitleStyle
> Also, someone should to rewrite the system.fvwmrc file to maybe use
> Decor and/or Style "correctly" as an example; here's how I changed my
> ~/.fvwm2rc (obviously, comments more than welcome :) after I (think I)
> figured out Decor and UseStyle:
True, some examples are needed. But the problem is that these things are
quite flexible, and I could give you a pretty simple example as above or a
very complex one. I guess the key would be to get as many examples as
possible. But someone has to make an example repository.
It would be nice if someone could setup some sort of fvwm2 example
repository with a http inteface (seriously!).
The main thing right now is to fix bugs; this is the only the first beta
release of the decor stuff in fvwm2 :-).
Regards,
Andrew
--
Andrew Veliath <veliaa_at_rpi.edu> http://www.rpi.edu/~veliaa
One day, all forms of communication will be superseded by a FAQ.
Finger for PGP Public Key
Key fingerprint = 51 56 5D 3E 51 43 8B 74 7C B2 E4 B6 84 8E 8B 08
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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 Jan 17 1997 - 18:29:36 GMT