Subject: re: Release goals

From: Steve Robbins <[email-masked]>
Date: Mon, 15 Mar 1999 23:56:15 -0500 (EST)

Hey gang,

So just after the 2.2 release, there was a short thread on future goals.
This is the last list I saw:

	* remove auto*-built files from CVS

Done.

	* remove modules/extras distinction

Done.

	* remove icons to a separate distribution

Is there anyone besides me that thinks this is a good idea?

	* move code duplicated in many modules into a library

Presumably this happens gradually.  People working on module code are
keeping this in mind, right? 

	* experiment with shared library for libfvwm

I experimented with this on the weekend.  It was not an unqualified
success, though.  We can discuss this in a separate thread.

	* Turn on the GSFR code and fix whatever it breaks.

I saw some discussion about this, but I don't think anything has been
committed, right?

	* Evaluate the backlog of new style ideas.

?

	* Add animated windowshade.

This is in, according to the NEWS.

	* Reuse FvwmWindow struct on Recapture.

?

	* The GNOME hint stuff.

?

 	* include OpenVMS port

Done.

	* Get 2.4 out within a few months.

The NEWS file has a load of entries in it.  Is there a reason not to make
a beta 2.3.1 release this week?  Someone will have to fix the "awk
problem"  first, of course. 

Were there other goals that I missed?

--
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: Tomas Ogren <[email-masked]>
Date: Tue, 16 Mar 1999 11:17:49 +0100

> This is the last list I saw:
[...]
> This is in, according to the NEWS.

After the 4-state stuff, one minor patch is still needed.. I have a
working version in my copy, but it's a little bit ugly (one global var
existing in 2 files). The other ways I can do it in results in either an
api-break (called from ~30 places) or code duplication (~300 lines),
which can bring them out-of-sync if stuff is changed.
Will commit any day now.

> 	* The GNOME hint stuff.

Jay was cleaning this up and was committing any day, according to his
mail to fvwm-workers.

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student of Computer Science at the University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
--
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: Dominik Vogt <[email-masked]>
Date: Tue, 16 Mar 1999 10:16:48 +0100

> Is there anyone besides me that thinks this is a good idea?

We need some of them for the example configs, but otherwise okay by me.

> I saw some discussion about this, but I don't think anything has been

Right. Won't be done before the other major patch is in (GNOME).

> a beta 2.3.1 release this week? 
    ^^^^

I assume you mean alpha release. Wouldn't 'beta' imply that we're
in feature freeze again?

Bye

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
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: Dan Espen <[email-masked]>
Date: Tue, 16 Mar 1999 08:35:07 -0500

> Is there anyone besides me that thinks this is a good idea?

Are you thinking of putting them somewhere else?

> problem"  first, of course. 

A list of outstanding problems:

* Bad  window size,  or  something else that  put  rxvt into a  memory
consumption binge with windowshade.

* "+" commands are acting up causing the "dot problem".

* Something awry with the ImagePath.

* FvwmForm data  files not installed in "fvwm" subdirectory.

* FvwmForm data files have a leading dot.

--
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: Brad Giaccio <[email-masked]>
Date: Tue, 16 Mar 1999 08:43:47 -0500

> consumption binge with windowshade.

I can reproduce this with a shaded xterm and then a restart of fvwm

> * FvwmForm data files have a leading dot.

I also pointed out a problem with:
Style "*" Layer n        
to Matthias and he is looking into it.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Tim Phipps <[email-masked]>
Date: Tue, 16 Mar 1999 13:51:00 +0000

> > Were there other goals that I missed?

Could we decide on a better name for the Replace function that was
posted in a patch and then put that in?  How about Place or PlaceAgain?

Cheers,
Tim.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 16 Mar 1999 08:46:00 -0500 (EST)

> I assume you mean alpha release. Wouldn't 'beta' imply that we're

I meant beta.  

I thought that the CVS sources are the "alpha releases", and feature
freezes came in when a "real release" (i.e. 2.4.0) was near. 

--
Steve Robbins                              <[email-masked]>

A woman came up to me and said, "I'd like to poison your mind,
with wrong ideas that appeal to you, though I am not unkind."

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 16 Mar 1999 14:12:52 +0100

> freezes came in when a "real release" (i.e. 2.4.0) was near. 

Hmm, our practice with 2.1.x/2.2 was differently. We called only
those labels 'beta' that were announced and intended for the masses.
Several releases were clearly marked as 'alpha' (e.g. 2.1.5, 2.1.6).
Not that I really care how we call them, but someone
might think 2.3.1 is similarly stable as 2.1.13 if they are both
called 'beta'. The open source community has become used to think
of 'beta' as equivalent to 'stable enough'. We don't want that right
now, do we?

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 16 Mar 1999 14:14:53 +0100

