Subject: CVS migo: * Updates in envvar library.

From: CVS <[email-masked]>
Date: Mon, 21 Jun 1999 12:59:43 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	migo	99/06/21 12:59:43

Modified files:
	.              : ChangeLog 
	fvwm           : fvwm.c fvwm2.1 
	libs           : envvar.c envvar.h 

Log message:
* Updates in envvar library.
* Added expanding of ${VAR} and ~ in Restart command.

--
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]
Date: Mon, 21 Jun 1999 14:05:11 -0400 (EDT)

> * Added expanding of ${VAR} and ~ in Restart command.

Minor question here:  Why just the Restart command?  Why not expand
environment variables of form ${VAR} for all commands?  This would be
more orthogonal, wouldn't it?  We could keep the current behavior if
the curly braces are omitted to avoid breaking existing config files.

Anybody else have thoughts on this?

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: Dan Espen <[email-masked]>
Date: Mon, 21 Jun 1999 14:16:28 -0400

> Anybody else have thoughts on this?

I have one instance of ${xxx} in Exec commands in my .fvwm2rc,
So I'm not crazy about the idea.
Can't say what caused my to go that way:

Exec set -A back 1 E I 8 9;rxvt -pixmap ${back[`random 5`]}

(Random pixmap backgrounds in rxvt's.)

But then I'm not really sure of the rules of {} vs. () if there are any.

--
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: Mon, 21 Jun 1999 21:17:26 +0300 (IDT)

> the curly braces are omitted to avoid breaking existing config files.

What other commands do you expect to expand $VAR? I can think about
*Path commands, but they already do this.

Regards,
Mikhael.

---

From: [email-masked]
Date: Mon, 21 Jun 1999 14:31:11 -0400 (EDT)

I'm responding to TWO messages here:

> *Path commands, but they already do this.

OK.  Here are some:

1.  Exec, Read, and PipeRead can use variables like $HOME very easily.

2.  .xsession file (or whatever it is that starts up fvwm2) can use
    environment variables for saving fvwm2 "state" information (last
    decor selected, etc.).

3.  .xsession file (ibid) can call xdpyinfo and parse out the current
    screen dimensions and/or depth (I know that these are available if
    you use FvwmM4; I'm just giving an example where such things may
    be useful).

4.  Probably more uses than you or I can think of right now, since
    users tend to use features like these in ways that we never have
    dreamed possible.  [smile]

> Can't say what caused my to go that way:

Why not allow \$ or $$ to precede things that shouldn't get parsed?
This is what the shell and make do, respectively.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 21 Jun 1999 21:50:41 +0300 (IDT)

On Mon, 21 Jun 1999, Dan Espen wrote:

> > Minor question here:Why just the Restart command?  Why not expand
> > environment variables of form ${VAR} for all commands?This would be

No, AFAIK, Exec or ReadPipe are different in that they pass the string to
the shell as is, while ImagePath or Restart do not.

> But then I'm not really sure of the rules of {} vs. () if there are any.

man sh :) Actually, some of the shell ${VAR} sub-syntax can be implemented
in libs/envvar.* if there are requests.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 21 Jun 1999 15:49:36 -0400

> the shell as is, while ImagePath or Restart do not.

No what? I think I knew that.

> in libs/envvar.* if there are requests.

OK, you shamed me into RTFMing.  I'm  a ksh user, so  I man ksh'd.  So
thats the difference...  (I look these things up when  I need to know.
Then it leaves my mind completely.)

So  we could do  some of this expansion in  libs/envvar.*, but we sure
couldn't deal with my example above.  Assuming we  don't want to break
existing config  files, doing   automatic  variable expansion  on  all
commands doesn't look like an idea whose time has come.

These e-mail discussions can  get confusing.   Mikhael, I don't  think
you proposed that we do  automatic expansion, in fact  I think you are
pointing out why we  can't same as me.   I think  Larry is asking  why
not.

So,  to answer the  e-mail  from Larry,  "$$" or "\$"  would work, but
existing config files would be broken.  I  sometimes think this is OK,
especially  when I  can  imagine a  sed  script  or some other  simple
mechanism  that could automatically  move  a config  file forward.  In
this case, I don't think that would be so easy.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 21 Jun 1999 23:15:41 +0300 (IDT)

