Subject: One thing about the next version...

From: "Paul D. Smith" <[email-masked]>
Date: Tue, 23 Feb 1999 11:14:30 -0500 (EST)

One thing I'd like to see for the next version is another quick release
cycle.  I think the user community would still like to see rapid
improvements and another official release sooner rather than later, to
give them warm-fuzzies that fvwm is _really_ under active development,
and the last version wasn't just a fluke.

Obviously not like a month or something, but say 4-6 mos.?  Sometime
this summer?

We might examine the list of "big features" for 2.4 with this in mind.

Thoughts?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jason L Tibbitts III <[email-masked]>
Date: 23 Feb 1999 11:08:30 -0600

>>>>> "PDS" == Paul D Smith <[email-masked]> writes:

PDS> Obviously not like a month or something, but say 4-6 mos.?  Sometime
PDS> this summer?

I think three months is about the minimum you can do and not exhaust your
developers.  (Immediate pre-release 'crunch time' is stressful.)  The key
is to limit the work to what you can do in that time.  This is what the
Linux kernel folks don't seem to understand.  Six months is a fair figure.

Important to this is keeping the stable branch stable (i.e. bug fixes
only).  If there is a lot of pressure to backport things, the release cycle
is too long.

However: I would like to suggest that there are two things that are
"necessary" (my opinion, probably not yours) for continued "popularity" of
fvwm.  I feel that these are important enough to alter the common notion of
a release cycle:

  Gnome support (hints and session management)
  KDE support (ditto)

Why?  Gnome at least needs a lightweight to alternative to Enlightenment; I
see icewm filling that gap if fvwm doesn't make the next RedHat release.  I
think it's an important goal for fvwm to have Gnome support by the time
RedHat 6 freezes even if that means that other things are stalled until
it's done.  If Debian has plans for a desktop then we should try to meet
them now.  It doesn't really matter if it comes in 2.2.x or 2.4.

Keep in mind the push by the Gnome developers and the Mexican government to
get Gnome on some huge number of small machines in schools in the near
future.  I don't know if they've already decided what WM to use, but what a
crowning achievement it would be if they used fvwm!

As for KDE, this is more vague to me but I know many folks like KDE but
detest kwm.  Some WM (Blackbox, I think) already has KDE support.  I don't
know what's required here, but it would be nice if fvwm was an alternative
here, too.

One other thing that folks seem to want is themes; I admit to not being big
on flash so I can't say whether this is seriously important.  I have a
feeling that we can get themes just by suggesting a default config file
structure and not changing much code at all.

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 23 Feb 1999 18:05:58 +0100

> We might examine the list of "big features" for 2.4 with this in mind.

I think I can afford the luxury of *not* thinking about it
in the next two weeks :) One thing I want to be considered
is the large number of outstanding patches and bugfixes that
have queued up.

I hope you can present me a list of goals that has been
agreed upon when I'm back.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: "Robert H. Ford II" <[email-masked]>
Date: Tue, 23 Feb 1999 12:26:31 -0600

> >>>>> "PDS" == Paul D Smith <[email-masked]> writes:
... text deleted for brevity ...
> structure and not changing much code at all.

I feel that I have no right to voice my opinion as I have contributed nothing
but a couple of found bugs, but I do have a large user base (somewhere between
200 and 500 users at least), so here it goes.

A large majority of users would like to have some type of GUI interface with the
window manager where by they can change settings and see the results
immediately.  Something like the animation form.

Instead of just having one controlling file, why not have fvwm2 and it's modules
use separate controlling files.  What I do for most of my users is have a
directory called $HOME/.fvwm2 and in this directory I have files named for the
module or task.  maybe it would be best if I showed you an "ls" of my
$HOME/.fvwm2 directory:

Audio                   Identify                Wharf
Backgrounds             KeyStyles               WinList
ButtonStyles            MouseStyles             lab-forms
Functions               Pager                  [menus]
Fvwm2-menus             Styles                  misc-forms
FvwmButtons             TaskBar                 pss-forms
IconBox                 TitleStyles             restart-menu.form

