Subject: FVWM CVS: fvwm dane

From: CVS <[email-masked]>
Date: Sun, 21 Mar 1999 10:36:29 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	dane	99/03/21 10:36:29

Modified files:
	.              : ChangeLog NEWS 
	fvwm           : fvwm2.1 
	libs           : Picture.c 

Log message:
* NEWS: Updates on form pasting, ImagePath adding, ColorLimit.

* libs/Picture.c (SetImagePath): Add to the existing image path.

* fvwm/fvwm2.1 (ImagePath): Indicate that ImagePath adds to the front
of the image path.  Document that there is a builtin image path.

--
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: Sun, 21 Mar 1999 12:53:44 -0500 (EST)

> of the image path.  Document that there is a builtin image path.

The ability to add to a path is a useful one, but I wonder if this is the
right way to go about it.

1. There is no way to replace a path wholesale.  You may not find this a
useful feature, but others will.  Ditto for the ability to append rather 
than prepend to the path.

2. ImagePath and ModulePath now differ: one sets the path, the other adds
to the path.  This is an unnecessary confusing difference.

3. I'm not sure we even WANT a builtin path --- I was moving to get rid of
it.  It is more confusing than useful to have something settable at both
build- and run-time.  We could, instead, put the default path into the
sample fvwm2rc files.

How about doing both ImagePath and ModulePath in the following way.  The
command will set the path, but a special token --- say '+' --- indicates
the previous setting.  Thus you could do:

	ModulePath /usr/local/special/modules:+

to prepend or

	ImagePath /a/b:+:/c/d

to both prepend and append to the image path.

If this sounds familiar, it should.  This same issue came up last fall in
the context of ModulePath, and someone suggested exactly this '+'
mechanism.  However, an alternative mechanism was implemented, by
having fvwm export an environment variable FVWM_MODULEDIR so that one
could use "ModulePath /user/local/special:$FVWM_MODULEDIR".

I strongly urge that we adopt a uniform mechanism for all path-setting
commands.  

Exporting a variable, while expedient, is not the best idea.  It is
backward from traditional practice.  Typically users export the variable
to modify a program's behaviour, rather than programs exporting variables. 
Sure, there are exceptions like DISPLAY or SHELL, but these ought to be
exceptional for a very good reason.  There is no compelling reason to have
FVWM_MODULEDIR exported. 

In fact, there is a compelling reason to NOT export it.  It came up on the
list a few weeks back.  Someone wanted the ability to override the
built-in module directory setting at build time, a reasonable request. One
decent way to do so is to set FVWM_MODULEDIR before configuring, and have
configure set the default module directory based on whether or not this
variable is set.  Ooops!  It is always set, because your shell is a child
of fvwm.  It is always set to what the *installed* fvwm is using, so
configure can't use this variable in any useful way. 

In summary: both ImagePath and ModulePath should behave in a similar
fashion.  Both should have the ability to reference the previously-set
path.  I don't much care what the chosen token is, but environment
variables are not a good mechanism. 

In fact, if they used the same token, you can implement all path setting
in a single function "setPath(char** path_pointer, char* newValue)".  One
can set the image path with "setPath( &ImagePath, newvalue )" and the
module path with "setPath( &ModulePath, newvalue )".

