Subject: Status update

From: [email-masked]
Date: Tue, 10 Nov 1998 20:29:40 +0100

Hi folks,

we have got done pretty much in the last few weeks. The
list of urgent problems shrinks by the day and we are fast
approaching 2.2. Here goes a list of things that have to be
done before. Have I forgotten anything? Comments?

new stuff:
 - Manpage for FvwmButtons panels (alomost done)
 - Update of FvwmButtons panels patch (optional)
 - Tim's menu-warp patch (almost done)
 - German's newmenu patches (optional, how is the status, German?)
 - Window attraction patch (I want that badly :-) )
 - Go through a list of minor patches and add them (do you
   have some results on this already, Dan?)
 - Get the copyrights straight (80% done)
 - Write the AUTHORS file. Everyone who contributed should
   be listed there.

fixes:
 - Fix the remaining memory leaks
 - Do a thorough purify session that uses most features
   (and fix the bugs of course)

and finally:
 - announce a full-fledged beta test

If we proceed at the same pace we can definitely have the
early in December and perhaps 2.2 as a christmas present.
Sounds nice 8-)  After that I'll reduce my workload
drastically and pass whatever responsibilities I took to
the list.  In fact I'm doing little more than most of you
right now.  This communal effort works surprisingly well!
Keep up the *excellent* work guys.

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.hpc.uh.edu/fvwm/>.
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, 10 Nov 1998 15:51:43 -0500

>    have some results on this already, Dan?)

Would you believe my employer has been keeping me busy?

I  think I've gone thru    everything I had    in my inbox.  I  didn't
actually  come up  with any   changes.   Many  of the  patches  became
obsolete or got applied.   Here are the 3  I feel compelled to comment
on:

Date: Wed, 17 Jun 1998 19:53:02 -0400
From: Jakub Jasinski <[email-masked]>
--- fvwm-2.0.46/fvwm/resize.c.orig      Wed Jun 17 18:21:41 1998
+++ fvwm-2.0.46/fvwm/resize.c   Wed Jun 17 19:23:04 1998
@@ -1,3 +1,4 @@
+/* Jakub Jasinski ([email-masked]) minor patch: resize frame
simplified */

Status, rejected, don't know why I'd want the resize frame simpler.

Date: Wed, 17 Jun 1998 21:44:12 -0400
From: Jakub Jasinski <[email-masked]>
Subject: in place of that lame colors.c.patch here comes newhilightcolor.patch. enjoy!
This new patch adds a new .fvwm2rc command, NewHilightColor (ala
HilightColor).
syntax:
NewHilightColor  (foreground) (background) (topshadow) (bottomshadow)
again, to make fvwm2 look more like  mwm here's the eleet color combo:

Status: Rejected. Although I have problems with fvwm2's calculation of
shadow  and highlight colors,  I think Rob would  have  rejected it as
bloat.

Date: Sun, 19 Jul 1998 17:27:38 -0700
From: brian moore <[email-masked]>
Subject: Re: fvwm-2.0.47d released
Okay, finally nailed it.... :)

Status: Pending. This  patch gives a  fix to  FvwmAudio so  that if it
gets a  message  that exceeds MAX_BODY_SIZE it   won't core dump.  The
patch is  for FvwmAudio only,   and I don't  think its  not in a valid
patch format.  It  looks to me like FvwmAudio  still  has the problem,
unless we did some truncation  somewhere else.  The long message comes
from a really long Netscape  window title.  Have we  fixed this on the
sending side?

I've filed these temporarily as "fvwm_rejected" and "fvwm_pending".

> This communal effort works surprisingly well!

I  think so too, imagine  if we had an  even larger  group with update
access.  Even with  the group we  have  now, it seems  chaotic, but it
seems to work.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: German Jose Gomez Garcia <[email-masked]>
Date: Wed, 11 Nov 1998 09:14:24 +0100 (MET)

>  - German's newmenu patches (optional, how is the status, German?)

	Well, I've been a little busy, I tried to upgrade to glibc-2.1 
