Subject: CVS migo: * added a new default FvwmBanner logo and its colorful origin

From: CVS <[email-masked]>
Date: Wed, 15 Sep 1999 21:24:29 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	migo	99/09/15 21:24:28

Modified files:
	modules        : ChangeLog 
	modules/FvwmBanner: FvwmBanner.c Makefile.am 
Added files:
	modules/FvwmBanner: fvwm-logo-colorful.xpm fvwm-logo-current.xpm 
	                    fvwm-logo-old.xpm 
Removed files:
	modules/FvwmBanner: fvwm2_big.xpm 

Log message:
* added a new default FvwmBanner logo and its colorful origin
* renamed fvwm2_big.xpm to fvwm-logo-old.xpm, removed stylized '2' from it

--
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: Thu, 16 Sep 1999 08:22:34 -0400

> * renamed fvwm2_big.xpm to fvwm-logo-old.xpm, removed stylized '2' from it

I'm  confused  as to  why  you've created fvwm-logo-old.xpm and stored
fvwm-logo-colorful in the FvwmBanner directory.

If someone gets around to making FvwmBanner accept a command line arg,
for the pixmap to use, we would only need one pixmap to be built in.

I think any other banners should be in fvwm-web.

--
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: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 1999 17:20:48 +0300 (IDT)

> for the pixmap to use, we would only need one pixmap to be built in.

I thought that the pixmap to be used as built-in default can be configured
from the three supplied (there will only be a change in #include).
If you think that this is a bad idea, feel free to correct it.

> I think any other banners should be in fvwm-web.

If you look at them as external banners - probably yes, if you look at
them as alternative default variants - they belong to FvwmBanner.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Sep 1999 17:10:47 +0200

> them as alternative default variants - they belong to FvwmBanner.

I'd rather not see pixmaps the size of the banners as part of the
fvwm tarball. It's bad enough that there must be one such file,
but I'd definitely against adding a set of them. We just need an
icon distribution.

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: Thu, 16 Sep 1999 11:19:16 -0400

> but I'd definitely against adding a set of them. We just need an

I think you are aware of this, but the way you  worded that has me not
sure.

We do have an icon distribution.  Check out xxx.fvwm.org.

Based on this  mornings discussions and  the comments  about the sites
possibly going away,  I will be adding the   banners and side  pixmaps
from the 2 sites mentioned to the fvwm-web icons directory.

I'm  including     the  "extra" icons    that   are   now  sitting  in
modules/FvwmBanner.

I  don't see  the value  of having more   than one built in  pixmap in
FvwmBanner.

As for size, a few days ago, right after I removed the  icons, I did a
make distcheck.  I don't know why, but the size  of the tar.gz file is
1,349,807.  I haven't figured out yet why its so large.

The ChangeLogs are getting out of hand.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Sep 1999 17:39:20 +0200

> We do have an icon distribution.  Check out xxx.fvwm.org.
                                              ^^^^^^^^^^^^

Okay, I see this address for the first time now. Is that some private
URL where you and Jason test the new pages, Dan?

Let me rephrase what I mean: We need a way to distribute icons *and*
config files that use them in a way that is compatible with the
autoconf stuff of fvwm.

> 1,349,807.  I haven't figured out yet why its so large.

There are several reasons:

 - The tared gziped icons from fvwm95
 - Tons of copyright statements is all files.
 - menus.c has grown to around 170k source code
 - FvwmTheme generates a lot new code in most modules.
 - The ChangeLogs are growing *fast*. The main and module
   changelogs have about 350k.

> The ChangeLogs are getting out of hand.

Indeed. I gues we should probably remove them from the distribution
and provide them in some other fashion.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 16 Sep 1999 11:52:55 -0400

> > We do have an icon distribution.  Check out xxx.fvwm.org.

Jason set it   up.  Anything   committed  to fvwm-web    automatically
propagates to this URL.  I've requested  that Jason switch fvwm.org to
fvwm-web but as  he's  indicated more  than once his   workload hasn't
allowed him to get this done.  I'm sure he will get to it.

> config files that use them in a way that is compatible with the

I'm not sure what you are driving at.  You can configure a pixmap path
right now.  Last  week you and I agreed  to remove the icons  from the
distribution.  (My offline mail to you  asking about the tgz files you
added to the icon directory.)

>  - The tared gziped icons from fvwm95

They were already removed when I did the make distcheck.

>  - Tons of copyright statements in all files.

If thats the case, lets get them out.  I don't see why it can't say,
see the copyright notice in xxx.

>  - menus.c has grown to around 170k source code

All good code I'm sure.

> Indeed. I guess we should probably remove them from the distribution

Hmm.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Sep 1999 18:46:06 +0200

> allowed him to get this done.  I'm sure he will get to it.

Hm, I must have missed anything that Jason said about this.

> see the copyright notice in xxx.

After all the work to put them in? :-) Hm, let's see...
251 .c and .h files plus perhaps 50 other files with a copyright
statement. One statement uses 717 bytes.

  300 * 717 = 210k

