Subject: removing configure options

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jun 1999 12:38:20 -0600

At present we have 14 features that can be explicitly turned
on and off with configure. Most of them don't make much sense.
And turning off all these options saves only about 20k of code.

  BORDERSTYLE
  MULTISTYLE
  EXTENDED_TITLESTYLE
  GRADIENT_BUTTONS
  PIXMAP_BUTTONS
  VECTOR_BUTTONS
  ACTIVEDOWN_BTNS
  INACTIVE_BTNS
  MINI_ICONS
  USEDECOR

All the above options do you no good except savig very little
code.

  MODALITY_IS_EVIL
  FVWM_DEBUG_MSGS
  SHAPE
  GNOME

These four are the only ones that may have user visible effects.
The debug messages are a mess anyway (you don't ever get useful
information from them), so I'd take them out too. SHAPE is probably
something to detect automatically. We could still have a fvwm
command that turns shape labels on and off. I don't know if there
are people who disable MODALITY_IS_EVIL.

What do you think, should we remove all the buttons/style/decor
related options (i.e. the first group) in a first sweep?

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: Jason Kibblewhite <[email-masked]>
Date: Wed, 09 Jun 1999 05:23:58 -0600

> related options (i.e. the first group) in a first sweep?

ok well minus the space saving of a piddly 20k if their config doesn't
use them does fvwm run any slower?  If not I see no real reason to
change the way it is now personally.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 09 Jun 1999 12:28:34 +0100

Dominik Vogt wrote:
> SHAPE is probably
> command that turns shape labels on and off.

Is the shape extension part of standard Xlib? If we remove the ability
to compile out SHAPE would we risk fvwm not compiling on some platforms?

> related options (i.e. the first group) in a first sweep?

I vote yes.

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Jun 1999 10:03:53 -0400

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

  tp> Dominik Vogt wrote:

  >> SHAPE is probably something to detect automatically. We could still
  >> have a fvwm command that turns shape labels on and off.

  tp> Is the shape extension part of standard Xlib? If we remove the
  tp> ability to compile out SHAPE would we risk fvwm not compiling on
  tp> some platforms?

Hmm.  Interesting.  Well, SHAPE is an X server extension, first, so I
suppose it's possible to compile fvwm with SHAPE enabled, then connect
to an X server that doesn't support it.  No idea what fvwm will do with
that.

Second, it's possible to build fvwm on systems where the SHAPE extension
isn't supported; I'm not familiar enough with the details of the code to
know if that will cause build errors if SHAPE isn't defined.

However, I don't think Dominik was suggesting we remove the #ifdefs for
SHAPE, only that it be determined automatically by configure and
provided as an option to the user.

My personal opinion on all these items is, if we have to make it
optionally compiled for some reason anyway (like it won't be supported
on some systems) we might as well let the user specify it, too.

-- 
-------------------------------------------------------------------------------
 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: Tim Phipps <[email-masked]>
Date: Wed, 09 Jun 1999 15:25:06 +0100

> to an X server that doesn't support it.  No idea what fvwm will do with

All the places I've seen shape stuff look like:

#ifdef SHAPE
if (ShapesSupported) {
 ...
}
#endif

so a shape enabled fvwm will work with a shape disabled server.
> provided as an option to the user.
Oh I see, that sounds better.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jun 1999 16:48:30 -0600

On Wed, Jun 09, 1999 at 05:23:58AM -0600, [email-masked] wrote:
> use them does fvwm run any slower?

No, it's not noticably slower.

> If not I see no real reason to change the way it is now personally.

Well, you don't have to maintain the code. It's a pain in the ass
to have to think about 2^14 combinations of compile options while
writing code. And many of the options don't do what they are supposed
to anyway. E.g. there are lots of places handling mini icons even if
the MINI_ICONS define is inactive.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jun 1999 16:51:46 -0600

> provided as an option to the user.

You can't remove the ifdefs completely because you may not have the
shape extension on the machine you compile.

> on some systems) we might as well let the user specify it, too.

Why not make a fvwm command that switches shapes on or off if it's
compiled in:

  ShapedIcons on/off

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 09 Jun 1999 11:09:15 -0400

>> provided as an option to the user.

Note I meant to say "_not_ provided ..." above :-/.

  >> on some systems) we might as well let the user specify it, too.

  dv> Why not make a fvwm command that switches shapes on or off if it's
  dv> compiled in:

  dv>   ShapedIcons on/off