Finally: I don't much care for the idea that a function frees memory
allocated by its caller:

	void SetImagePath( char* newpath )
	{
	...
	free( newpath );
	...

This style is extremely confusing and error-prone in my experience.  And
if you desperately want to adopt it, it must be documented in big red
flashing bold letters somewhere!!!

--
Steve Robbins                              <[email-masked]>

The revolution will not be televised.

---

From: [email-masked] (Paul D. Smith)
Date: 21 Mar 1999 15:20:07 -0500

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

  sr> If this sounds familiar, it should.  This same issue came up last fall in
  sr> the context of ModulePath, and someone suggested exactly this '+'
  sr> mechanism.  However, an alternative mechanism was implemented, by
  sr> having fvwm export an environment variable FVWM_MODULEDIR so that one
  sr> could use "ModulePath /user/local/special:$FVWM_MODULEDIR".

That was me.

  sr> I strongly urge that we adopt a uniform mechanism for all
  sr> path-setting commands.

  sr> Exporting a variable, while expedient, is not the best idea.  It
  sr> is backward from traditional practice.  Typically users export the
  sr> variable to modify a program's behaviour, rather than programs
  sr> exporting variables.  Sure, there are exceptions like DISPLAY or
  sr> SHELL, but these ought to be exceptional for a very good reason.
  sr> There is no compelling reason to have FVWM_MODULEDIR exported.

I agree that (a) we should use a uniform method and (b) typically users
export env. vars. to modify subprocess behavior, but I _strongly_
disagree there's no compelling reason to export the environment var.

I use that variable in many of my scripts.  For example, I have a shell
script I run a fvwm init time that creates a menu of all the builtin
modules; I need to know where to look for those modules.

My argument for the env. var. being exported by fvwm is still quite
relevant, I think: _if_ we are going to change the directory name with
every single release, then there should be a simple, programmatic way to
obtain that value in scripts, modules, etc. from FVWM.  Otherwise you're
virtually gauranteeing that people will be editing some part of their
setup every release.

Plus, on a purely practical level, the env. var. exists in 2.2 and I'd
be very opposed to removing it in the future without excellent reason,
on backward-compatibility grounds.

And finally, I don't think it's all _that_ strange.  Plenty of tools
that invoke subprocesses use the environment to pass information; that's
a perfectly common and respectable method of doing so.

  sr> In fact, there is a compelling reason to NOT export it.  It came
  sr> up on the list a few weeks back.  Someone wanted the ability to
  sr> override the built-in module directory setting at build time, a
  sr> reasonable request. One decent way to do so is to set
  sr> FVWM_MODULEDIR before configuring, and have configure set the
  sr> default module directory based on whether or not this variable is
  sr> set.  Ooops!  It is always set, because your shell is a child of
  sr> fvwm.  It is always set to what the *installed* fvwm is using, so
  sr> configure can't use this variable in any useful way.

Yes, I agree that that's a shame.  But this is an obscure situation and
easily worked around; I don't think it rises to the level of being a
compelling argument for removing the env. var.

  sr> In summary: both ImagePath and ModulePath should behave in a similar
  sr> fashion.  Both should have the ability to reference the previously-set
  sr> path.  I don't much care what the chosen token is, but environment
  sr> variables are not a good mechanism. 

Contrariwise, I think it _is_ important to provide the modulepath via
the environment, since it's so variable, and it's needed both within the
config file and by processes the config file invokes.

Imagepath I'm less concerned about, since it won't change
release-to-release, although it would be nice to still have a "write
once" mentality and allow that value to be changed in one place and
allow anyone else who might need it to get it without changing.

I don't care if we modify the behavior, either, but I don't want to lose
any functionality.  If we remove the existing env. var., some method
must be provided to take its place.

  sr> In fact, if they used the same token, you can implement all path
  sr> setting in a single function "setPath(char** path_pointer, char*
  sr> newValue)".  One can set the image path with "setPath( &ImagePath,
  sr> newvalue )" and the module path with "setPath( &ModulePath,
  sr> newvalue )".

Of course, if you use env. vars. you don't have to do _anything_, since
they already allow env. vars ;).

-- 
-------------------------------------------------------------------------------
 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: Steve Robbins <[email-masked]>
Date: Sun, 21 Mar 1999 17:51:40 -0500 (EST)

> modules; I need to know where to look for those modules.

OK, you've convinced me ;-)  that's a pretty good reason for subproceses
knowing about FVWM_MODULEDIR that I didn't think of.

> a perfectly common and respectable method of doing so.

It may be common; I don't know.  I couldn't think of many.  I'm
comfortable with using environment variables *if and only if* there is no
better way. 

> config file and by processes the config file invokes.

OK, but hold on.  For modules, we are only exporting the "system" DIR, not
the entire PATH.  Maybe we should instead really *be* exporting the path?

The module-menu script that you mentioned currently has access only to
fvwm-installed modules.  One might desire the entire path instead.

> must be provided to take its place.

OK, how about allowing these paths to be used as arguments in "Exec", like
the $d, $w, $x, and $y expanions?  $ModulePath and $ImagePath, perhaps?
Then you could invoke your module-menu script via

	AddToFunc "InitFunction"
	+	  "I"			Exec module-menu $ModulePath

No?

It's the end of the world as we know it, and I feel fine.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 22 Mar 1999 02:43:15 +0300 (IDT)

Can I suggest an idea?

On 21 Mar 1999, Paul D. Smith wrote:

> sr> exporting variables.Sure, there are exceptions like DISPLAY or