pre series and my box got totally screwed!, I had to restore a backup
(dated 13-9-98... :( and I lost some things in the process, one of them
the last version of the newmenus patch (I know, I know, BACKUP are 
important...); after that I decide to integrate the old version (that 
works pretty well) in the CVS tree, but now we have a 2.1.1 version 
around, (I've been disconnected from the net during a time, because our
mailserver crashed on saturday and was down until yesterday), my question
is in what should I integrate the newmenus?, in the main CVS tree?, in 
the 2.1.1 version? in any particular branch of the CVS tree?, if the answer
is in the CVS tree, it would be enough to send a encrypted password to 
the mailing list administrator?

	Finally I have a suggestion, what about a fvwm-workers-digest
mailing list? nowadays I am receiving more than twenty mails a day from
the list, it would be nice to have an option to just get a big mail, what 
do you think?

<>-------------------------------------+-----------------------------------<>
   One O.S. to rule them all,          |  German Gomez Garcia
      One O.S. to find them.           |  [email-masked]
   One O.S. to bring them all          |
      and in the darkness bind them.   |  "Wur Qanar Wur Stilor Wur Kas"
<>-------------------------------------+-----------------------------------<>

---

From: [email-masked]
Date: Wed, 11 Nov 1998 10:32:42 +0100

On Wed, Nov 11, 1998 at 09:14:24AM +0100, [email-masked] wrote:
> ...  in the CVS tree, but now we have a 2.1.1 version 
> is in what should I integrate the newmenus?

Into the CVS tree if you feel confident that it runs fairly well (2.1.1
is already obsolete again).

> if the answer is in the CVS tree, it would be enough to send a encrypted
> password to the mailing list administrator?

Basically yes. It has become practice however that one of the people
with commit privileges advocates you before giving out the rights
to do so (I do always abstain from these votes). At least people 
should have the chance to voice objections (not that I think that
will happen).

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Wed, 11 Nov 1998 09:18:08 -0500 (EST)

> should have the chance to voice objections (not that I think that

It should be noted that having write access on the CVS is not required to
submit a change, be it a feature or fix.

Anyone can pull down the CVS tree and generate a diff for it very easily. 
Then post the patch (if small enough) or just announce (if the patch is
large) that you have a patch for such-and-such.  One of the maintainers
will commit the patch into the tree on your behalf. 

If you do this frequently enough, you'll be granted CVS write privileges
in short order!  ;-)

--
Steve Robbins                              <[email-masked]>

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

---

From: [email-masked] (Paul D. Smith)
Date: 11 Nov 1998 11:24:06 -0500

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

  sr> It should be noted that having write access on the CVS is not
  sr> required to submit a change, be it a feature or fix.

  sr> Anyone can pull down the CVS tree and generate a diff for it very
  sr> easily.  Then post the patch (if small enough) or just announce
  sr> (if the patch is large) that you have a patch for such-and-such.
  sr> One of the maintainers will commit the patch into the tree on your
  sr> behalf.

  sr> If you do this frequently enough, you'll be granted CVS write
  sr> privileges in short order!  ;-)

I agree; this is The Right Way to get privileges.  If you generate
enough work applying patches for maintainers they'll beg you to "just do
it yourself!" :)

If you don't, then write-access is just one more small administrative
burden for both you and Jason, and who needs that?  As Steve points out,
you can always get the latest stuff in the tree, and sending patches
rather than having write-privileges _removes_ a lot of responsibility:
you don't have to worry as much about breaking the tree or having the
very latest code (although it's nice :), etc.

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.hpc.uh.edu/fvwm/>.
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]
Date: Wed, 11 Nov 1998 20:03:56 +0100

> Would you believe my employer has been keeping me busy?

No. People who can do so much for fvwm can't have an employment.

> Status, rejected, don't know why I'd want the resize frame simpler.

I don't see a reason for this either.

> shadow  and highlight colors,  I think Rob would  have  rejected it as

Agreed. What is the problem with the colours?

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 11 Nov 1998 14:31:04 -0500

> No. People who can do so much for fvwm can't have an employment.

So, you don't believe it...

> Agreed. What is the problem with the colours?

Last time I checked, it would fail to create lighter or darker colors.

If you make a frame #00FF00 (green), it would attempt to create a brighter
color by increasing each rgb component 40%.

So increase 0 by 40% and you get zero.  Increase the max "FF" by 40% and
you get "FF".  So the end result is #00FF00.

Some smarter algorithm is called for.

---

From: [email-masked]
Date: Thu, 12 Nov 1998 11:24:34 +0100

>  - Manpage for FvwmButtons panels (alomost done)

Done.

>  - Update of FvwmButtons panels patch (optional)

Done.

>  - Tim's menu-warp patch (almost done)

Done.

>  - German's newmenu patches (optional, how is the status, German?)

Pending.

>  - Window attraction patch (I want that badly :-) )

