Subject: FVWM: Ideas for improvements to the configuration file

From: Michael F Gordon <[email-masked]>
Date: Mon, 18 Jan 1999 15:02:47 +0000

After having played with 2.1.7 for a while, the inconsistencies
in how various commands take their options began to annoy me.
The following changes would, in my opinion, make things cleaner
and simpler.

  Get rid of HighlightColor and specify HilightColorForeground
  and HilightColorBackground in Style commands.

  WindowFont should be part of the Style command as well.

  IconFont should be extended to a full IconStyle, with the
  default IconStyle inheriting the values that make sense for
  icons from the default Style unless they've been set explicitly.

  Where you're configuring the same thing, the option should be the
  same.  For example, there's no reason to have Foreground and
  Background in MenuStyle and ForeColor and BackColor in Style.

Michael
-- 
Quidquid latine dictum sit, altum viditur.
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Jan 1999 01:30:39 +0100

>   and HilightColorBackground in Style commands.

Why should it? The hilighting colour is definitely a global
setting. Why should it be a window style?

>   icons from the default Style unless they've been set explicitly.

Again I don't understand what what the benefit would be. Looking
through the manpage I see not settings at all that would make
sense passing from a window style to an icon style. There are
only two things configurable to icons (apart from the font):
If it goes into the icon box and if it has a title.

I don't think we should start wasting space just for the sake
of parsing consistency. In my eyes neither the fonts nor the
hilight colors are global settings.

>   Background in MenuStyle and ForeColor and BackColor in Style.

Yup.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: [email-masked]
Date: Mon, 18 Jan 1999 19:10:51 -0800

my system : pentium 90 / Debian Linux kernel 2.0.34

When I run configure I get the following messages :

  checking iconpath... /usr/include/X11/bitmaps:/usr/include/X11/pixmaps
  
  checking iconpath... 
    /usr/include/X11/bitmaps:/usr/include/X11/pixmaps

  checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
  checking for dnet_ntoa in -ldnet... no
  checking for dnet_ntoa in -ldnet_stub... no

  checking for XpmReadFileToXpmImage in -lXpm... no
  Not using xpm library
  checking for rplay_create in -lrplay... no
  Not using rplay library
  checking for readline in -lreadline... no 
  Not using readline library

What I don't understand is that I have the X-libs installed - why won't
it give me xpm support??  What libs am I missing and where can I get
them from.  I really want to be able to use xpm's.

Thankx,

Aaron

---

From: [email-masked] (Paul D. Smith)
Date: 18 Jan 1999 21:53:05 -0500

%% [email-masked] writes:

  a>   checking for XpmReadFileToXpmImage in -lXpm... no
  a>   Not using xpm library

  a> What I don't understand is that I have the X-libs installed - why won't
  a> it give me xpm support??  What libs am I missing and where can I get
  a> them from.  I really want to be able to use xpm's.

Odd as it may seem, Xpm is not part of standard X.

Look in /usr/X11R6/lib and see if libXpm.* is there.  If not, find the
Xpm rpm and install it.  If so, something else is wrong (maybe you have
an old version of Xpm?).  Send us the output of the config.log test for
xpm (search for xpm in config.log and send us the contents around that
spot).

-- 
-------------------------------------------------------------------------------
 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://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jim Nicholson <[email-masked]>
Date: Mon, 18 Jan 1999 23:09:25 -0500 (EST)

Has there ever been any discussion about automating the selection of a 
MiniIcon value based on the Icon setting?

What I'm suggesting is something like a global "MiniIconPrefix"
setting that would calculate a MiniIcon file name by appending the set 
prefix to whatever the Icon value is for a given Style.

This would ease the use of KDE-style icon directories, where there is 
a "/mini" subdirectory within the pixmap directory that contains small 
versions of each image. It also would work for those, like me, who
keep their mini-icons in the same directory as their pixmaps, but with 
"mini." tagged to the begining of the filename.

Of course, this can also be done by preprocessing the .fvwm2rc (and
MiniIcon accepts values like "mini/myicon.xpm", interestingly
enough).

