Dominik Vogt wrote:
>> I never said that I'm against reading docs. I just found lisp easier,
>> clearer, more coherent than what fvwm has to offer.
>
> I guess many people disagree with this opinion. The main
> difference is that to learn lisp, you have to learn programming.
In Sawfish you could get very far without real knowledge of lisp. All
you needed was the ability to invoke functions and pass parameters. And
maybe know that head/tail thing in lists. Sawfish provided/provides
some predefined popular functions, similar to those in fvwm. And
sawfish-ui (~FvwmConsole) had tab-completion, so it was really
convenient.
>> > By the way, this is the main strength of the "language": you can
>> > start writing your own config snippets right away by looking at the
>> > examples in your config file. That will not take the beginner very
>> > far, but it helps to overcome one's inhibitions.
>>
>> That's true for any given higher-level language. Not only fvwm's
>> configs.
>
> I don't know where you get that idea from. It's certainly not
> true for PERL, Python or shells. They all require sound knowledge
> in programming.
You were talking about simple, primitive examples ("That will not take
the beginner very far"). So I could name a simple shell script,
consisting only of a list of external commands to execute. Or a perl
script with a couple of print's. If you meant something more
complicated, then please compare it with something equally complicated
in fvwm, for example
Current (!State 2)
KeepRc TestRc (Match) foo
TestRc (Match) bar
It depends on how complicated the example is. With easy examples most
languages are easy to understand. With "advanced" code snippets most
languages are difficult, fvwm is no exception.
>> So where's the insult?
>
> The insult is that you claim that I am unable to consider what
> users want
Don't take it hard, but yes, sometimes at least. I could name some
examples, but since you put so much weight to it I won't. I bet
you would just see thing "in a different light". If you insist we can
continue this topic in less... public conditions. My private email is
hoppke _at_ lubuska.zapto.org
My apologies if that insults you, but it shouldn't. We are all humans
and with bigger projects it's never possible to please *everyone*.
Just as it is impossible to read the minds of others and predict with
100% accuracy "what they want". That would be much like the theory of
politics ;)
> You ranted about the scripting *engine*. Only in the follow up mail
> you made it clear that you were talking about its *interface*, not the
> engine itself. So don't condemn me for replying on the same level.
I'm sorry, but there is no (IMVHO) definition of an "engine" or
"interface" when it comes to fvwm. If I would say from the start that
I mean the "interface", you could've thought that I mean FvwmConsole (as
a module) or something similar. In your mind the "engine" is that what
*you* know best - C code implementation. For me the "engine" is the set
of commands, the syntax - what keeps the whole thing running. That what
is under the interface (and the interface is, of course, the GUI). All
a matter of semantics.
>> b. you can glue code to the function after invoking some different
>> commands (I know it's a feature, but still - it's different from most
>> languages with functions and it complicates things)
>
> And it is very, very flexible and a *great* debugging help.
I don't know about debugging, but I've never used that
"flexibility" since I use fvwm. In my opinion it may be a nice feature,
but I haven't found any use for it. I could imagine that this comes
handy with menu definitions (dynamical menus), but functions? And one
more thing: I would have found it easier if you could only continue
definitions after an AddTo* command. Right now if you interrupt
a definition you can continue by just using the "+ ". I don't know if
that's so great. Many times it meant troubles for me. The code got
appended to the "wrong" function or menu definition. I have never ever
needed this feature and I would have found it much easier if you would
always have to use a AddTo* after interrupting a definition to continue.
>> It just didn't work. No error message, nothing. I had to understand what
>> was wrong by myself, 'cause the manual obviously considers it as
>> "obvious".
>
> Well, that is not part of the design but simply a bug (in my
> eyes).
I thought it was designed that way. The "+" is allowed in names of
functions, so I thought that it's not a "reserved word". To give users
the possibility to do:
addtofunc foo+bar
+ I ...
+ I ...
function foo+bar
Although I didn't knew why anyone would want to allow a "plus" sing in
functions names...
> Then our image of a "normal user" differs very much. In my eyes,
> the typical computer user:
>
> - Will not learn a programming language to configure a program
> - Hates having to learn sopmething just to use the machine
> - Has no deep knowledge of programming, or even the computer
> - Sees the computer as a tool, not as a toy
> - Has little time to learn the internal workings of the computer
> or a program.
Oh, you mean a "ZU" ;) That's what we call those people in my language.
> So I would hardly classify you as a "normal user". Okay, fvwm is
> a bit hard to configure anyway, but that is no good excuse to not
> think about the most inept users too.
Yeah, but I really don't think that a ZU (or "normal user") will ever
want to use fvwm. Fvwm is to hard to use:
a. It comes with no fancy default configuration
b. Not that much eye-candy as in most popular WMs
c. No GUI configurators (those scripts that come installed by default
can only setup a small subset of fvwm's features)
d. It's ugly like 1981 (by default, of course)
e. You have to download fvwm-themes to make it look somewhat "modern".
f. Sounds. No nice wizard to do the configuration, no support for esd or
arts - and they are standards in the "normal user" computer worlds.
g. The manual page is too cryptic and too long, there are too many
options to actually get a strong grip on the WM
h. Some (very important for the Normal User) things don't work:
- tray icons. Mostly KDE or Gnome apps.
- fullscreen maximizing. In mplayer, Mozilla, ...
- no fancy panel (plain taskbars are prehistory)
i. ...
Really, I would be amazed if an Normal User would choose fvwm. All that
I know have removed it from their systems and installed something
easier. Less powerfull, but easier. WindowMaker is very popular, so is
IceWM. Then, let's not forget, Normal Users mostly use ready-set
Desktop Environments like KDE or Gnome, and I believe they won't
exchange Gnome's Metacity for FVWM.
IMO the only way for a Normal User to use fvwm is in larger networks,
where the user has no influence. Universities etc. But on such sites
fvwm is preconfigured by sysadmins, so you don't need to worry about
making fvwm "not so easy".
I admire what you're trying to do, but I think that fvwm is unusable (or
not tempting enough) for a Normal User unless he receives
a preconfigured version of this WM.
>> Alright, how do you picture deleting all bindings for the "I" context?
>> Add twenty new commands, like
>> DeleteBindingsInContext(contex name),
>> DeleteBindingsToFunction(function name),
>> ...
>> ?
>>
>> Sure, you can do everything that I mentioned if you add new functions.
>> But it's like constructing a cell phone with buttons for every entry in
>> it's address book. Is that really "user friendly"? That's good when
>> the address book has 10 entries. But when it has more than 100 of them
>> it's time to think of a new interface for the user.
>
> I wonder how you would delete bindings without a binding specific
> interface in a different language.
You mean "keybindings"? In Sawfish there was a "table of bindings". It was
as if you would put all Key's and Mouse's into a table.
(...)
(Key,c,M,W,Close)
(Key,z,M,W,Minimize)
(Key,s,M,W,Shade)
(...)
Every row describes a binding. The row itself is split into fields which
can be separately analyzed if it's necessary.
The "binding specific interface" consisted of a synchronization
procedure between the table and WM's internals. You push a new row into
the table and a new binding comes to life. You remove a row, and
a binding get's wiped out. As you have normal acces to the list you can
pick specific rows just as you do it with data in lisp.
There was no other way to add a binding[1]. You simply had to place it
in a special table/variable. And because it was a normal table you could
modify it like a normal table. So there only needed to exist this
feedback pipe between the table and the WM, the developers didn't need
to think about all possible needs or wishes. This was done later by the
users themselfs. You want to make a function clearing the root context?
No problem, scan the table for "R" in fourth field and delete matching
rows.
[1] - well, there was also a convenience macro to do it quickly.
For Sawfish existed/exists a wiki with many custom functions, for people
who just can't write it on their own or want to publish something. With
this "open the internals" approach much load slipped off the developers.
Instead of patches for C code the users started to send in functions in
Lisp - easier to integrate and less prone to crash the WM (errors etc.
are caught by the interpreter).
--
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]