> posted in a patch and then put that in?  How about Place or PlaceAgain?

I prefer 'PlaceAgain'. If you want to apply the patch, go ahead.

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Tue, 16 Mar 1999 09:32:29 -0500 (EST)

> which can bring them out-of-sync if stuff is changed.

Another global variable?  Hmm...

Using a global variable rather than changing 30 function calls is likely a
false economy, is it not?  Using globals means one cannot understand or
modify the function in isolation.  It becomes hell to maintain.  

You note that the global only "exists" in two files, currently.  Global
references have a tendency to spread and infect other files.  Moreover,
there is no way to enforce that only two files reference the global.  So
even if you document this fact, someone could (will?) break the rules
later on.  When I go to modify the function using the global, I can't
trust your documentation, and have to search through the sources anyway!

If we want the code to be maintainable, I think one ought to be
re-designing the internals to eliminate globals, rather than increase
their number.  As far as I am concerned, any "internal api" is fair game
to be changed.  It is only documented in the source, anyway.  Changing the
module interface is more problematical, but it should not be a sacred cow,
neither.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 16 Mar 1999 14:50:49 +0100

> module interface is more problematical, but it should not be a sacred cow,

Finally we have a volunteer ;-) Yes, I agree 150%. The globals have
to be removed. I'm constantly striving to reduce usage of globals or
at least make them static in their modules, but it's a hard job. Did
you ever look at FvwmButtons or FvwmTaskBar? That's kind of
discouraging. I'll happily support anyone writing documentation on
this or doing some cleanup.

Bye

Dominik

---

From: Matthias Clasen <[email-masked]>
Date: Tue, 16 Mar 1999 16:30:01 +0100

> to Matthias and he is looking into it.

A fix will go in tonight. FYI: the problem was that every Style command
would override the layer, even if no explicit layer was given, thus

Style "*" Layer n

works as expected, but any layer Style "*" without explicit layer
option would bring everything back to layer 0. Fixing it requires
an extra has_layer flag in struct name_list. Unfortunatly, there was
no room in the unsigned longs used for flags, thus I´ll put in
a bitfield tmpflags similar to the one in FvwmWindow. I assume
that the GSFR will also turn the name_list flags into a bitfield ?

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: 16 Mar 1999 10:32:09 -0500

%% Steve Robbins <[email-masked]> writes:

  sr> 	* remove icons to a separate distribution

  sr> Is there anyone besides me that thinks this is a good idea?

I'd prefer they not (all) be removed.  Certainly I think the icons
directory needs a good, stiff cleaning.  There's lots of stuff in there
which is either useless or only marginally useful.

But, I'd like fvwm to come with some basic set of icons and not require
them to be downloaded separately.  And I think that we need _more_ of
some kinds of icons, not less: mini-icons in particular, which are
harder to find on the 'net in my experience.  Most of the mini-icons I
use I've snarfed from the fvwm95 dist; they have a much nicer set of
icons than fvwm2.  Although, they have a lot more junk there too :).

  sr> 	* Turn on the GSFR code and fix whatever it breaks.

  sr> I saw some discussion about this, but I don't think anything has been
  sr> committed, right?

Dominik committed an ifdef'd out first-whack at the GSFR bitfields.
I've looked at it and have been _trying_ to find the time to post some
comments...

  sr> 	* Evaluate the backlog of new style ideas.

  sr> ?

I don't necessarily think we need to implement a bunch of new styles in
the same release as the GSFR, "just because we can".  I'd prefer to get
a GNOME-aware release out with all the other new stuff we have, and
leave that kind of more "pie-in-the-sky" stuff until later.

-- 
-------------------------------------------------------------------------------
 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://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: Tomas Ogren <[email-masked]>
Date: Tue, 16 Mar 1999 16:33:40 +0100

> modify the function in isolation.  It becomes hell to maintain.  

Okay. I'll make an extra arg..

/Tomas

---

From: Steve Robbins <[email-masked]>
Date: Wed, 17 Mar 1999 10:53:46 -0500 (EST)

On 16 Mar 1999, Paul D. Smith wrote:

> them to be downloaded separately.

I understand the desire to keep the build process simple.  And it is an
important one.  But consider: 