I'm willing to try my (somewhat shakey) hand at a patch, if there's
enough interest.

- Jim

---

From: [email-masked]
Date: Mon, 18 Jan 1999 22:25:19 -0800

I have /usr/X11R6/lib/libXpm.so.4.10  and  libXpm.so.4 (sym link to
first lib) so I don't know why it is failing.  I'm doing everything as
root so it is not a permissions issue.  

Here is the output from config.log I think you are talking about :

configure:2769: gcc -o conftest -g -O2   -L/usr/X11R6/lib conftest.c
-lICE   1>&5
configure:2832: checking for XpmReadFileToXpmImage in -lXpm
configure:2851: gcc -o conftest -g -O2   conftest.c -lXpm -lXpm 
-L/usr/X11R6/lib  -lSM -lICE -lX11   1>&5
ld: cannot open -lXpm: No such file or directory
configure: failed program was:
#line 2840 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char XpmReadFileToXpmImage();
int main() {
XpmReadFileToXpmImage()
; return 0; }

Thankx, 
  Aaron

---

From: Neil Bird <[email-masked]>
Date: Tue, 19 Jan 1999 08:59:15 +0000

> setting. Why should it be a window style?

  I'd disagree with that, personally. If one's specified wholly distinct
decors for various windows, it makes a great deal of sense [to me] to have
the window highlight itself within the bounds of its own decor. It's one
of the first things I noticed when setting up fvwm2 for the first time ...

> If it goes into the icon box and if it has a title.

  Yes, I don't see enough icon-specific settings to warrant a new command.
IIRC, one can include icon settings in decors [I may be wrong!], and one
can certainly apply them on a window/app. class basis. Maybe if the future
if more icon-control settings are added, it'd make sense.

> hilight colors are global settings.

  ?  You just said that you thought the highlight colour /is/ a global
setting.

-- 
========================- http://www.rrds.co.uk/ -======================
 Neil Bird                   |   This is who we are     The time is near
                             |        There are 347 days remaining
 mailto:[email-masked] |                           [ T-140 days! ]
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Neil Bird <[email-masked]>
Date: Tue, 19 Jan 1999 09:09:08 +0000

> root so it is not a permissions issue.

  Do you not have a libXpm.a in the same place? I'm not sure how ld works
at that level; it may need the lib.a to reference symbols on the .so (?) 
I'd never assumed that to be the case, but if you're having problems, that
may be it.

  If your system has 'truss', and you're still having problems, try a
'truss -f -topen <compile-command>' to find out what file-open [and hence
filename] command is failing - I've assumed it's "libXpm.a" [from '-lXpm']
above.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Jan 1999 11:21:04 +0100

> of the first things I noticed when setting up fvwm2 for the first time ...

So, has anyone ever complained about that? I think there are far
more important enhancements in usability to make than this. For
me it falls into the same category as specifying your own shadow
and hilighting colours (i.e. superfluous bloat).

> > through the manpage I see no settings at all that would make

I still can't see what these icon specific settings could be.

> > hilight colors are global settings.
                       ^^^^^^
                       Style

>   ?  You just said that you thought the highlight colour /is/ a global

Yup, a typo.

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://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Neil Bird <[email-masked]>
Date: Tue, 19 Jan 1999 10:38:58 +0000

> and hilighting colours (i.e. superfluous bloat).

  Actually ... :-)

  I only say /that/ since my hi/lolight colours come out a shite shade of
green, when all my window borders are blue hues - but I've become used to
it.

  On the HilightColors front, it's not actually a problem for me, since I
prefer a consistent look any way - all my windows use the same (well,
pretty well) decor. I think one has to be a little twisted to want
different window colours on different windows :-)

  On that note - I've implemented a 'changing' toggle-size button by
defining two similar decors: each the same, bar the icon for the
toggle-size button (one's a toggle-big piccy, one's a toggle-back piccy).
my toggle-size func. sets the decor of the current window accordingly.

  It works a treat, but I can't help feeling that there's an easier way to
do it. Any suggestions?

> I still can't see what these icon specific settings could be.

  Font, f/g & b/g colour, box, etc. I think it comes down to being more of