Pending.

>    have some results on this already, Dan?)

80%

>  - Get the copyrights straight (80% done)

85%

>  - Write the AUTHORS file. Everyone who contributed should

Pending.

>  - Fix the remaining memory leaks

Done (but not verified)

>    (and fix the bugs of course)

Pending.

>  - announce a full-fledged beta test

Pending.

Bye

Dominik

---

From: Tim Phipps <[email-masked]>
Date: Thu, 12 Nov 1998 13:11:35 +0000

> Agreed. What is the problem with the colours?

It doesn't pick topshadow and bottomshadow colours with the same
algorithm as Motif.  I don't know what their algorithm is (and it
changed from 1.1 to 1.2) but it does some fairly fancy stuff when the
background colour gets very light or dark.  If you can run a CDE session
in pseudocolor and then run the style manager you can change your
colours interactively and watch it do the top/bottomshadow colours. 
When you go dark there is a point at which the bottomshadow becomes
lighter than the background.  There is also a point at which the
topshadow becomes darker than the background.

Does anyone know if the Xaw3d library does any better than Fvwm.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 08:18:51 -0500

> topshadow becomes darker than the background.

Somewhat like the algorithm I imagine.

I  thought it would make sense  to detect overflows in  the  R G and B
values.  If  R  overflows, distribute it to  B  and G, etc.   When all
done, if there  is still unapplied overflow, it  could  be because you
were trying to brighten white.  So instead darken it.

> Does anyone know if the Xaw3d library does any better than Fvwm.

Good suggestion, haven't looked there yet.

---

From: [email-masked]
Date: Thu, 12 Nov 1998 14:44:40 +0100

> were trying to brighten white.  So instead darken it.

CDE seems to calculate contrast, not brightness; even depending
on the colour (red is brighter than blue). At home I'll try to
think of a formula that duplicates CDE's behaviour.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 08:55:47 -0500

> think of a formula that duplicates CDE's behaviour.

Just a note about a trap you might fall into.

When  I  first  tried to  do  colorlimiting, I   took the most logical
approach which was to use  the built in X CMS  routines to convert RGB
to HVC.

I  think   you could then   directly  adjust  the  'V' component,  for
brightness (maybe its 'C')?   But anyway,  thats not  the point.   The
point is,  for some colors, these  routines can make upwards of 40,000
iterations (or  some  number    like   that) during some   of    their
calculations.  Clearly not  a   good idea during   colorlimiting,  and
probably not the best idea anywhere in fvwm.

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 09:19:05 -0500

> Good suggestion, haven't looked there yet.

Except for allowing user overrides, and a override on contrast,
the logic is no better than fvwm.

---

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 12 Nov 1998 12:36:58 -0500 (EST)

On Thu, 12 Nov 1998, Tim Phipps wrote:

: [email-masked] wrote:
: > Agreed. What is the problem with the colours?
: 
: It doesn't pick topshadow and bottomshadow colours with the same
: algorithm as Motif.  I don't know what their algorithm is (and it
: changed from 1.1 to 1.2) but it does some fairly fancy stuff when the
: background colour gets very light or dark.  If you can run a CDE session
: in pseudocolor and then run the style manager you can change your
: colours interactively and watch it do the top/bottomshadow colours. 
: When you go dark there is a point at which the bottomshadow becomes
: lighter than the background.  There is also a point at which the
: topshadow becomes darker than the background.
: 
: Does anyone know if the Xaw3d library does any better than Fvwm.