Each file then has an associated "read" (except for FvwmButtons) in my
".fvwm2rc"

If fvwm2 used some type of structure like this, all controlling files located in
one sub directory (not individual "dot" files under the users $HOME) then this
might make it easier to have some type of GUI interface with fvwm2 that could
run the appropriate destroy or kill the old settings and restart or add the
requested changes.

I am not very knowledgeable about these type of things and I don't know if
something like this is even possible, but it sure would be nice to able to bring
up a form/menu/some-type-of-GUI and make changes on the fly, sort of like (I am
very sorry for mentioning it here) AfterStep.

98% of my users are still using fvwm-2.0.45, I have been installing a private
copy of the development stream to test things.  The one problem I am having is
that fvwm-2.0.45's module FvwmBacker used a construct like this:

	*FvwmBackerDesk 0 xpmroot /home/misha21/icon/bg/spacebg.xpm

Now fvwm-2.2's FvwmBacker module needs at least an Exec after the desk number.

Does anyone have a suggestion as to how I can update my users files so the
upgrade in version will be seamless?  I could create a front end script that
could look for the use of that module and then edit the users files before
invoking fvwm2, but I was hoping for something different then that.

I would also like to send a big "Thank You" to all the developers who have taken
the time to make fvwm2 the window manager of choice and quality.

-- 
    _/_/_/     _/  _/   _/_/_/_/   _/_/_/_/_/_/ Robert H. Ford II
   _/   _/    _/  _/   _/           _/    _/    Lucent Technologies
  _/_/_/     _/_/_/   _/_/_/       _/    _/     Bell Labs Innovations
 _/   _/    _/  _/   _/           _/    _/      Naperville IL, 60566-7045
_/    _/   _/  _/   _/         _/_/_/_/_/_/     mailto:[email-masked]
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Phipps <[email-masked]>
Date: Thu, 25 Feb 1999 11:38:06 +0000

> 200 and 500 users at least), so here it goes.

Everyone has the right to voice an opinion.  Reporting bugs is much
better than not reporting them.

> run the appropriate destroy or kill the old settings and restart or add the

The module FvwmAnimate does a lot of this already, it maintains it own
rc file and creates some menus and forms that make it GUI configurable. 
It's blazing a path for the other modules to follow.

I'd like to see a .fvwm directory rather than have a version specific
name but I'm willing to be convinced the other way.  I don't have lots
of users or old versions to worry about.  It might be a good idea to
have an env variable that fvwm and the modules use to look up their rc
files that would default to ~/.fvwm$VERSION/$MODULErc so that I could
have VERSION="".

> invoking fvwm2, but I was hoping for something different then that.

If you can get a function definition into their config you could fake it
with

AddToFunc xpmroot I Exec xpmroot $0

but it depends on them all using xpmroot and not something else.

Cheers,
Tim.
--
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-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 25 Feb 1999 11:11:28 -0500

%% Tim Phipps <[email-masked]> writes:

  tp> The module FvwmAnimate does a lot of this already, it maintains it
  tp> own rc file and creates some menus and forms that make it GUI
  tp> configurable.  It's blazing a path for the other modules to
  tp> follow.

Yes, I like what has been done here.  It would be even more cool, as
I've mentioned to Dan in the past, if he used mini-icons in the menus:
he could mark the "currently selected" item in the "Iterations",
"Effects", etc. menus with a check mini-icon or something.  That would
be neat... of course FvwmAnimate would have to destroy/recreate the menu
each time the value was changed...

Also, I know Dan is working on enhancements to FvwmForms; these will be
critical if it's to be used in any kind of "self modifying config"
environment.

  tp> I'd like to see a .fvwm directory rather than have a version specific
  tp> name but I'm willing to be convinced the other way. 

Nope, definitely you're right.  We already changed the original
${prefix}/libexec/fvwm2/${VERSION} modules directory name to just "fvwm"
for similar reasons; no need for the "2" there.

---

From: [email-masked] (Paul D. Smith)
Date: 25 Feb 1999 11:22:27 -0500

