Robert Nicholson <robert_at_elastica.com> writes:
>
> I'm guessing that the 95 hack is so much of a hack that to integrate
> the sources back into the main distribution would upset the purists?
>
> I'm new to fvwm95 and I was just curious about the fvwm position on
> it?
>
> I've already noticed that fvwm95 seems to be out on it's own so to
> speak and I'm wondering what's the best to commit time and resources
> to. I do like the way fvwm2's .fvwm2rc file is split with the Read's
> which don't appear to have made their way into the fvwm95 release I'm
> currently using.
>
> So, will these two source trees be disjoint?
>
> Why for instance can't the 95 hack be a module of fvwm2?
>
> Go easy on me :-)
> --
> 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.
>
>
There are three problems:
1. I'm not sure how well the current module interface
is suited for a module that is resposible for drawing all of the decorations
and whatnot.
2. fvwm95 is different from fvwm in more ways that just new titlebars. For
example, they have been busy creating new types of packets to send to modules,
and so has fvwm (SendToModule is only in fvwm for example, and until recently,
the mini-icon packet was only in fvwm95). Also, the style flags are diverging.
3. When you have two groups of people working on software, and they aren't
forced by some higher power to cooperate, it seems inevitable that they will
continue to diverge.
One additional problem:
4. Fvwm is a free piece of software developed by a lot of people. As such
there is no "fvwm position" on just about anything. Sitting around and waiting
for one is rarely productive. The single best way to get a "position" to form
is to put fingers to keyboard, write the code, and then hope that everybody
else says "cool." I'd recommend getting in touch with Chuck Hines, before
starting anything major, and also I'd wait until after the official release
is made and the things stabilize.
I think that merging fvwm95 and fvwm together again (note that I didn't say
merge fvwm95 back into fvwm. It's changed enough to be considered a seperate
project, if in its infancy) will certainly require rewriting a large fraction
of fvwm (and fvwm95). As such, nobody's going to be much happy about it on
either side unless it is accompanied by clear improvements. For example, if
a better way is found to interface modules to fvwm that allows for a new
family of neato modules to be written (the options I see: and embedded
language like guile or python, dynamic linking, or some sort of
rpc). Otherwise, all you've succeeded in doing is tearing your house down and
living in a tent in the back yard for a few months so that you can rebuild
your house with a new type of flooring.
I think the best way to proceed is to get a clear answer to the question:
What improvements need to be made to fvwm which would make it all around
cooler, smaller, faster, and/or better, from which adding a module to make
it look and feel like windows 95 would just fall out?
--
Brady Montz
bradym_at_cs.arizona.edu
--
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 Tue Oct 22 1996 - 00:42:51 BST