Speaking of Motif.... Is anyone on this list involved with "GTK" a.k.a. "The
Gimp Toolkit"?  It seems to have many Motif capabilities, but is not
dependent on lisencing problems which has lead to lots of old version
around.

I see that Netscape will be using "GTK" instead of Motif in their "NGT"
a.k.a. "Next Generation Technology" browser.

Randall

---

From: Austin Donnelly <[email-masked]>
Date: Fri, 13 Nov 1998 00:31:28 +0000

On Thu, 12 Nov 1998, Randall S. Winchester wrote:

> Speaking of Motif.... Is anyone on this list involved with "GTK"
> a.k.a. "The Gimp Toolkit"?  It seems to have many Motif
> capabilities, but is not dependent on lisencing problems which has
> lead to lots of old version around.

I have done a little work on GTK.  But I don't see what the issue is.

You say it has Motif capabilities - this is not true: GTK is not
source or binary compatible with Motif.  Yes, both are widget sets,
but that's as close as they get to being similar.

Austin

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Nov 1998 20:29:24 -0500

> I have done a little work on GTK.  But I don't see what the issue is.

We are looking  for  a non-proprietary algorithm   that produces a  3D
shadow effect, from a  base color, thats fast and  small enough  to be
used in a window manager.

We  are trying  to  come  up with something   thats  better than whats
currently in "fvwm/colors.c".   There are cases  now, that the current
algorithm doesn't give a 3D effect at all.

---

From: "Randall S. Winchester" <[email-masked]>
Date: Fri, 13 Nov 1998 12:33:11 -0500 (EST)

On Thu, 12 Nov 1998, Dan Espen wrote:

: Austin Donnelly <[email-masked]> writes:
: > On Thu, 12 Nov 1998, Randall S. Winchester wrote:
: > 
: > > Speaking of Motif.... Is anyone on this list involved with "GTK"
: > > a.k.a. "The Gimp Toolkit"?  It seems to have many Motif
: > > capabilities, but is not dependent on lisencing problems which has
: > > lead to lots of old version around.
: > 
: > I have done a little work on GTK.  But I don't see what the issue is.
: 
: We are looking  for  a non-proprietary algorithm   that produces a  3D
: shadow effect, from a  base color, thats fast and  small enough  to be
: used in a window manager.
: 
: We  are trying  to  come  up with something   thats  better than whats
: currently in "fvwm/colors.c".   There are cases  now, that the current
: algorithm doesn't give a 3D effect at all.

Beautifully put - thank you,
Randall

---

From: Michael M Han <[email-masked]>
Date: Fri, 13 Nov 1998 11:14:36 -0800

Previously...
>: algorithm doesn't give a 3D effect at all.

Anyone look at lesstif? http://www.lesstif.org/
_________
mike ([email-masked])
I will not hang donuts on my person
 - The collected wisdom of Bart Simpson
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Maciej Stachowiak <[email-masked]>
Date: Fri, 13 Nov 1998 14:39:50 EST

> algorithm doesn't give a 3D effect at all.

The following GPL code from scwm implements a good, fast 3D-shadowing
algorithm. It converts the color from RGB to HLS space, then
multiplies both the luminosity and the saturation by a specified
factor (clipping at the extremes). Then it converts back to RGB and
creates a color. The guts of it, i.e. the `color_mult' routine, looks
a bit longish, but this is only because there are 6-way conditionals
at the begining and end; it actually runs quite fast. The algorithm is
the same as Gtk's, but the implemenation is independent and more
streamlined.

Calling `adjust_pixel_brightness' with a `factor' of 1.3 for hilights
and 0.7 for shadows exactly emulates Gtk's shadowing, which is, IMO
the most visually pleasing shadowing of any widget set; using 1.2 and
0.5 respectively gives something closer to the "classic" fvwm effect
with deeper shadows and more subtle hilights, but still (IMO) smoother
and more attractive than fvwm.