1. We don't currently install icons anyway.  Neither did fvwm 2.0.46.  
   Removing icons to a separate distribution will affect the naive
   intaller only marginally.  Instead of

	./configure && make && make intall
	[starts fvwm] 
	"hey, why don't my icons work?"
	[reads docs]
	cp icons/* /usr/local/share/icons

   the sequence becomes

	./configure && make && make intall
	[starts fvwm] 
	"hey, why don't my icons work?"
	[reads docs]
	[downloads icons-1.0.0 from net, unpacks it]
	cd icons-1.0.0 && make install

2. This only affects the first-time install.  Subsequent intallations
   will use the old icons, no problem.

3. The icons directory is large and unchanging compared to the source
   code.  The icons take up more disk space (unpacked) than libs/ or
   any module, save one.  Since going to CVS, exactly one icon has been
   removed (due to copyrights) and one added.  Since 2.0.46 (about 
   a year and a half ago maybe?) only 13 icons (of about 140) have been
   added. 

4. Icons ought to be distributed with their applications, not the window
   manager.  Why?  Well suppose I have an emacs icon I like that came with
   emacs.  Suppose further that fvwm has its own emacs icon (it doesn't).
   If fvwm installs its icon over mine, I'm going to be pissed.  Yes, we
   can play games with not installing the icon if the same name already
   exists, or suggesting that admins keep their own icons in a separate
   place on the ImagePath.  But these just mask the initial flaw that the
   icons are associated with the *application* not the *window manager*,
   and should be distributed with the former.

5. Sharing icons with other window managers is a bit tricky.  Yes, we have
   an ImagePath, so fvwm will search more than one place for a given icon.  
   But suppose both fvwm and some other window manager, say 'f', come with 
   icons a.xpm and b.xpm.  How will you arrange the ImagePath if you like
   fvwm's version of a.xpm, but prefer f's version of b.xpm?  Yes, there
   are some obvious solutions, but you end up trying to do some kind of
   merging or pruning of icon sets.  Upon upgrading WMs, you're faced with 
   doing it all over again.

> And I think that we need _more_ of

Which perhaps illustrates that the current icons are not adequate.  

Historically, icons weren't distributed with applications, and I know that
this is why WMs come with icons.  We could either spend energy keeping the
icons directory up-to-date, or promote the idea that icons belong to
applications.  Over time, the burden of providing icons will lift from
WMs, [he says, perhaps over-optimistically].

Of course it would be unrealistic to simply dump all the application icons
and leave it at that.  For one thing, if we wait for all application to
ship & intall icons, we'll be waiting a long long time.  For another: 
where would they install their icons anyway?  There's no real standard
that I know of; /usr/X11/include doesn't count -- the X11 include
directory is non-standard anyway, it doesn't typically hold non-xbm's, and
it is prone to getting wiped out during upgrades.  

So we need a collection of icons for existing applications.  And it needs
a mechanism for coordinating the install path with WM.  It would be nice
if it were WM-independent, but I'm not volunteering to do that ALONE, :-) 
though I would help in the effort.  If such a collection does not
materialize, I suggest as a first step to put icons useful to fvwm into
its own distribution, and put it up on fvwm.org.  I can't think it is
_such_ a burden to install the icons package for the first fvwm install. 

Certainly fvwm is an application, so any fvwm-specific icons should be
shipped AND INSTALLED by fvwm.  These won't disappear from the icons
directory.

I'd rather have one of your minutes
than a year with all the hours in it.

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Mar 1999 11:19:27 -0500

> > %% Steve Robbins <[email-masked]> writes:

Providing Jason is willing to set up some way for us to create an
"icon" distribution I don't see any problem in separating it from
the main CVS tree.

It is the CVS tree you guys want to get it out of isn't it?

Or is it the distribution?  If its just the distribution, we
should be able to create the proceedures to create more than
1 tar file.

If we (you guys?) want it out of the main CVS tree, do you want
another CVS tree just for icons, or something else?

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 17 Mar 1999 21:11:08 +0200 (IST)

>  and should be distributed with the former.

Ideally icons must be distributed with applications, but this will lead
to a set of icons of different size and style, so it will be hard to use
them on one desktop. So practically you need some set of icons in one
place and having fvwm-icons is not bad idea.

Actually current fvwm-icons are all of different size and style and not so
nice. IMHO massive clean-up must be done. Lets decide which icons do we
need (application icons, mini application icons, button icons, side menu
icons etc.) and choose at least their sizes, when possible. For example,
48x48 for desktop icons, 16x16 for mini icons. Voting? I think we must
drop all icons which are not of the chosen size and prepare new icon set.
Pat Rogan has interesting icons in fvwmiconpack.

> So we need a collection of icons for existing applications.And it needs
> a mechanism for coordinating the install path with WM.It would be nice
> though I would help in the effort.

I can help with this once we decide about which icons to have, if any.

Mikhael.