Wow.

> >  - menus.c has grown to around 170k source code

Thanks for the kind lie ;-) It's much code and there is much
more work to be done.

> > and provide them in some other fashion.

I mean, who uses the ChangeLogs anyway. Only the developers. Anybody
else will be hard pressed to extract any useful information from them.
SuSE for example takes all ChangeLogs out of the packages and provides
a ChangeLog package (that probably nobody installs).

Bye

Dominik ^_^

---

From: Ben Winslow <[email-masked]>
Date: Thu, 16 Sep 1999 15:50:52 -0400 (EDT)

On Thu, 16 Sep 1999, Dominik Vogt wrote:

[snip]
# After all the work to put them in? :-) Hm, let's see...
# 251 .c and .h files plus perhaps 50 other files with a copyright
# statement. One statement uses 717 bytes.
# 
#   300 * 717 = 210k
# 
# Wow.
# 
Yes, and the COPYING file in the source directory contains the entire GPL... 
I imagine the total size could be quartered with a reference to that file..
Not that I'm volunteering to change them ;)

[snip]
# > >  - The ChangeLogs are growing *fast*. The main and module
# > >    changelogs have about 350k.
# > > 
# > > > The ChangeLogs are getting out of hand.
# > > 
# > > Indeed. I guess we should probably remove them from the distribution
# > > and provide them in some other fashion.
# > 
# > Hmm.
# 
# I mean, who uses the ChangeLogs anyway. Only the developers. Anybody
# else will be hard pressed to extract any useful information from them.
# SuSE for example takes all ChangeLogs out of the packages and provides
# a ChangeLog package (that probably nobody installs).
# 
Right, as long as they still stay in the CVS tree :)
Still, I think the ChangeLogs should be rotated out of the reposatory, say,
monthly.  That would theoretically keep the size down near 32k (judging by
the fact that that most of the changelogs are 10-11 months old.)

# Bye
# 
# Dominik ^_^
# 
# 
On the FvwmBanner stuff, I agree that all but the internal pixmap (which I
personally think there should be only one of, but that's just my opinion)
should be externalized, and FvwmBanner should be able to accept a pixmap as
a command line parameter.  Additionally, I suggest a command line option or
.fvwm2rc option that can make FvwmBanner wait until it's done displaying its
banner to send the startup notification (this way colormap problems could be
avoided).  I'd be happy to do either or both of those, but I'd need some
feedback as to where to set the option, or if there's a reason it shouldn't
exist.

-- 
Ben Winslow / [email-masked] / |Rain| / freshmeat news squad

Knowledge is of no value unless you put it into practice.
- Heber J. Grant

---

From: Ben Winslow <[email-masked]>
Date: Thu, 16 Sep 1999 15:58:12 -0400 (EDT)

On Thu, 16 Sep 1999, Ben Winslow wrote:

# On Thu, 16 Sep 1999, Dominik Vogt wrote:
# 
[snip]
# On the FvwmBanner stuff, I agree that all but the internal pixmap (which I
# personally think there should be only one of, but that's just my opinion)
# should be externalized, and FvwmBanner should be able to accept a pixmap as
# a command line parameter.  Additionally, I suggest a command line option or
# .fvwm2rc option that can make FvwmBanner wait until it's done displaying its
# banner to send the startup notification (this way colormap problems could be
# avoided).  I'd be happy to do either or both of those, but I'd need some
# feedback as to where to set the option, or if there's a reason it shouldn't
# exist.
# 
# 
Maybe I should read the man page instead of believing the previous mails and
making an idiot of myself!

       *FvwmBannerPixmap file

Okay, scratch the first part of that, unless you want a command line option,
too.  The second part still applies :)

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 17 Sep 1999 11:58:30 +0200

> Not that I'm volunteering to change them ;)

As always. When it comes down to changing hundreds of files I'm
the idiot who does the work :-) Perhaps a shell script can do the
work this time.

> Right, as long as they still stay in the CVS tree :)

Of course. They are invaluable to me, but they are trash in the tarball.

> monthly.

No! I need the old entries too. I could imagine to rotate the old
entries into a new file that is too in the repository for each new
release (i.e. remove the entries that came in for the release before
the current one). This way CVS access time can be reduced.

> avoided).

Do we need an option? We could simply delay that notification until after
FvwmBanner is done displaying the pixmap, just before it exits (is there a
possible race condition with shutting down the pipe?).