I agree with Steve (before it was converted by Paul (: ). Setting
environment variable to inform about fvwm compile-time information is not
good. What if fvwm will need provide other information in the future.
Do we need to flood environment space of every spawned by fvwm process
with environment variables (FVWM_MODULEDIR, FVWM_STANDARDIMAGEDIR,
FVWM_MISC..)? I think, no, if there is other way to provide fvwm
internal information.

> I use that variable in many of my scripts.For example, I have a shell
> script I runa fvwm init time that creates a menu of all the builtin

Being able to know module dir is nice, but if environment variable is
used for this it restricts you. You can run your scripts *only* inside
fvwm run. Your scripts will not work *before* lanching fvwm.

The solution can be having fvwm-config utility (like gnome-config,
gtk-config, glib-config etc.), which can be queried by shell scripts,
about all fvwm info, like:

  fvwm-config --moduledir
  fvwm-config --imagedir

Or even fvwm executable iself can provide this info.

> Plus, ona purely practical level, the env. var. exists in 2.2 and I'd

Implementing suggested above method will break recent scripts based
on $FVWM_MODULEDIR, but will make things more consistent in the future,
when new info must be provided by fvwm.

Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sun, 21 Mar 1999 20:16:55 -0500

> build- and run-time.  We could, instead, put the default path into the

All these arguments make sense to me, but bear in mind what I am after
is a way to make the old "PixMapPath" + "BitMapPath" continue to work.
Since they   added to each   other,  rather than  replace one  common
variable, we were  breaking existing configurations with the ImagePath
enhancement.

In the case of image path, I don't see much harm  is leaving old stuff
at the end of the path.  Not unless you intentionally  want an icon to
be  not found.  I'll  read   the rest of  the  thread  and see if  the
solutions proposed  include a    way  to deal with   keeping  existing
configurations working.

As far as  freeing something malloced by the  caller, I saw the caller
doing the malloc when I didn't need  it anymore, and inertia caused me
to be sloppy.  (The callers malloc  isn't required anymore.)  I'll fix
it up.  (Too late   to  claim I  would  have  fixed it without   being
caught.)

--
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: [email-masked] (Paul D. Smith)
Date: 22 Mar 1999 00:46:01 -0500

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

  >> And finally, I don't think it's all _that_ strange.  Plenty of
  >> tools that invoke subprocesses use the environment to pass
  >> information; that's a perfectly common and respectable method of
  >> doing so.

  sr> It may be common; I don't know.  I couldn't think of many.  I'm
  sr> comfortable with using environment variables *if and only if*
  sr> there is no better way.

Well, there are always _different_ ways.  Quite often, better is in the
eye of the beholder :).

  >> config file and by processes the config file invokes.

  sr> OK, but hold on.  For modules, we are only exporting the "system"
  sr> DIR, not the entire PATH.  Maybe we should instead really *be*
  sr> exporting the path?

Yes, I've thought of that too.  My position at the moment is that the
important thing is to provide this particular information, since we have
modified the installation such that it changes with every release.

Presumably the other paths are much more "fixed" and hardcoding them
isn't as big an issue.

Anyway, it's one justification :).

  >> must be provided to take its place.

  sr> OK, how about allowing these paths to be used as arguments in
  sr> "Exec", like the $d, $w, $x, and $y expanions?  $ModulePath and
  sr> $ImagePath, perhaps?  Then you could invoke your module-menu
  sr> script via

  sr> 	AddToFunc "InitFunction"
  sr> 	+	  "I"			Exec module-menu $ModulePath

Well, it's OK with me but we, in effect, already have that now because
env. vars. are expanded here.  This is basically exactly what my code
does now, use the env. var. on the command line.

I've often wished fvwm's config had variables, but the prevailing
attitude seems to be to use cpp or m4 for that...

---

From: [email-masked] (Paul D. Smith)
Date: 22 Mar 1999 00:54:57 -0500

%% Mikhael Goikhman <[email-masked]> writes:

  mg> What if fvwm will need provide other information in the future.
  mg> Do we need to flood environment space of every spawned by fvwm
  mg> process with environment variables (FVWM_MODULEDIR,
  mg> FVWM_STANDARDIMAGEDIR, FVWM_MISC..)?

Remember, I'm only really interested in paths that will change with
every release.

  mg> The solution can be having fvwm-config utility (like gnome-config,
  mg> gtk-config, glib-config etc.), which can be queried by shell scripts,
  mg> about all fvwm info, like:

  mg>   fvwm-config --moduledir
  mg>   fvwm-config --imagedir

This would be OK, but:

 a) Can't address Steve's issue about knowing _all_ the paths in the
    config file; this provides only the defaults.  That may be
    enough... or it may not be.

    In particular what if we do away with a default imagedir altogether?

    Only a fully-initialized fvwm2 with the config loaded has _all_ the
    info needed.

 b) I worry about versioning issues; what if the version of fvwm2 you
    run and the version of fvwm-config you run don't match?

    What if you have fvwm2 for most people, and fvwm2-2.3.1 for others?
    How will you know how to run the right fvwm-config script?

  mg> Or even fvwm executable iself can provide this info.

This could be more accurate, but given the strange invocations people
use with m4, etc. it would be impossible to just invoke "fvwm2
--modulepath" and get the path.  You could still do the simple builtins,
of course.

The config script stuff is very nice and simple for straightforward
installations, but I have a very complex installation here with many
different OS versions installed in essentially the same filesystem,
different versions all available at once, etc.

---

From: Steve Robbins <[email-masked]>
Date: Tue, 23 Mar 1999 19:45:46 -0500 (EST)