That would work for SHAPE, since (based on Tim's description) it's
already coded that way.  It might not work for other optional features,
though (XPM support, etc.)

Note SHAPE deals with more than just icons; I'd prefer something like
ShapeExtension or UseShapeExtension.  YMMV.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jun 1999 17:22:36 -0600

> though (XPM support, etc.)

The reason why I talk about SHAPE is that there is a user visible
change in behaviour depending on if you have them or not. If you
don't like shaped icons, disabling the configure option changes
the looks of your icons, even if you don't touch the config file.

> ShapeExtension or UseShapeExtension.  YMMV.

I don't care. I noticed that some of the modules use the SHAPE #define
too, so we will have to extend the module interface.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 09 Jun 1999 16:30:15 +0100

> Why not make a fvwm command that switches shapes on or off if it's

I'd rather see style options: ShapedIconYes/ShapedIconNo,
ShapedWindowYes/ShapedWindowNo. These would default to Yes if the server
supports shapes, be fixed to No if the server doesn't support shapes,
and would only be compiled in if SHAPE is defined.

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 9 Jun 1999 17:37:46 +0200

> related options (i.e. the first group) in a first sweep?

Yes

-- 
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: Steve Robbins <[email-masked]>
Date: Wed, 9 Jun 1999 19:30:22 -0400 (EDT)

> And turning off all these options saves only about 20k of code.

OK, 20k of code ... that's less than 10% of the (stripped) size of my
linux fvwm2.  Not a big deal in terms of disk.

I wonder if there is any impact on the *in-core* size of a running FVWM if
the options are disabled?  That's the only concern I have about removing
compile-time options.  I don't know the ins and outs of all the options in
question, but part of FVWM's heritage was that it is -- or can be compiled
to be -- cheaper on memory than other WMs.  I'd hate to lose that. 

--
Steve Robbins                              <[email-masked]>

The revolution will not be televised.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 10 Jun 1999 12:40:15 -0600

> to be -- cheaper on memory than other WMs.  I'd hate to lose that. 

If we want to save memory there is only one place where it really has
a noticable impact: function and menu items. Since 2.2.0 the memory
consumption of function items has been reduced radically at the cost
of some additional code by separating the functions code from the menu
code. Functions use up 13 bytes per item + the length of the action
(assuming int = 4 bytes, short = 2 bytes, char = 1 byte, pointer = 4 bytes)
plus 20 bytes for the function structure (+ name of the function). I can't
see any potential to save more than perhaps one byte per item here.

Menu items on the other hand use up 64 bytes each (+ memory for labels and
mini icons and the action). Not using mini icons would save 13 bytes and
using two instead of three labels another 8 bytes. There might be a potential
of 4 to 10 bytes at the cost of drawing speed (some members like 'prev'
or 'label_strlen' are there only for performance reasons).

There is lots of stuff in the FvwmWindow structure too, but optimizing it
will be a painfull process.

Bye

Dominik ^_^

---

From: Steve Robbins <[email-masked]>
Date: Thu, 10 Jun 1999 11:18:49 -0400 (EDT)

On Thu, 10 Jun 1999, Dominik Vogt wrote:

> a noticable impact: function and menu items. 

I expect that you are right.  I have not checked the code nor compiled
with options off to see if the RSS is any smaller.

Maybe this question can be answered by the old-timers.  In acconfig.h
there are comments before each option symbol.  These comments came from
the Imakefile of 2.0.47, so perhaps they are no longer relevant.  But
several of them say "disabling this saves some memory."  Are any of these
comments still relevant?  If so, about how much memory are we talking
about? 

SHAPE:
 * Shaped window extensions seem to increase the window managers RSS
 * by about 60 Kbytes. They provide for leaving a title-bar on the window

ACTIVEDOWN_BTNS:
 * "ActiveUp" state is used instead.  Disabling this reduces memory
 * usage.  */

INACTIVE_BTNS:
 * is used instead.  Disabling this reduces memory usage.  */

USEDECOR:
 * the man page entries for AddToDecor and DestroyDecor.  There is a
 * slight memory penalty for each additionally defined decor.  */

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 10 Jun 1999 17:59:40 -0600

>  * by about 60 Kbytes. They provide for leaving a title-bar on the window

Don't know. I'd leave this one in *and* make a command to disable it.

>  * "ActiveUp" state is used instead.  Disabling this reduces memory

Saves less that 30 bytes (two names).

>  * is used instead.  Disabling this reduces memory usage.  */

Saves less that 50 bytes (two names and three lines of code).

BTW, the _BTNS defines change the way the buttons behave. Perhaps this
should be made configurable (if anybody uses it).

>  * slight memory penalty for each additionally defined decor.  */

I guess it saves a few k of code, several dozen bytes in the global
default decor and two pointers in the FvwmWindow structure.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Fri, 11 Jun 1999 08:42:35 -0400

> comments still relevant?  If so, about how much memory are we talking

I think I've been around long enough to fit the old-timer category,
but I don't remember any numbers.  My guess is if there were numbers,
they would have been mentioned.

I think the ifdefs are part of a general desire to stay true to the
fvwm design objectives, and the feature of "patch" that makes it so
easy to generate the ifdefs.

Perhaps not enough thought was given to the actual savings, and the
long term impact on code readability.

I think  selective  removal  would be  OK,   especially for   the more
pervasive ifdefs like mini-icons.

--
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]