an 'IconDecor' that IconStyle ... or even, just have then icon bits in a
Decor, and be able to create super-classes of Decor (i.e., Decor MyDecor
UseDecor MyWindowDecor, UseDecor MyIconDecor' ... and chaning a sub-decor
changes the parent). Or can we already do that?

---

From: [email-masked] (Paul D. Smith)
Date: 19 Jan 1999 10:29:18 -0500

a> I have /usr/X11R6/lib/libXpm.so.4.10  and  libXpm.so.4 (sym link to
  a> first lib) so I don't know why it is failing.  I'm doing everything as
  a> root so it is not a permissions issue.  

  a> Here is the output from config.log I think you are talking about :

  a> configure:2769: gcc -o conftest -g -O2   -L/usr/X11R6/lib conftest.c
  a> -lICE   1>&5
  a> configure:2832: checking for XpmReadFileToXpmImage in -lXpm
  a> configure:2851: gcc -o conftest -g -O2   conftest.c -lXpm -lXpm 
  a> -L/usr/X11R6/lib  -lSM -lICE -lX11   1>&5
  a> ld: cannot open -lXpm: No such file or directory
  a> configure: failed program was:
  a> #line 2840 "configure"
  a> #include "confdefs.h"
  a> /* Override any gcc2 internal prototype to avoid an error.  */
  a> /* We use char because int might match the return type of a gcc2
  a>     builtin and then its argument prototype would still apply.  */
  a> char XpmReadFileToXpmImage();
  a> int main() {
  a> XpmReadFileToXpmImage()
  a> ; return 0; }

Yes, that's it.  Extremely strange.  I'm going to go with an initial
opinion that something in your system config is messed up :)

Try this; create a foo.c:

 char XpmReadFileToXpmImage();
 int main() { XpmReadFileToXpmImage(); return 0; }

Now run the compile with the -v option:

  $ gcc -v -o foo -g -O2 foo.c -lXpm -lXpm -L/usr/X11R6/lib -lSM -lICE -lX11

and tell us what it prints.  Check where it is looking for things for
any oddities.  Although this absolutely shouldn't make any difference,
try rearranging things to look a little more "normal":

  $ gcc -v -o foo -g -O2 foo.c -L/usr/X11R6/lib -lXpm -lSM -lICE -lX11

Does that work better?  I hope not, because if it does I'm not sure what
to do about it :-/.

---

From: Dan Espen <[email-masked]>
Date: Tue, 19 Jan 1999 10:45:28 -0500

>   a> root so it is not a permissions issue.  

There should be a libXpm.so somewhere in this picture.

Normally the symbolic link would look like:

MyMachine> ls -l /opt/public/lib/libXpm*
lrwxrwxrwx   /opt/public/lib/libXpm.so@ -> libXpm.so.4.10
-rw-r--r--   /opt/public/lib/libXpm.so.4.10

If there is no file, "libXpm.so", I think the rest of the bug
report falls into place.

--
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://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Richard Lister <[email-masked]>
Date: Tue, 19 Jan 1999 11:13:12 -0500

On Tue, 19 Jan 1999 01:30:39 +0100
Dominik Vogt <[email-masked]> 

Dominik	

I disagree. If I say something like this:

  Style "Emacs"		Color White/Green
  Style "XTerm"		Color White/Blue

it is very reasonable for me to want to also say:

  Style "Emacs"		HilightColor White/LightGreen
  Style "XTerm"		HilightColor White/LightBlue

I also think this is what an awful lot of people expect to work, and they
struggle for a while with the fact that they can set colors on a per
window basis, but not highlight colors.

> > >   WindowFont should be part of the Style command as well.

I don't see why the font shouldn't be settable per window, though I have
less strong feelings about this.

> If it goes into the icon box and if it has a title.

I've not thought about the icon stuff.

Cheers
Ric

Richard J Lister, Georgetown Institute for Cognitive and Computational Sciences
Georgetown University Medical Center, Washington, DC 20007, USA
Phone: +1 202-687 2878
Email: [email-masked] 
Web: http://www.giccs.georgetown.edu/~ric/
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Lee Willis <[email-masked]>
Date: 19 Jan 1999 16:37:17 +0000