The only color these routines do not usefully handle is black; black
will be returned even for a factor greater than 1.0, when optimally
one would like to see a very dark gray. This could possibly be
addressed by adding a small additive factor when brightening
colors. If anyone adds that feature, please feed it upstream to me.

Feel free to use this code in fvwm2, of course.

 - Maciej Stachowiak

=======================================

/*
 * Copyright (C) 1997, 1998, Maciej Stachowiak and Greg J. Badros
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this software; see the file COPYING.GPL.  If not, write to
 * the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
 * Boston, MA 02111-1307 USA
 *
 */

/* The hilight/shadow stuff should maybe be in a separate relief.c? */

#define SCALE 65535.0
#define HALF_SCALE (SCALE / 2)
typedef enum {
  R_MAX_G_MIN, R_MAX_B_MIN, 
  G_MAX_B_MIN, G_MAX_R_MIN, 
  B_MAX_R_MIN, B_MAX_G_MIN 
} MinMaxState;

/* Multiply the HLS-space lightness and saturation of the color by the
   given multiple, k - based on the way gtk does shading, but independently
   coded. Should give better relief colors for many cases than the old
   fvwm algorithm. */

/* FIXMS: This can probably be optimized more, examine later. */

void 
color_mult (unsigned short *red, 
	    unsigned short *green, 
	    unsigned short *blue, double k)
{
  if (*red == *green && *red == *blue) {
    double temp;
    /* A shade of gray */
    temp = k * (double) (*red);
    if (temp > SCALE) {
      temp = SCALE;
    }
    *red = (unsigned short)(temp);
    *green = *red;
    *blue = *red;
  } else {
    /* Non-zero saturation */
    double r, g, b;
    double min, max;
    double a, l, s;
    double delta;
    double middle;
    MinMaxState min_max_state;

    r = (double) *red;
    g = (double) *green;
    b = (double) *blue;

    if (r > g) {
      if (r > b) {
	max = r;
	if (g < b) {
	  min = g;
	  min_max_state = R_MAX_G_MIN;
	  a = b - g;
	} else {
	  min = b;
	  min_max_state = R_MAX_B_MIN;
	  a = g - b;
	}
      } else {
	max = b;
	min = g;
	min_max_state = B_MAX_G_MIN;
	a = r - g;
      }
    } else {
      if (g > b) {
	max = g;
	if (b < r) {
	  min = b;
	  min_max_state = G_MAX_R_MIN;
	  a = r - b;
	} else {
	  min = r;
	  min_max_state = G_MAX_B_MIN;
	  a = b - r; 
	}
      } else {
	max = b;
	min = r;
	min_max_state = B_MAX_R_MIN;
	a = g - r;
      }
    }
    
    delta = max - min;
    a = a / delta;

    l = (max + min) / 2;
    if (l <= HALF_SCALE) {
      s = max + min;
    } else {
      s = 2.0 * SCALE - (max + min);
    }
    s = delta/s;
    
    l *= k;
    if (l > SCALE) {
      l = SCALE;
    }
    s *= k;
    if (s > 1.0) {
      s = 1.0;
    }

    if (l <= HALF_SCALE) {
      max = l * (1 + s);
    } else {
      max = s * SCALE + l - s * l; 
    }

    min = 2 * l - max;
    delta = max - min;
    middle = min + delta * a;

    switch (min_max_state) {
    case R_MAX_G_MIN:
      r = max;
      g = min;
      b = middle;
      break;
    case R_MAX_B_MIN:
      r = max;
      g = middle;
      b = min;
      break;
    case G_MAX_B_MIN:
      r = middle;
      g = max;
      b = min;
      break;
    case G_MAX_R_MIN:
      r = min;
      g = max;
      b = middle;
      break;
    case B_MAX_G_MIN:
      r = middle;
      g = min;
      b = max;
      break;
    case B_MAX_R_MIN:
      r = min;
      g = middle;
      b = max;
      break;
    }

    *red = (unsigned short) r;
    *green = (unsigned short) g;
    *blue = (unsigned short) b;    
  }
}

