>>>>> "Richard" == Richard Lister <ric_at_giccs.georgetown.edu> writes:
Richard> On Wed, 18 Jun 1997 13:12:31 +0200 (METDST) Jacco van Schaik
Richard> <jacco_at_nlr.nl> wrote concerning 'FVWM: New guy':
....
>> Why are the Color and HilightColor commands so different? The syntax is
>> different ("color1 color2" vs. "color1/color2"), the places where they
>> can be used (in a Style vs. at the top-level), the one doesn't accept
>> an "rgb:rr/gg/bb" color spec and the other does, the one can be split
>> into a BackColor and a ForeColor and the other can't. I end up having
>> to specify normal and hilighted colors in different places and in
>> different ways, which looks really awkward.
Richard> I think this is historical. The HilightColor command existed long
Richard> before Style "*" Color was created. I agree with you that it is
Richard> not very intuitive. Now we have the new decors it is possible to
Richard> get some strange and counterintuitive interactions between
Richard> BorderStyle, Color and HilightColor.
Correct.
Richard> In my opinion this should all be rewritten as part of the
Richard> Great Style Flag rewrite. And so I come to a proposal I'd like
Richard> to put to Chuck and the others.
Yes I agree that a fair amount of the rc syntax needs cleaning up...
Richard> I think fvwm-2.0.45 is pretty stable (more stable than a lot
Richard> of software I use!). How about freezing the features and
Richard> releasing it as 2.1, then having parallel releases: 2.x will
Richard> just be bug fixes for the current feature set, while 3.x (or
Richard> whatever) will have all the code rewrites people have been
Richard> planning for so long. People adding features will be
Richard> encouraged to add them to the cleaner code of the 3.x betas.
Whether the next beta after 2.1 is 2.2 or 3.0 depends on the scope of
the changes - what you are mentioning above perhaps falls about
halfway between what I imagine would be a 2.2 and a 3.0 version (which
path to take I've been oscillating on). I'll explain more below
(briefly).
Richard> It strikes me that Chuck spends a lot of time adding and debugging
Richard> all the great new features that people keep writing, and we'll
Richard> never get to 2.1 and begin the GSFR at this rate.
More or less correct... I've been trying to limit features to help
get 2.1 out easier, but incorporating patches is always a pain because
my development level usually changes shortly after I release a beta
version and patches often overlap files & throw off lines (sometimes
overlap lines too). Plus as some people have noticed, I like to
reimplement things sometimes...
Richard> Just my 2c. Comments?
My thoughts - I would like to get at least one more beta out before
2.1. Then what to do for the next beta after that?
(This is all breifly written, because I have to get back to work and
typing this note between working on things is becoming distracting)
I've toyed with the idea of the next one being a big rewrite, beyond
just what I had in mind for the GSFR (this would be 3.x). Clean more
stuff up, change rc syntax again (built in language, but add ways to
change to other scripting languages for the folks who would like
that), change module stuff (dynamic loading instead of or in addition
to a cleaned up socket communications protocol), etc. Essentially
redesign it. Scary thought, no?
What I had in mind initially for 2.2.x was the GSFR and various
associated cleanups, maintaining essentially the same rc syntax but
clean up parts of it (mostly for consistency between commands), add
some new features & bugfixes that are currently needed (eventually
including some of those that would be for 3.x). Then 2.3 official
could be releases, and then probably move on to 3.x...
What does everyone else think? The latter is probably safer, but I
find the former more appealing...
Most important for me to do in the immediate future is to actually
finish up the next beta... :) Sorry it's taking so long (again).
>>>>> "David" == David Jones <t47704_at_sulu.dehavilland.ca> writes:
David> I disagree with the statement that fvwm-2.0.45 is pretty
David> stable. I'm still using fvwm 1.x because of a bug in the
David> FvwmButtons module. I've written to the list before about this,
David> and got no response, other than from other people with the same
David> problem. The problem is that I can't get FvwmButtons to appear,
David> quite a fundamental problem with fvwm I would say. The only
David> advice I've been able to get is use the FvwmButtons module from
David> 2.0.41. Unfortunately, this didn't work for me, so I'm still
David> using fvwm 1.x.
Hm... I have to say that I think fvwm itself is relatively stable and
usable (am I biased?), but there will always be bugs and there will
often times be ones that some people see that others don't (and if one
of those others happens to be me, as it often is, then debugging some
problems is difficult).
Various people have had different problems with FvwmButtons,
especially since I accepted Jarl's rewrite - it doesn't handle the
older syntax well sometimes and this is often the problem.
Can you get a *simple* FvwmButtons example to work? Something like a
single button (no pixmap) that beeps? Just copy these two into
FvwmTalk and see if it works:
*SimpleButtons(Title beep Action Beep)
FvwmButtons SimpleButtons
If it does work ok, then work your way up through more complex
examples. Perhaps this will help you figure out what's wrong. Or
perhaps you can post to the list what your rc file was trying to do
and some kind soul who has some time might be able help.
Other alternatives - try FvwmGoodStuff (which is the pre-rewritten
FvwmButtons), FvwmScript, or tkgoodstuff. The first two are in the
extras dir in the 2.0.45 distribution.
[On a side note, eventually (3.x?) I'd like to combine features of
FvwmButtons, FvwmForm, & FvwmScript to make one super usable module
(FvwmGUI or something like that)...]
Ok, this has all taken way too long to type - gotta go. Hopefully
everything I've written here is coherent and actually what I meant. :)
Chuck
*******************************************************************************
Charles K. Hines <chuck_hines_at_vnet.ibm.com>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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 Wed Jun 18 1997 - 15:03:31 BST