%% Jason L Tibbitts III <[email-masked]> writes:

  jlt> Why?  Gnome at least needs a lightweight to alternative to
  jlt> Enlightenment; I see icewm filling that gap if fvwm doesn't make
  jlt> the next RedHat release.  I think it's an important goal for fvwm
  jlt> to have Gnome support by the time RedHat 6 freezes even if that
  jlt> means that other things are stalled until it's done.  If Debian
  jlt> has plans for a desktop then we should try to meet them now.  It
  jlt> doesn't really matter if it comes in 2.2.x or 2.4.

Hmm.  You make a compelling argument, Jason.  I would love to see fvwm
move back into the "mainstream" like this, and since we already have
GNOME (at least) patches imminent, plus the session management stuff, it
shouldn't be difficult to get a release out (I favor a 2.4 release over
a 2.2.x release) fairly rapidly with these enhancements.

Then the question becomes what, if anything, else "big" do we do for
2.4?  For example, if we decide to try to target the next fvwm release
at integration with GNOME and KDE, do we push off the GSFR until 2.6?

I've seen many people post their "should be in 2.4" lists, but I wonder
if maybe a good next step wouldn't be to go through the TODO list and
clean it out and make a "should be in _SOME_ future release" list.
Maybe we can sort the TODO list by expected difficulty or size of the
project.

Then we can examine that list and decide what the goal and timeline for
2.4 is, and what projects are needed to meet the goal.

  jlt> One other thing that folks seem to want is themes; I admit to not
  jlt> being big on flash so I can't say whether this is seriously
  jlt> important.  I have a feeling that we can get themes just by
  jlt> suggesting a default config file structure and not changing much
  jlt> code at all.

So far I've been an advocate of taking a "wait and see" approach to
themes.  What I'm looking for is for some people who really want themes
to try to get some kind of "theme scheme" working with fvwm as-is.

Then, have them come bitch to us about all the pain and torture they
suffered and the hoops they had to jump through to get it working... and
see if we can't smooth the rough edges in a way that both (a) doesn't
require tons of work and yet (b) addresses 90% of the "hard parts" of
setting up themes.

That being said, I think there is definitely room for improvement in the
consistency of fvwm itself.  For example, see the bug report I made
recently as a placeholder for the idea of having a unified "FVWM Style"
which would provide default information to all parts of FVWM _AND_ all
it's modules, like basic foreground/background colors, font(s), etc.
This would give a "single point of change" for modifying fvwm and all
its modules, _and_ ensure a consistent look and feel amongst them.

---

From: Dan Espen <[email-masked]>
Date: Thu, 25 Feb 1999 13:12:48 -0500

> critical if it's to be used in any kind of "self modifying config"

Yep.  If you are wondering why you haven't seen it yet,  I got tired
of waiting for 2.2 and launched into another round of enhancements.
Right now I'm working toward stability again.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Jay Kuri <[email-masked]>
Date: Sat, 27 Feb 1999 12:22:12 -0500 (EST)

> to try to get some kind of "theme scheme" working with fvwm as-is.

	I've been thinking about theme capabilities of fvwm for awhile
now.  I like the way that fvwm.themes.org lays things out (for the most
part anyway ) and I agree that we don't need to crunch on fvwm itself to
implement themes.

I think that themes can and should be handled in a module (say FvwmTheme)
that allows you to have multiple themes installed, and allows you to
select your 'theme' from a menu (as FvwmAnimate does it) rather than
editing / symlinking files.

I intend to write such a module... But I am not too familiar with the
module interface so I have a little bit of learning to do.  My main goals
are as follows:

	* Provide easy-to-use theme selection mechanism
	* Use 'standard' fvwm config options to achieve themes

I would also like to do the following, but as an added bonus, not as a
main development goal:

	* Provide for the ability to use other wm themes (ie: windowmaker)
	   (obviously, not 100%, but we could probably get pretty close)

Are there any other capabilities that any of you are interested in (or
aware of other people being interested in)? 

I think that I could have this together by the 2.4 release time-frame...
What is the procedure for adding a module to the distribution?  

Thoughts on this would be appreciated,

Jay