Pixel
adjust_pixel_brightness(Pixel pixel, double factor)
{
  XColor c;
  c.pixel = pixel;
  
  XQueryColor (dpy, Scr.ScwmRoot.attr.colormap, &c);
  color_mult(&c.red, &c.green, &c.blue, factor);
  XAllocColor (dpy, Scr.ScwmRoot.attr.colormap, &c);

  return c.pixel;
}

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 14:50:47 -0500

Thanks!

Without your comments, I wouldn't  have been able  to tell what it was
doing.  I'll try to fit this into fvwm2.

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 13 Nov 1998 15:52:57 EST

> doing.  I'll try to fit this into fvwm2.

OK, looking at the message ID I guess this is inresponse to my posted
hilight generation patch.

You're welcome.

Since fvwm is starting to be actively developed again, I'd like to
bring up an old issue, that of fvwm2/scwm cooperation. I'm going to
assume for now at least that an outright merge is politically
infeasible, but I think given our shared code base and, to some
extent, similar ideals (extensibility on a behavioral and functional
rather than purely visual) level, we should find ways to work
together.

Here's a suggestion for a starting point. Recently, the idea of
splitting the fvwm icons into a separate distribution was brought
up. The icons are already split out of scwm. How about we create a
grand unified distribution of window manager images? Here are some
unsorted thoughts about the idea:

* Most OS distributions that ship with fvwm and other window managers
do not even use the icons that ship with the wm in the wm package. Red
Hat has a "fvwm95-icons" package which is actually a bunch of various
icons and mini-icons from the fvwm95 distribution.

* There's 4 basic categories of broadly interesting window manager
images: icons, mini-icons, textures and tiles. Tiles are currently not
of direct interest to fvwm or scwm, but (a) they might be in the
future and (b) it would be good to try to get other window manager
devel groups on board. Hence, I propose this directory structure for a
source tarball (of hypothetical version x.y):

wmimages-x.y/
wmimages-x.y/icons/
wmimages-x.y/mini-icons/
wmimages-x.y/textures/
wmimages-x.y/tiles/

As a start on populating these, we could take the stuff from fvwm2 and
scwm, merge it, and remove anything redundant or undistributable.