> is a way to make the old "PixMapPath" + "BitMapPath" continue to work.

Ah.  So if that's the case, how about just fixing PixmapPath and
BitmapPath (in functions.c:pixmapPath_function and bimapPath_function,
respectively)?  You can use GetImagePath and SetImagePath to do what you
want.

--
Istanbul was Constantinople,
now it's Istanbul, not Constantinople.
Why did Constantinople get the works?
That's nobody's business but the Turks'!

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 10:46:24 -0500

> respectively)?  You can use GetImagePath and SetImagePath to do what you

Good, I've got you doing it.  (Its really "PixmapPath" and "IconPath".)

No problem,  but then  I have 2  obsolete  commands doing something no
other  command     does, so   I'll have  to     add  the   new command
"AddToImagePath".  Of course  I could go  with the ":+:" change, but I
really wanted to just get  existing configurations working, and  spend
more time on customization.

I  really  think we  need  builtin   paths.  I'm  trying   to simplify
installation  and    customization.   Making each    user  know  where
everything is installed won't help.

I would vote for making ModulePath work the same as ImagePath.

Any more votes for "AddToImagePath" in addition to "ImagePath"?

---

From: Steve Robbins <[email-masked]>
Date: Wed, 24 Mar 1999 11:06:04 -0500 (EST)

On Wed, 24 Mar 1999, Dan Espen wrote:

> other  command     does,

Yes, but inconsistency is not a problem with obsolete commands!

> so   I'll have  to     add  the   new command

I'd rather spend the time now on a consistent behaviour than have a lot of
add-hoc nonsense that is impossible to remove later.  [How did we come to
have two image-paths, anyway?]

> I  really  think we  need  builtin   paths. 

Yes for modules; no for images.  We don't install images to any standard
place.  

In a perfect world the icon package (fvwm-icons) would install itself with
a script that FVWM's configure could query to find out where the icons
live.  *THEN* a built-in path would make sense.

> I would vote for making ModulePath work the same as ImagePath.

Absolutely.
 
> Any more votes for "AddToImagePath" in addition to "ImagePath"?

We need the ability to both PREpend and Append to the paths.  I would
rather one powerful command, say ImagePath with some '+' token, than three
commands: SetImagePath, AppendImagePath, and PrependImagePath.  But maybe
that's just me.

There's a little bit of Elvis in everybody.
Except Michael J. Fox -- he's the anti-Elvis.

---

From: Dan Espen <[email-masked]>
Date: Wed, 24 Mar 1999 13:33:53 -0500

> Yes, but inconsistency is not a problem with obsolete commands!

Message from user in 2010:  You removed the obsolete command "PixmapPath"
which I still use because its the only command I found that worked.
Please but it back.

> have two image-paths, anyway?]

I believe one was for Pixmaps (color) and the other for Bitmaps (black
and white).  Realizing later that the world isn't so neatly organized,
both commands set paths for both image types.

> live.  *THEN* a built-in path would make sense.

I think the new "FvwmDefaults" will include menus.
As it is, system.fvwmrc refers to a number of icons.  I intend to install
the icons that are directly referred to in the new FvwmDefaults.

So the "perfect world" is not so far away, and I think we need builtin
icon paths.

> > I would vote for making ModulePath work the same as ImagePath.

This is not so clear.  I intended my sentence to mean that
both ModulePath and ImagePath would adopt the behavior of the
new ImagePath.  Both commands would add to the front of the path.

> commands: SetImagePath, AppendImagePath, and PrependImagePath.  But maybe

Why do we need all  this elaborate control over  the imagePath?  Isn't
this unnecessary bloat?

I started to try to code one of those "+" thingies.  It was taking too
long,  so I settled  for  just  plain  prepend,  which acts just  like
setting the path unless you want  to NOT find  something.  I can't see
why you would want to not find an image (or a module).

As you all might have noticed, I dived  into ImagePath, did my damage,
and now I'm out.  I don't mind going back  in to change ImagePath back
to its old behavior, as  long as PixmapPath  and IconPath continue  to
work as they once did,  but if anyone  else wants  to tackle the  more
elaborate "+" stuff, explain why we need it and then go for it.

---

From: Steve Robbins <[email-masked]>
Date: Thu, 25 Mar 1999 08:29:16 -0500 (EST)

> and white).  Realizing later that the world isn't so neatly organized,
               ^^^^^^^^^^^^^^^
> both commands set paths for both image types.

This illustrates my point, I think, of the danger of making ad-hoc
changes. 

> Why do we need all  this elaborate control over  the imagePath?  Isn't

It is for ModulePath that I want elaborate control, for the same reason I
like to have elaborate control over PATH.  ImagePath just happens to
inherit this behaviour. 

Speeding motorcycle ... won't you take me ...