> I'd be happy to do either or both of those, but I'd need some

I like the idea of a command line argument much better than the current
fvwm resource. It's more flexible.

Bye

Dominik ^_^

---

From: Mark Rainford <[email-masked]>
Date: Fri, 17 Sep 1999 11:37:11 +0100

> the idiot who does the work :-) Perhaps a shell script can do the

This perl snippet edits the "*.c" files in place (try before you buy !)

   perl -i -ne 'if (/This program is free software/../MA  02111-1307 
USA/)
        {print "/*\nGPL pointer\n" unless $f++;} else {print;}'  *.c
-- 

Regards,  Mark.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 17 Sep 1999 13:26:47 +0100

>  - FvwmTheme generates a lot new code in most modules.

I didn't think the extras lines of code in modules to make them colorset
aware was that big. Or do you mean the size of the executables?  What
are the chances of getting fvwmlib built as a shared library? Does make
distcheck strip the binaries?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 17 Sep 1999 15:29:56 +0200

On Fri, Sep 17, 1999 at 01:26:47PM +0100, Tim Phipps wrote:
> aware was that big. Or do you mean the size of the executables?

I mean lines of code. At least IconMan, Buttons and Pager need
a lot of LOC to handle colour sets. And don't forget all the changes
related to gradients in Graphics.c. And it's not critical anyway
since it's useful code.

> What are the chances of getting fvwmlib built as a shared library?

That won't help for the size of the tarball. I think Steve had
already looked into this a while ago.

> Does make distcheck strip the binaries?

make distcheck doesn't generate binaries at all. To strip the binaries
you would call 'make strip'. Anyway, since I was not talking about the
size of binaries...

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Fri, 17 Sep 1999 09:41:03 -0400

> fvwm resource. It's more flexible.

I don't know where the confusion is coming from.  This is in the man
page:

You  can also give  it an  optional  file parameter, like  'FvwmBanner
doomface.xpm' or specify an alternate default pixmap via configuration
options (see "*FvwmBannerPixmap" below).

(It already accepts a command line parameter.)

---

From: Ben Winslow <[email-masked]>
Date: Fri, 17 Sep 1999 17:11:54 -0400 (EDT)

On Fri, 17 Sep 1999, Tim Phipps wrote:

# Dominik Vogt wrote:
# 
# >  - FvwmTheme generates a lot new code in most modules.
# 
# I didn't think the extras lines of code in modules to make them colorset
# aware was that big. Or do you mean the size of the executables?  What
# are the chances of getting fvwmlib built as a shared library? Does make
# distcheck strip the binaries?
# 
# Cheers,
# Tim.

I second the motion to have fvwmlib as a shared library-  I've been tossing
around the idea of making a GTK based configurator for fvwm, and having a
shared fvwmlib I can link to would make it really easy to provide a preview,
even if somebody else writes it before I do.

---

From: [email-masked] (Paul D. Smith)
Date: 24 Sep 1999 11:50:04 -0400

>> The ChangeLogs are getting out of hand.

  dv> Indeed. I gues we should probably remove them from the distribution
  dv> and provide them in some other fashion.

There was some subsequent discussion to this that I lost, but for the
record I oppose removing the ChangeLogs.

Remember that the primary goal of the NEWS file is to introduce new
user-visible features and changes.  That leaves the goal of providing
detailed information on bugs fixed, etc. to the ChangeLog.  I really
don't want to see them left out of the tarball; I look at ChangeLog's
for programs all the time, myself.

If they're getting too big we can split them and only ship the changes
for the last release for now.  If/when fvwm development starts slowing
down we can ship more background.

Personally I don't think a large tarball is that big a deal for a
release these days.  _Many_ people will be pulling a .rpm or .deb
anyway, not the source tarball.

Anyway, that's my $0.02.

-- 
-------------------------------------------------------------------------------
 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: Dominik Vogt <[email-masked]>
Date: Fri, 24 Sep 1999 18:06:16 +0200

> down we can ship more background.

Yup, I think that was the most recent suggestion. Anyway, I guess
nothing will happen with the ChangeLogs anyway if makes the effort
(I won't). Personally I want to have the Changelogs in one piece when
developing. We could cut off a ChangeLog for shipping that has only
the entries since the last release.

> anyway, not the source tarball.
 
I would have assumed most people simply wait until the package
appears in their favourite Linux distribution.

As an aside note: SuSE 6.2 that's out for a month now finally
has a 2.2.2 package. It's as big as 9.4 MB! I guess they forgot
to strip the executables (the old 2.0.46 package was about 1.5 MB).

> Anyway, that's my $0.02.

If I got these 2 cents for every mail I'd be filthy rich :-)

Bye

Dominik ^_^