Later we could start incorporating stuff from other window managers (I
think the last fvwm95 might have interesting images that don't ship
with either fvwm or scwm's icon package). Hopefully authors will want
to cooperate with us.

* It should use autoconf and automake for configuration/make/install
stuff.

* Make it install in a rational location (IMO: not in the X11 tree).

* Possibly: Have a configure-time option to gzip xpm's when
installing, since libXpm can read gzipped .xpm files transparently.

* Highly speculative territory: Have a configure-time option to conver X

* Possibly: Install a trivial wmimages-config script so that
wmimages-compliant window managers can find the path where it is
installed at configure time.

* Possibly: set up the package so that it is easy or at least possible
for a window manager distribution to incorporate part or all of the
wmimages distribution, for use when installing on systems where
wmimages is not installed, to spare users the need to download an
extra package.

If people agree this would be a good move, I'll ask the other scwm
people what they think (I don't expect any massive objections) and
then try to work out the administrivia with both groups.

 - Maciej

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Nov 1998 16:11:04 -0500

> hilight generation patch.

You are right.  I've changed the subject line.

> scwm, merge it, and remove anything redundant or undistributable.

I think your proposal is, for phase 1, have both fvwm and scwm
ship icons, but make sure they are exactly the same icons?

Some of the other Window Managers seem to be pretty particular
about icon sizes.

There  have been proposals about  sorting or naming  icons  by size or
color   use  (8bit vs. 24bit).   I  think  fvwm2 is the   only WM with
colorlimiting where the color segregation is a non-issue.

(I'm just indentifying issues.)

As you are probably aware, fvwm2 doesn't currently install icons,
and we would like to have a way to know where the icons are, and
which icons are installed.  So this sounds like a good way to go.

Perhaps each window manager should have at least one icon it can
probe for so it can tell whats installed.

> then try to work out the administrivia with both groups.

Sounds good to me.

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 13 Nov 1998 16:32:07 EST

> ship icons, but make sure they are exactly the same icons?

No, my proposal for phase one is, set up a wmimages package in some
cvs repository, release a version of it, and have subsequent versions
of fvwm and scwm point users to that and/or incorporate it (scwm
already has a separate icon package so this is a non-issue for us -
and I saw mention of possibly splitting all the icons out of fvwm2,
but I don't know how people here feel about that).

> Some of the other Window Managers seem to be pretty particular

Umm, we could encode that in the name or segregate but that seems
distasteful somehow.

> colorlimiting where the color segregation is a non-issue.

At least WindowMaker and Enlightenment also have color limiting.

> (I'm just indentifying issues.)

Yes, they are good points, we need to come up with a policy on these
things. I think a goal for

> which icons are installed.  So this sounds like a good way to go.

Yes, but vendors do, and painfully enough, often in fvwm's compiled-in
path, which is IMO wrong for things not part of the X11 distribution.

> probe for so it can tell whats installed.

I believe the bullet points in my previous message outline a better
technical solution for finding out: (a) whether the wmimages package
is installed; and if so (b) under what path. My proposal for what
windowmanagers should do with this info is to add an appropriate
autoconf test for wmimages and munge their compiled-in image path to
be able to find the installed images.

> > then try to work out the administrivia with both groups.

Cool. Any other opinions? 

 - Maciej

---

From: Steve Robbins <[email-masked]>
Date: Fri, 13 Nov 1998 23:00:56 -0500 (EST)

On Fri, 13 Nov 1998, Maciej Stachowiak wrote:

> grand unified distribution of window manager images?

That sounds like an excellent idea to me.

> * Make it install in a rational location (IMO: not in the X11 tree).

Yes, ${datadir}, for example.
 
> installing, since libXpm can read gzipped .xpm files transparently.

Should be trivial.
 
> installed at configure time.

I like this idea.  Don't some shared libs (GNOME libs?) install with a
similar file? 

When love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.

---

From: Maciej Stachowiak <[email-masked]>
Date: Sat, 14 Nov 1998 13:53:16 EST

> Yes, ${datadir}, for example.

Yeah, I was thinking of ${pkgdatadir}, i.e. ${datadir}/wmimages, but
either option makes sense.

> > installing, since libXpm can read gzipped .xpm files transparently.

Yeah, the only drawback is possible user confusion. Do you think this
mode should be the default if gzip is found on the system?

> I like this idea.  Don't some shared libs (GNOME libs?) install with a

Several packages install with such a script, most notable guile, glib,
gtk+ and gnome-libs. It takes sooooo much of the pain out of finding
packages you depend on.

 - Maciej Stachowiak

---

From: Steve Robbins <[email-masked]>
Date: Sun, 15 Nov 1998 15:13:51 -0500 (EST)

> either option makes sense.

Yes, pkgdatadir.
 
> mode should be the default if gzip is found on the system?

Hm.  Is there a load-time penalty involved with gzip?  How bad is it?  I
would assume it isn't bad, since icons will be read only rarely.  If that
is the case, then I say: yes, make it default.

> gtk+ and gnome-libs. It takes sooooo much of the pain out of finding

Is this script associated with some standard tool (libtool?) or are they
all ad-hoc scripts?   

Don't know what I want, but I know how to get it.

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 15 Nov 1998 15:30:20 EST

> is the case, then I say: yes, make it default.

It should add no more extra time than gzip takes to decompress said
file, in fact, since gzip does streaming decompression it is partly
paralelizable. libXpm is so slow at loading .xpm files that its
routines will dominate the load time anyway.

> Is this script associated with some standard tool (libtool?) or are they

They are all ad-hoc but follow relatively standard
conventions. Perhaps there should be a meta-tool for generating them,
but that's beyond the scope of this post :-)

 - Maciej

---

From: [email-masked]
Date: Mon, 16 Nov 1998 09:17:45 -0500 (EST)

> is the case, then I say: yes, make it default.

Exactly what benefit does gzip'ing the icons give us?

On most Unix systems, the granularity of the file system usually means
that a 3.5K file and a 1-byte file take up the same amount of disk
space.  Since most XPM's are usually pretty small, especially for things
like icons, I don't see how adding the complexity of gzip'ing the icons
will provide any benefit.

If you insist on providing this capability, please give the user the
option to turn it off, or (even better) to only enable it with a
configuration option:

	./configure --with-gzip		# my preference
	./configure --without-gzip	# an alternative

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: Dan Espen <[email-masked]>
Date: Mon, 16 Nov 1998 09:33:17 -0500

> Umm, we could encode that in the name or segregate but that seems

To me too.

Afterstep does this:

  AfterStep-1.5pre6/afterstep/desktop/icons:
  drwxrwxr-x   2 dane      2048 Jul  1 15:19 16bpp
  drwxrwxr-x   2 dane      2048 Jul  1 15:20 8bpp
  drwxrwxr-x   2 dane      1024 Jul  4 11:25 common

(I don't like it.  Just starting a list.)

It would seem if we don't organize this wmicons package this way,
Afterstep would be a non-participant.

> At least WindowMaker and Enlightenment also have color limiting.

You're right,  I  did see the code  in  Enlightenment, since it wasn't
done the way I wanted to do it, I sort of forgot.

> things. I think a goal for

Doesn't look like you completed this sentence.

> be able to find the installed images.

Sounds good, actually, having autoconf look for the package is the kind
of probe I was thinking of.

> Cool. Any other opinions? 

I have too many opinions for my own good.  I bet you mean opinions on
the icon package subject only...

---

From: [email-masked]
Date: Mon, 16 Nov 1998 15:55:38 +0100

On Mon, Nov 16, 1998 at 09:17:45AM -0500, [email-masked] wrote:
> space.

> Wrong. That depends on the file system and the block size (e.g. 512 bytes).
> I'm not sure if Linux's ext2fs already has it, but there were
> ideas to put very small files directly into the inode. If not present
> now such enhancements will surely be made in the future.

Bye

Dominik

---

From: [email-masked]
Date: Mon, 16 Nov 1998 11:10:28 -0500 (EST)

> now such enhancements will surely be made in the future.

The whole world is not Linux, unfortunately.  People running on SunOS
4.1.3, as an example which I have at home have larger block sizes
thanks to the Berkeley Fast File System.

Some more reasons:

1.  Some programs cannot figure out what sort of file www.xpm.gz is.  (I
    know this is true for xpaint, whether or not the gzip'ed file is
    named www.xpm.gz or www.xpm, although it seems that xv gets it
    right.  Anybody know about GIMP?)

2.  Appending .gz to filenames makes directory listings longer.  This is
    already a problem with all those mini icons with "mini-" prepended
    to their name.  If the intention is to gzip the icons and leave the
    file extension intact, this becomes a non-issue.

3.  The `file' command can no longer discern what kind of file it is:

	$ file www.xpm.gz 
	www.xpm.gz:     gzip compressed data - deflate method , original file
	                name , last modified: Thu Oct 29 12:31:09 1998 os: Unix

    (I thought this was a compressed X-Pixmap file!)

I still think it should be up to the user to decide whether or not their
XPM files should be gzip'ed.

---

From: Lee Willis <[email-masked]>
Date: 16 Nov 1998 16:23:49 +0000

>     right.  Anybody know about GIMP?)

Correct me if I'm wrong but Gimp copes just fine with gzipped files (As
it should IMHO ...)

My 2p's worth is that fvwm should use gzipped icons transparently if
they're there, ie if you gzip your icons fvwm will carry on working but
should by default have the icons unzipped ...

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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].