>   Style "XTerm"		HilightColor White/LightBlue

I agree with this completely. If you allow different colour settings on a
per-window/class basis then you should also allow highlight colours on a
per-window/class basis. It makes sense (To me at least ...)

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://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Michael Han <[email-masked]>
Date: Tue, 19 Jan 1999 10:18:40 -0800

Previously...
>I'm willing to try my (somewhat shakey) hand at a patch, if there's

But what's wrong with appending the mini subdir into your pixmap path?
I only import my system's /usr/X11R6/include/X11/pixmaps, but I
override builtins by prepending $HOME/pixmaps in my pixmap path. The
mini-* effect is, IMHO, far more annoying and more begs for the patch
you mention, but all the same, I think the general view here is that
there are better ways to approach that "problem" than by hacking fvwm
to do something that a good preprocessor would handle...
-- 
[email-masked]
I will not call my teacher `Hot Cakes'
 - The collected wisdom of Bart Simpson
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked]
Date: Tue, 19 Jan 1999 22:29:51 -0800

Here are the experiments - I hope you can give me a reccomendation based
on them because I don't know what else to do.

Ok here is the first try and output - I don't know what I'm looking at
(I'm a newbie)

$  gcc -v -o foo -g -02 foo.c -lXpm -L/usr/X11R6/lib -lSM -lICE -lX11
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc: unrecognized option `-02'
gcc version 2.7.2.3
 /usr/lib/gcc-lib/i486-linux/2.7.2.3/cpp -lang-c -v -undef -D__GNUC__=2
-D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__
-D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix)
-Asystem(posix) -Acpu(i386) -Amachine(i386) -g foo.c /tmp/cca20638
GNU CPP version 2.7.2.3 (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/i486-linux/include
 /usr/lib/gcc-lib/i486-linux/2.7.2.3/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-linux/2.7.2.3/cc1 /tmp/cca20638 -quiet -dumpbase
foo.c -g -version -o /tmp/ccb20638
GNU C version 2.7.2.3 (i386 Linux/ELF) compiled by GNU C version
2.7.2.3.
 as -V -Qy /tmp/ccb20638 -o /tmp/ccc20638
GNU assembler version 2.9.1 (i486-linux), using BFD version 2.9.1
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o foo
/usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i486-linux/2.7.2.3/crtbegin.o -L/usr/X11R6/lib
-L/usr/lib/gcc-lib/i486-linux/2.7.2.3 /tmp/ccc20638 -lXpm -lSM -lICE
-lX11 -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/2.7.2.3/crtend.o
/usr/lib/crtn.o

and here is the second try : 

$ gcc -v -o foo -g -02 foo.c -L/usr/X11R6/lib -lXpm -lSM -lICE -lX11 
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc: unrecognized option `-02'
gcc version 2.7.2.3
 /usr/lib/gcc-lib/i486-linux/2.7.2.3/cpp -lang-c -v -undef -D__GNUC__=2
-D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__
-D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix)
-Asystem(posix) -Acpu(i386) -Amachine(i386) -g foo.c /tmp/cca20658
GNU CPP version 2.7.2.3 (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/i486-linux/include
 /usr/lib/gcc-lib/i486-linux/2.7.2.3/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-linux/2.7.2.3/cc1 /tmp/cca20658 -quiet -dumpbase
foo.c -g -version -o /tmp/ccb20658
GNU C version 2.7.2.3 (i386 Linux/ELF) compiled by GNU C version
2.7.2.3.
 as -V -Qy /tmp/ccb20658 -o /tmp/ccc20658
GNU assembler version 2.9.1 (i486-linux), using BFD version 2.9.1
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o foo
/usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i486-linux/2.7.2.3/crtbegin.o -L/usr/X11R6/lib
-L/usr/lib/gcc-lib/i486-linux/2.7.2.3 /tmp/ccc20658 -lXpm -lSM -lICE
-lX11 -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/2.7.2.3/crtend.o
/usr/lib/crtn.o