On Mon, 21 Jun 1999, Dan Espen wrote:

> > > > Minor question here:Why just the Restart command?Why not expand

Ah, I see, you pointed out that this will break *your* config file.
Anyway, this was an answer mainly to Larry. Exec must not do any parsing.

> Then it leaves my mind completely.)

Shamed? No way. I executed "man sh" and read about the syntax, then I
wrote you to try too. I am tcsh and bash user and don't remember this,
because there is a man page which is a much better storage then my head.

[Further misunderstanding deleted]

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 01:08:21 +0200

>... 

> This is what the shell and make do, respectively.

This topic comes up once in a while and each time I tend towards one
or the other. But there are a few reasons why we should not allow it:

 - It's a rich source of future problems. The quoting we have now is
   hell. Why make it even more complicated.

 - There is little gain in usability. People who are trying to use
   environment variables in their config file are most likely capable
   of writing a simple shell script.

 - There is not the slightest gain in functionality. Modern shells
   are incredibly versatile tools. They can do parsing so much better
   than a window manager ever will (even the infamous POSIX ksh ;-) ).
   The philosophy of the UNIX command line is to have small tools that
   can do a limited task well and to combine them to get the desired
   result. Why should the window manager try to replace them all?

 - One reason for allowing shell scripts in the config file that came
   up in the past was being able to have the complete configuration
   in a single file. But we have already abandoned that path.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [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: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 00:54:06 +0200

> because there is a man page which is a much better storage then my head.

Hah! I can't hold back, I must brag with my knowledge of shell syntax
(without reading man page. Really!):

  ${foo} is replaced by the value of the environment variable foo. There
         are much more complicated things you can do inside ${}, depending
         on the shell (If you had seen the addres book shell script I wrote
         for zsh you'd know what I mean ;-)

  $(foo) is replaced by the stdout of the command foo (same a back quotes)

  $[foo] is replaced by the arithmetic value of the expression foo.
         E.g. $[1+2] is replaced by 3.

8-)

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 22 Jun 1999 08:25:52 -0400

>          E.g. $[1+2] is replaced by 3.

Thats cool, but can you forget it completely to make room for some new
stuff?

Actually, this is with ksh:

fork> echo $[2+2]    
$[2+2]
fork> echo $((2+2))
4

(No, I didn't have the $(( )) memorized.)

---

From: [email-masked]
Date: Tue, 22 Jun 1999 08:41:30 -0400 (EDT)

> (without reading man page. Really!):

I think we have diverted from the topic here.

I can see the point about not wanting to break existing config files,
but I really thought that it would be nice to have "variables" within
fvwm2 to provide for stuff other than home directory pointers, etc.

For instance, button bars are very popular, but some people would like
them to occupy the {top,bottom,left,right} side of the screen.  Without
hard-coding the width or height of the screen into the .fvwm2rc file,
this cannot be done without FvwmM4.

Actually, I had wanted this feature for a while in FvwmButtons and
FvwmIconMan.  I've stopped attempting this, and have gone back to using
(and now maintaining) tkgoodstuff, which can "stretch" if desired.

Dominik was correct in that adding variables may increase complexity
for little gain, so I remove my suggestion.

However....!

How about something to simply achieve the affect I had been trying to
get:  a button bar that "stretches" to take available width/height.

Something like:

# Have FvwmButtons be as wide as the screen:
*FvwmButtonsExpand	horizontal

# Have FvwmButtons be as tall as the screen:
*FvwmButtonsExpand	vertical

# Have FvwmButtons use its existing geometry calculations (default)
*FvwmButtonsExpand	none

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 22 Jun 1999 17:01:30 +0300 (IDT)

> fvwm2 to provide for stuff other than home directory pointers, etc.

I have thought a bit yersterday about a possible solution.
It is nice to have fvwm internal variables (not environmental), which can
be expanded on every command. The problem is to choose a good syntax not
to break things. Maybe this:

To assign variable:
  set var "string"
  set var $env_var

On any command %{var} will be expanded.
  set var3 "%{var1}, %{var2}"
  MenuStyle "*" Background %{MY_BACK_COLOR}
  *FvwmButtonsBack %{MY_BACK_COLOR}

%{%} can be expanded into % for the rare cases to escape %{ sequence.

The problem with this is that advanced users very soon will want a much
more compicated syntax, like:
  if (%{var1} == "left") set var1 "right"

and so on...
Fvwm configuration language is one-line oriented and not good for such
things, it is more a documentation language, not a programming language.
For example, scwm uses scheme (much like lisp), which is a very powerful,
(but difficult for most users) language. It is not less powerful than any
shell language despite of the last Dominik's comment.

What do you think, may adding 'set' command and expanding fvwm
variables be a good start? This can help peoples writing non-hardcoded or
themable configurations without preprocessing.

Regards,
Mikhael.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 22 Jun 1999 15:40:03 +0100

> themable configurations without preprocessing.

I think you really should use a preprocessor for handling variables. 
They really are much better than fvwm will ever be.  For instance I run
FvwmButtons that is 25% of the width of the screen, I specify it's size
with FvwmM4 thus:

*FvwmButtonsFrame 2
*FvwmButtonsGeometry -0-0
*FvwmButtonsPadding 0 0
*FvwmButtonsColumns 5
m4_define(BOXSIZE,m4_eval(WIDTH/20-4))m4_dnl 5 boxes per quarter screen
*FvwmButtons(4x1 Frame 0 Swallow gbuffy "Exec gbuffy")
*FvwmButtons(1x4 Size BOXSIZE BOXSIZE Swallow asclock "Exec asclock")
*FvwmButtons(4x3 Swallow FvwmPager "FvwmPager 0 3")

I can switch screen resolution and it always works.

Just putting variables into fvwm won't help me unless you also include
equation evaluation, in which case you might as well use SCWM. I would
rather fvwm not do variables at all rather than do them poorly.

Cheers,
Tim.

---

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

On Tue, 22 Jun 1999, Mikhael Goikhman wrote:

> to break things. Maybe this: [ ... ]

>   if (%{var1} == "left") set var1 "right"

I think you hit the nail on the head.  If you start adding programming
constructs to the configuration language, where do you stop?  Why not go
all the way and use scwm?  Or go half-way and use the existing
preprocessed config files?

I think Dominik made the point that even just _expanding_ variables adds a
lot of complexity for little gain.  I would have to agree.

> themable configurations without preprocessing.

I remain skeptical.  I think the onus is on the proposer to demonstrate
what value variables add, as opposed to using a pre-processor.

---

From: Dan Espen <[email-masked]>
Date: Tue, 22 Jun 1999 11:17:37 -0400

> what value variables add, as opposed to using a pre-processor.

I agree.

I believe   Larry  withdrew his  variable  suggestion.   Larry's  last
suggestion was to be able to have FvwmButtons expand.  (No variables.)

I think thats consistent with our goal of removing extraneous modules.
The    expansion is  one  reason  FvwmButtons   is not an  FvwmTaskBar
replacement.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 17:36:49 +0200

> Actually, this is with ksh:

Ah yes, ksh. A 'decent' shell doesn't need these double-parentheses :-)
(And no, I'm not sure if there are other shells than zsh which use
braces).

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: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 17:42:50 +0200

> # Have FvwmButtons use its existing geometry calculations (default)

Why don't you simply use the 'Maximize' command?

  Next (FvwmButtons) Maximize 100 0

Note that FvwmButtons doesn't resize too well with lots of buttons since the
buttons are all the same width/height. So if you have 70 rows (I have), the
width is always a multiple of 70 pixels.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 17:48:15 +0200

> themable configurations without preprocessing.

What is so horrible about preprocessing? Just allowing all these fancy
stuff in the config file doesn't make it more user friendly (see 'quoting').
Or would you like to have to remember a syntax like %{foo}? It's much more
likely that you know how to use a C preprocessor.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Tue, 22 Jun 1999 16:59:59 +0100

> width is always a multiple of 70 pixels.

This is dumb. Would anyone complain if some buttons were 1 pixel
wider/taller than others after they had resized it.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jun 1999 18:09:10 +0200

> wider/taller than others after they had resized it.

I don't think so, but I've no idea how many places would have to be changed.
Probably all size calculations depend on the assumption that all buttons
have the same size.

Bye

Dominik ^_^