brian moore <bem_at_cmc.net> writes:
<stuff removed>
> Again, I said the same thing two months ago on the users list. I really
> dislike the format of .fvwm2rc (and .fvwmrc, for that matter). Not in
> that they are incapable of doing some impressive things: some of the
> configs people have make it clear that with patience modules like
> FvwmButtons are amazingly flexibly, including being able to fake the CDE
> bar's appearance fairly well. I dislike them because they are ugly,
> rife with +'s and ""'s and other junk.
>
> I won't, however, argue that including an interpreter (again, be it
> guile, perl, tcl, python, whetever) in the core is a Good Thing. It's
> certainly a good thing as a module, and modules like FvwmCpp and FvwmM4
> show that it's possible to have a module provide config files for the
> parent.
>
> It doesn't, however, belong in the core.
Here we differ! Both modules are oneway creatures. They can not react
on the current configuration in anyway, just change it blindly. That
is, of cause (or if not "of cause", then seen in hindsight) enough for
most uses of fvwm until now.
I just believe that if we want to do more with fvwm, then we need a
full configuration language with access to all structures of
fvwm... And that is difficult, though not impossible, to do in a
module. We would have to extend the fvwm module protocol alot, and I
guess, we would end up with a fvwm the same size as if we just added
configuration language.
<stuff removed again>
> > Nope. I'd probably make Guile and filtering a build-time option. Not
> > because I'd fear a fork, but simply for parsimony's sake.
>
> So why not in this case? It's trivial to #ifdef things. Until the
> Great Style Rewrite, lots of things in fvwm2 will be ifdef'd. That's
> not what's being argued for, though.
>
> What's being asked is not parsimony, it's assimilation. "We want to
> call scwm 'fvwm3' and will require linking an interpreter into your core
> WM."
Looking back at the messages send by Maciej and Greg until now, I see
nothing to support the above paragraph. All they have done is to
express a desire to avoid duplicate work. Which is "good" in my
book. Then again, I'm no big fan of "not-invented-here software" as
seen so often...
/tonny
--
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 Jul 17 1998 - 10:55:43 BST