Subject: fvwm 2.0.47a

From: Brady Montz <[email-masked]>
Date: 22 Jun 1998 21:15:53 -0700

Here's the alpha release of 2.0.47:

ftp://ftp.cs.arizona.edu/people/bradym/fvwm/fvwm-2.0.47a.tar.gz

I haven't announced this to the general fvwm list yet. I will when bug reports 
come in at an acceptably low rate.

ChangeLog:

2.0.47
        1. FAQ updates
        2. Menu code & Move fixes & enhancements based on patch from
           Greg Badros [+ some bugfixes]
        3. Added SetEnv function (also from Greg's patch)
        4. Fixed some memory leaks
        5. Cleaned up some ugly code pointed out by Peter Seebach
           (like mystrcasecmp & mystrncasecmp - are these even needed
           anyways?  Is there any system that doesn't have the non-"my"
           versions?)
        6. Builtin WindowList no longer searches for xpm's in window
           titles (patch from Greg Badros)
        7. Various compiler fixes
        8. Created textures directory, put Martin Cartwright's
           "marbles" and textures from http://www.PLiG.org/xwinman/ in
           there as a start
        9. Pager balloon window patch from Ric Lister
        10. Signal handler safety patches (based on patch from Grant
            McDorman)
        11. Cleaned up and consolidated allowed function checking code
        12. Made GetTwoArguments check for 'MxN' style numbers so cmds
            like 'DeskTopSize 2x3' will work (since the man page has
            always said that is the proper syntax)
        13. Fixed some minor parsing bugs
        14. Added check to GetWindowSizeHints to compensate for bad
            aspect ratios (fixes some windows that startup HUGE)
        15. Patch to FvwmButtons to add animated panels to it (like CDE
            or Wharf) from Jui-Hsuan Joshua Feng
        16. Brady Montz <[email-masked]> is the new maintainer.
        17. The Imakefile for FvwmCpp sets FVWM_CPP to CppCmd. If Imake
            is incorrectly configured, you have to override this in Fvwm.tmpl.
        18. New version of FvwmIconMan

I'm not certain about item 15. I couldn't find anything obvious in the source
code or man page about animated buttons. Does anybody know if this patch
really got applied (chuck did everything up to item 16). 

Unless I've personally told you otherwise, I'm not going to accept any patches 
other than bugfixes. The 2.0 line is now in feature freeze for the 2.2
release. This is a good time for people to send in documentation and sample
fvwm2rc's though.

-- 
 Brady Montz
 [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, 23 Jun 1998 09:10:47 -0400

> ftp://ftp.cs.arizona.edu/people/bradym/fvwm/fvwm-2.0.47a.tar.gz

The good news  is  that it compiles  and  runs fine on Solaris  2.5.1,
Sparc 10, Sun's compiler.

There is   an empty directory  named "tmp"  in the  distibution that I
don't think you wanted to be there.

> Unless I've personally  told you otherwise,  I'm not going to accept
> any patches  other than  bugfixes.  The 2.0 line   is now in feature
> freeze for the 2.2 release. This is  a good time  for people to send
> in documentation and sample fvwm2rc's though.

This is really bad news  for me.  There is no  way I  can move off  my
patched fvwm-2.0.46  without   the  "iconboxes"  and   "colorlimiting"
patches.  I had a firm commitment from Chuck  that these patches would
be included.

What do I  have to do  to get these  patches  included in some  future
release?

--
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: Tim Phipps <[email-masked]>
Date: Tue, 23 Jun 1998 14:25:51 +0100

> patches.  I had a firm commitment from Chuck  that these patches would

I too would like to see the iconboxes patch go in.  It was only after
this patch that I actually liked the way icons wre placed.

Cheers,
Tim.

---

From: Tobias Oetiker <[email-masked]>
Date: Tue, 23 Jun 1998 16:01:39 +0200 (MET DST)

On Tue, 23 Jun 1998, Dan Espen wrote:

*> Brady Montz <[email-masked]> writes:
*> > Here's the alpha release of 2.0.47:
*> > 
*> > ftp://ftp.cs.arizona.edu/people/bradym/fvwm/fvwm-2.0.47a.tar.gz
*> 
*> The good news  is  that it compiles  and  runs fine on Solaris  2.5.1,
*> Sparc 10, Sun's compiler.

while we are at bugs ...

I have a config file which uses the FvwmIconBox module but sets the height 
of the displayed Icons to zero, so that only the lable of the ocon is
displayed.

Whenever I start an application I get the follwoing error messages on the
console ... 

Error in FvwmIconBox:  BadValue (integer parameter out of range for operation) 
Major opcode of failed request:  53 
Resource id of failed request:  0x0 
Error in FvwmIconBox:  BadDrawable (invalid Pixmap or Window parameter) 
Major opcode of failed request:  55 
Resource id of failed request:  0x3c000c4 
Error in FvwmIconBox:  BadDrawable (invalid Pixmap or Window parameter) 
Major opcode of failed request:  62 
Resource id of failed request:  0x3c000c4 
Error in FvwmIconBox:  BadGC (invalid GC parameter) 
Major opcode of failed request:  60 
Resource id of failed request:  0x3c000c5 
Error in FvwmIconBox:  BadPixmap (invalid Pixmap parameter) 
Major opcode of failed request:  54 
Resource id of failed request:  0x3c000c4 

maybe someone can fix this ... (don't know about X ... sorry )

cheers
tobi

--
 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1194  ICQ: 10419518 
/_/ \___/_.__/_/ [email-masked] http://ee-staff.ethz.ch/~oetiker

---

From: Brady Montz <[email-masked]>
Date: 23 Jun 1998 13:33:57 -0700

New version:

ftp://ftp.cs.arizona.edu/people/bradym/fvwm/fvwm-2.0.47b.tar.gz

Additions to ChangeLog:

        19. Changed prototype of bzero() in alpha_headers.h.
        20. Applied Iconbox patch which added new styles IconGrid and IconFill.
        21. Applied Colorlimit patch which adds ColorLimit command to set
            maxmimum number of colors fvwm can use for pixmaps.
        22. Applied DontFocusOffscreen patch.

I haven't really tested the Iconbox patch much, so go nuts.

---

From: Brady Montz <[email-masked]>
Date: 23 Jun 1998 13:40:50 -0700

> Whenever I start an application I get the follwoing error messages on the

I've not been able to reproduce this. I took the FvwmIconBox configuration
from the system.fvwm2rc bundled with fvwm, and changed the
*FvwmIconBoxMaxIconSize line to:

*FvwmIconBoxMaxIconSize 64x0

And everything seems to work for me. Could you send me your .fvwm2rc?

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Tue, 23 Jun 1998 23:41:08 +0200 (METDST)

Well the problem (the same with others, I think) is that fvwm2 has 
changed too much!. My problem is that the menu system is one of the most 
changed areas, and it is impossible to apply (even by hand) my patch to 
improve menu look (it still needs an improve :), I will have to rewrite 
it from scratch (taking into accound the new WIN mode and the animated 
menus, although I think I will just ignore this last feature as it would 
be very expensive when using bitmaps and gradients).
	So I won't be able to post a patch until next week (I'm having final 
exams now, and *finally* I will have to study, just a bit ...:), and I 
really don't know about the new menus philosophy, I've been rewritting 
it, so we could change MenuStyle in a per-menu basis, but the new version 
ignore it and include new features as WINmenus (do we really need it? :), 
so I'm a bit puzzled.

	Other important (*VERY* important) thing is that you should made patches
available in the beta site, in order to improve development and to low 
bandwidth, I don't know about others but I connect to internet through a 
28.8 kbps modem, and telephone isn't free in Spain :)

<>-------------------------------------+-----------------------------------<>
   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: Brady Montz <[email-masked]>
Date: 23 Jun 1998 15:34:56 -0700

> ignore it and include new features as WINmenus (do we really need it? :), 

OK. I think I would prefer your stuff to go into the 2.3 version anyway.

> 28.8 kbps modem, and telephone isn't free in Spain :)

Good point. I'm putting a patch on the ftp site right now.

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 23 Jun 1998 19:12:47 -0400 (EDT)

Well I have fvwm 2.0.47b running ok with Solaris 2.5 and X11R6.3.
The one problem I noticed is that the build did not set the LD_RUN_PATH.
It may be an issue with the Imakefile of my site.def file. I need to check
on this still. Anyone else have this problem? This is a shared library issue
where you need to tell the compiler at build time where to look for the
libraries at run time.

I have included a small patch (which defaults to False). It puts
"StipledTitles" in all window titles. This is the default behaviour for our
1000+ Unix boxes and 50,000 user base. It would save me alot of hassle if
you could incorporate it in 2.0.47, as it is small and does not effect
normal behavior.

Thanks,
Randall

--- 1.1	1998/06/23 22:20:38
+++ borders.c	1998/06/23 22:21:30
@@ -848,7 +848,7 @@
                      t->name, strlen(t->name));
   }
   /* now, draw lines in title bar if it's a sticky window */
-  if(t->flags & STICKY)
+  if(t->flags & STICKY || Scr.StipledTitles)
   {
     for(i=0 ;i< t->title_height/2-3;i+=4)
     {
--- 1.1	1998/06/23 22:22:17
+++ builtins.c	1998/06/23 22:24:11
@@ -3323,6 +3323,14 @@
     {
       Scr.MouseFocusClickRaises = True;
     }
+    else if (StrEquals(opt,"NOSTIPLEDTITLES"))
+    {
+      Scr.StipledTitles = False;
+    }
+    else if (StrEquals(opt,"STIPLEDTITLES"))
+    {
+      Scr.StipledTitles = True;
+    }
     else
       fvwm_msg(ERR,"GlobalOpts","Unknown Global Option '%s'",opt);
 
--- 1.1	1998/06/23 22:24:30
+++ fvwm.c	1998/06/23 22:25:20
@@ -1242,6 +1242,7 @@
   Scr.ClickToFocusPassesClick = True;
   Scr.ClickToFocusRaises = True;
   Scr.MouseFocusClickRaises = False;
+  Scr.StipledTitles = False;
 
   /* Not the right place for this, should only be called once somewhere .. */
   InitPictureCMap(dpy,Scr.Root);
--- 1.1	1998/06/23 22:25:30
+++ screen.h	1998/06/23 22:25:46
@@ -332,6 +332,7 @@
   int ClickToFocusPassesClick;
   int ClickToFocusRaises;
   int MouseFocusClickRaises;
+  int StipledTitles;
 
 } ScreenInfo;
 
--- 1.1	1998/06/23 22:26:18
+++ fvwm2.man	1998/06/23 22:26:38
@@ -1112,6 +1112,7 @@
 ClickToFocusDoesntPassClick/ClickToFocusPassesClick,
 ClickToFocusDoesntRaise/ClickToFocusRaises,
 MouseFocusClickDoesntRaise/MouseFocusClickRaises
+NoStipledTitles/StipledTitles
 .EX
 GlobalOpts ClickToFocusDoesntPassClick, ClickToFocusDoesntRaise
 .EE

---

From: Brady Montz <[email-masked]>
Date: 23 Jun 1998 21:49:38 -0700

> where you need to tell the compiler at build time where to look for the

This is most likely a solaris problem. This seems similar to a problem I had a
month or so ago when I was trying to compile fvwm on solaris for a class I was
teaching on window managers. I couldn't get fvwm to compile so that I didn't
need to have LD_RUN_PATH set in order for it to find the X libraries. I tried
every combination of linker and gcc flags that I could think of to set the
load path to include /usr/X11R6/lib, but nothing would work (although ldd
always could find the right libraries). I stopped using Suns when Solaris came
out, so I'm pretty clueless on that dialect of unix. I'd like to know if
anyone else has had a similar problem.

> you could incorporate it in 2.0.47, as it is small and does not effect

I'm uncertain of whether such a feature is really a good thing, but so many
people have wanted it for so long I'm putting it in. I think that in 2.3 I
want to make it so that you can better specify what the titlebar should look
like depending on the state of the window, in as flexible a way as possible. I 
was originally thinking about it in the context of FvwmIconMan, but it'll work 
just as well for titlebars. Every thing I can think of tends to look like
printf line noise/format strings, so I've never taken the plunge. Something to 
think about.

---

From: Bob Woodside <[email-masked]>
Date: Wed, 24 Jun 1998 01:12:32 -0400 (EDT)

>         22. Applied DontFocusOffscreen patch.

        Great! Another bug-fix patch I noticed missing is the 
MouseFocusOnStartup patch (it's in unofficial_patches) - Greg Badros'
SCWM code originally, I just translated the variable names to fit FVWM2.

        I'd certainly like to see the StackingOrder patch (also in
unofficial_patches) make it into the 2.2 base, but I can readily 
understand if you decline, since it's a late entry and rather more than 
a few lines of neatly localized code. (Of course, with the amount of 
Restarting I've been doing trying out the new code, the annoyance of 
having the window I was working in dropped to bottom of the stack *does* 
make me want to press for this one a bit....)

        Now for the bad stuff.... Despite the niceties it introduces, I
have to consider the new menu code seriously broken in its behavior when
you first pop up a top level menu (by clicking on the root window). It's
not really acceptable to have to move the mouse cursor out of the menu 
before releasing the button to make the menu stick. Also, the cursor
doesn't seem to warp reliably to the title entry, so I've several times
started programs by accident by quickly clicking on the root window only
to find that the menu code interpreted my action as clicking on a menu
item. 

        I thought this might not be too difficult to fix, but it requires 
deeper digging than I've had time to do this evening.

---

From: Tobias Oetiker <[email-masked]>
Date: Wed, 24 Jun 1998 07:44:53 +0200 (MET DST)

On 23 Jun 1998, Brady Montz wrote:

*> "Randall S. Winchester" <[email-masked]> writes:
*> 
*> > Well I have fvwm 2.0.47b running ok with Solaris 2.5 and X11R6.3.
*> > The one problem I noticed is that the build did not set the LD_RUN_PATH.
*> > It may be an issue with the Imakefile of my site.def file. I need to check
*> > on this still. Anyone else have this problem? This is a shared library issue
*> > where you need to tell the compiler at build time where to look for the
*> > libraries at run time.
*> 
*> This is most likely a solaris problem. This seems similar to a problem I had a
*> month or so ago when I was trying to compile fvwm on solaris for a class I was
*> teaching on window managers. I couldn't get fvwm to compile so that I didn't
*> need to have LD_RUN_PATH set in order for it to find the X libraries. I tried
*> every combination of linker and gcc flags that I could think of to set the
*> load path to include /usr/X11R6/lib, but nothing would work (although ldd
*> always could find the right libraries). I stopped using Suns when Solaris came
*> out, so I'm pretty clueless on that dialect of unix. I'd like to know if
*> anyone else has had a similar problem.

fvwm under solaris should compile with the /usr/openwin/ X11 installation.
Unfortunately the Imake support under solaris was broken until 2.6

the problem is described on
http://night.primate.wisc.edu/software/imake-stuff/imake-vs-openwin.html
there you can also find patches to fix the problem ... 

about shared libraries ... 

the LD_RUN_PATH variable must be set or every -L on the compiler commandline
should be accompanied by a -R pointing to the same place as the -L ...
otherwhise the solaris shared library loader will not find the X libraries
or any other library no located in /usr/lib ...

cheers
tobi

---

From: Greg Badros <[email-masked]>
Date: Wed, 24 Jun 1998 11:52:03 -0700

> to find that the menu code interpreted my action as clicking on a menu

Hmmm... that's not the way it works for me.. a single click leaves the
menu window up.  The cursor shouldn't ever warp (I dislike warping
cursors, and there are good UI reasons to feel that way); instead the
menu position should be such that the top item (not necessarily the
title nor the first clickable item) falls neatly under the pointer.

> deeper digging than I've had time to do this evening.

Perhaps you could tell me your relevant settings... (I'm not sure what
they are offhand, unfortunately). I spend most of my wm-development time
on SCWM, but I don't mind trying to help out with fvwm2 as needed.

Greg

---

From: Austin Donnelly <[email-masked]>
Date: Wed, 24 Jun 1998 23:19:20 +0100 (BST)

2.0.47b works fine for me.

The only quibble I have is the change to the menu pop-down logic: if
you click down on the root window to pull up a menu, then move off the
menu, and let go, the menu stays up.  It used to dissappear.  I have
the menus appear using "Popup", rather than "Menu".

I don't see the problem someone else mentioned where the pointer is
warped to the wrong place, causing them to select an option rather
than cancelling.  The pointer warps to the menu title reliably, even
when menus are forced to the edges of the screen.

I'm using Linux (2.1.103) with a libc6-based Debian system.

There are some doc updates needed - I'll get a patch to you at some
stage; it's mainly manpage cleanups.

Austin

---

From: Bob Woodside <[email-masked]>
Date: Wed, 24 Jun 1998 23:38:11 -0400 (EDT)

On 24-Jun-98 Greg Badros wrote:
>>    [blah-blah, single click doesn't stick menu, blah, app starts
>>    up as though menu item had been clicked...]
> 
> they are offhand, unfortunately). 

        Unfortunately, I'm not sure what they'd be, either. I didn't
add any of the new fvwm2rc settings like SetAnimation or SetMenuDelay,
so I'd think that MenuStyle would be the only applicable thing. I start
up with something like

        MenuStyle white MidnightBlue bisque [font-spec] fvwm

then I've added a little popup menu of six items to set fvwm, mwm, and 
win, with and without anim, so I can test without restarting.

        The starting of an app when the first button release is over
an item in the root menu (and the mouse has not moved) happens with
mwm and win menus but not fvwm menus. (This condition occurs when the
menu is too tall to fit on the screen if the top item is placed under
the mouse cursor.)

        In all cases, however, the menu refuses to stay up unless I
hold the mouse button down till I've moved the cursor outside the menu.
(This looks to be the intent of the code in MenuInteraction around line
534, to judge from the comment.)

        If you can think of any setting I've overlooked, please let me
know.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 25 Jun 1998 01:13:56 -0400 (EDT)

OK, I tinkered with menus.c a little, and the following patch
seems to restore the sticky menu handling that we've been used to in
fvwm2.

        Since I've not had the time to dig too deeply into the menu
code, though, my concerns are: what was the actual intent of the new
code, does this patch produce any nasty side effects (haven't seen 'em
yet), and are there possibly pieces missing from the version we have
in 2.0.47b? (Hmm.... I just noticed that WinList exhibits the same
no-stick-on-click behavior - this patch doesn't affect it.)

        Also, Greg, I'm completely at a loss to understand why it
seemed to work differently for you. In any case, does this look like
a reasonable change?

diff -u -r fvwm-2.0.47b/fvwm/menus.c fvwm-2.0.47b-patched/fvwm/menus.c
--- fvwm-2.0.47b/fvwm/menus.c   Tue Jun 23 15:58:30 1998
+++ fvwm-2.0.47b-patched/fvwm/menus.c   Thu Jun 25 00:16:15 1998
@@ -533,7 +533,7 @@
          mi = FindEntry(&x_offset);
          /* hold the menu up when the button is released 
             for the first time if released OFF of the menu */
-         if(fSticks && !mi) {
+         if(fSticks) {
            fSticks = FALSE;
             continue;
            /* break; */

---

From: Greg Badros <[email-masked]>
Date: Thu, 25 Jun 1998 00:04:28 -0700

I'll look into this, but probably not until Friday.  The main
motivations for the menu changes were:

1) Provide reasonable keyboard-based behaviour;  the old menus were
abysmally bad at managing menus with keystrokes (right-arrow moved the
pointer over some fixed number of pixels, instead of doing something
conceptually appropriate, etc.)

2) Deal better with the "out-of-space-at-right-side-of-screen" problem; 
animating top level windows out of the way turned out to be a pretty
nifty effect (on a reasonably fast server) and seems like the right thing

3) Generalize the code to handle deep menus; the old code only handled
depths of up to 3, because static variables were used to hold, e.g., the 
prior menu and the one before that.

The code is not trivial, but neither was the old code.  The new menuing
code isn't a few features chucked into crap, it's rewritten from first
principles, twice!  (My machine crashed after the first rewrite, before
my weekly backup, so I had to redo everything---better!)

I'll look into your patch and see if I can figure out what's the reason
for the different behaviour -- I've not looked at the code in a while,
and my rewrite for SCWM is pretty different, unfortunately (we were
shooting for more flexibility, there, though it still doesn't have
animated menus).

Greg

---

From: Albrecht Kadlec <[email-masked]>
Date: Thu, 25 Jun 1998 12:31:33 +0200

following are:
	unpacking comments

	Build comments

	Bugs
		sorry, only bugreports, no patches
		(I limit myself to testing - don't have the time now)

unpacking comments:
    tar -zxvf fvwm-2.0.47b.tar.gz

    tar: Could not write to file fvwm-2.0.47b/modules/FvwmPager/FvwmPager.h: Invalid argument

    tar: Could not write to file fvwm-2.0.47b/extras/FvwmWharf/README: Invalid argument

    don't know what happened, could be NFS.

    tar -zxvf fvwm-2.0.47b.tar.gz fvwm-2.0.47b/modules/FvwmPager/FvwmPager.h
    fvwm-2.0.47b/modules/FvwmPager/FvwmPager.h

    tar -zxvf fvwm-2.0.47b.tar.gz fvwm-2.0.47b/extras/FvwmWharf/README
    fvwm-2.0.47b/extras/FvwmWharf/README

    so this worked. Probably a NFS timeout.

Build comments:

-)  Fvwm.tmpl
    #define HasXpm  YES     /* NO */
                  ^^

    two whitespaces !!!
    this has produced severe problems in the past (some old compilers don't cut
    spaces)

    It's no problem for me any more.

-)  I still had to 

    xmkmf; make all; make install; make install.man
           ^^^^^^^^
    otherwise the lib isn't built, thus all other targets fail.

    I think the 'install' target should build the library.

-)  unluckily there's not much use in using make -j -l2.5 (parallel make)
    because of the batch-character of the main makefile (imake).

    I tried an aggressive make (all on one line):
	
	make clean ; xmkmf ; nice make -j -l2 Makefiles ; 
        nice make -j -l2 all install install.man 

    resulting in several .c files being compiled twice.
    (more precise: in parallel:
	the toplevel Makefile has independent rules for 'all' and 'install'
	so 2 different makes are executed in each directory in parallel.)

	> nice make -j -l2 -n all install install | egrep '\.\.\.$'
	making all in ./libs...
	installing in ./libs...
	installing in ./fvwm...		(but dependent of 'all' -> make 'all' first)
	making all in ./fvwm...		(this competes with the above process)
	installing in ./modules/FvwmAudio...
	making all in ./modules/FvwmAudio...
	... and so on.

	the individual makefiles (except the 'libs' one) _have_ 'install'
	depending on 'all', so there's 2 makes taking care of 'all'.

    so one safe way is:	
	make clean ; xmkmf ; nice make -j -l2 Makefiles ; 
	nice make -j -l2 -C libs ; nice make -j -l2 install ;
	nice make -j -l2 install.man 

	(note that the library has to be taken care of separately, 
	because 'install' doesn't build the lib.)

   or :
	make clean ; xmkmf ; nice make -j -l2 Makefiles ; 
	nice make -j -l2 all ; nice make -j -l2 install install.man

   anyway: you almost can't use parallel make to make fvwm2.

   usually the load is at 0.22 for normal make over NFS (the net is
   sometimes the limiting factor).

   ----- want to say: the make process still needs work & optimizations.

Bugs 

-) DestroyMenu doesn't work reliably. My .fvwm2rc contains:

	DestroyMenu New-Windowmanager
	AddToMenu New-Windowmanager "&Restart Fvwm2" Restart /usr/X11R6/bin/fvwm2
	# /net/einstein/home/einstein/albrecht/bin/fvwm2
	+	"&local Fvwm2"	Restart /homes/albrecht/bin/fvwm2
	+	"Start &Fvwm"	Restart	fvwm
	+	"Start &twm" 	Restart	twm
	+	"Start tvtwm" 	Restart	tvtwm
	+	"Start &mwm" 	Restart	mwm
	+	"Start &olwm" 	Restart	/usr/openwin/bin/olwm

   after rereading .fvwm2rc (from another menu), most menus had
   duplicated entries. After insertion of empty lines after DestroyMenu,
   and rereading .fvmw2rc several times, I get from 1 to 3 copies of the
   menu entries.

   I found this bug, because fvwm barfs at duplicate hotkey usage. :-)

   also my mouse bindings seem to be somewhat duplicated

-) maybe that's related: I after all that rereading my .fvwm2rc, I opened 
   the windowlist:
   after selecting an entry, another windowlist popped up.
   after that, another one. 
   after some 8-9 clicks, I was able to get rid of that 'sticky' window
   list. When I tried again, it didn't go away after some 30 clicks.
   Then I killed fvwm2.

-) the windowlist doesn't have any indication of stat any more.
   there used to be prentheses around the geometry for iconified windows.

-) resizing FvwmButtons doesn't resize the bottons inside any more.
   in 2.0.45 (don't know of .46) my swallowed xterm, buttons & pager
   were resized, if I resized Fvwmbuttons.
   2.0.47b doesn't do that. Instead there's a bigger / smaller 
   lower & right margin (background color)

-) the old bug of a second pager appearing after a time is still there.

-) keybindings that worked under .45 don't work any more:

    # these are working fine.
	Key KP_Home	A	CM	Scroll -100 -100
	Key KP_Prior	A	CM	Scroll +100 -100
	Key KP_End	A	CM	Scroll -100 +100
	Key KP_Next	A	CM	Scroll +100 +100

	Key KP_Left	A	CM	Scroll -100    0
	Key KP_Right	A	CM	Scroll +100    0
	Key KP_Up	A	CM	Scroll    0 -100
	Key KP_Down	A	CM	Scroll    0 +100

	#Key KP_Begin	A	CM	TogglePaging
	Key KP_Substract A	CM	KillModule FvwmAuto
	Key KP_Add	A	CM	Module FvwmAuto 300

    # these 4 don't work any more.
	Key Home	A	CM	Scroll -100 -100
	Key Prior	A	CM	Scroll +100 -100
	Key End		A	CM	Scroll -100 +100
	Key Next	A	CM	Scroll +100 +100

    # these 4 do work ok.
	Key Left	A	SCM	Scroll -10  0
	Key Right	A	SCM	Scroll +10  0
	Key Up		A	SCM	Scroll  0   -10
	Key Down	A	SCM	Scroll  0   +10

-) FvwmAuto isn't the newest version.
   FvwmAudio was superseded by FvwmEvent - more general.
   (chuck said he'd be trying to include it in .47)

   the newest Versions of FvwmAuto & FvwmAudio as well as my .fvwm2rc are
   at <http://www.auto.tuwien.ac.at/~albrecht>
   Never mind that it states 2.0.45 there: the other versions are even
   older.

   I already merged FvwmAuto.
   (chuck put in some obscure-and-not-very-well-documented #ifdef's in his
   copy, while I did further enhancements in my development tree.)

   I will have a look on FvwmEvent / FvwmAudio in the next days.

regards,
-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them? To die: to sleep;
No more; and by a sleep to say we end
The heart-ache and the thousand natural shocks
That flesh is heir to, 'tis a consummation
Devoutly to be wish'd. To die, to sleep.	-- Shakespeare: Hamlet
--
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: Bob Woodside <[email-masked]>
Date: Fri, 26 Jun 1998 02:40:01 -0400 (EDT)

On 25-Jun-98 Greg Badros wrote:
> for the different behaviour -- 

        Ok, here's a revision of yesterday's patch that makes the WinList
menu stick as well. Other than this quirk, I'm really pleased with the
new menu code. Thanks!

diff -r -u fvwm-2.0.47b/fvwm/menus.c fvwm-2.0.47b-patched/fvwm/menus.c
--- fvwm-2.0.47b/fvwm/menus.c   Tue Jun 23 15:58:30 1998
+++ fvwm-2.0.47b-patched/fvwm/menus.c   Thu Jun 25 00:16:15 1998
@@ -533,7 +533,7 @@
          mi = FindEntry(&x_offset);
          /* hold the menu up when the button is released 
             for the first time if released OFF of the menu */
-         if(fSticks && !mi) {
+         if(fSticks) {
            fSticks = FALSE;
             continue;
            /* break; */
diff -r -u fvwm-2.0.47b/fvwm/windows.c fvwm-2.0.47b-patched/fvwm/windows.c
--- fvwm-2.0.47b/fvwm/windows.c Fri Jun 26 00:19:47 1998
+++ fvwm-2.0.47b-patched/fvwm/windows.c Fri Jun 26 00:20:15 1998
@@ -301,7 +301,7 @@
   MakeMenu(mr);

-  do_menu(mr, NULL,&miExecuteAction,0, FALSE, (eventp->type == KeyPress));
+  do_menu(mr, NULL,&miExecuteAction,0, TRUE, (eventp->type == KeyPress));
 
   DestroyMenu(mr);
 }

---

From: "Brandon M. Browning" <[email-masked]>
Date: Wed, 24 Jun 1998 06:47:07 -0700

On Tue, 23 Jun 1998, "Randall S. Winchester" wrote:

> The one problem I noticed is that the build did not set the
> LD_RUN_PATH.  It may be an issue with the Imakefile of my site.def
> file. I need to check on this still. Anyone else have this problem?
> This is a shared library issue where you need to tell the compiler
> at build time where to look for the libraries at run time.

I have this problem all the time with Solaris.  Which is why I try to
avoid it when possible (I'm not keen on it's ld.so implementation --
but, on a positive side, it's better than BSDi's version).

If you're using GCC2 (which I am), you can always pass -Rpath when
linking.  It tells GCC to build in the path to look for shared libs.
I think I set my site.def (or whatever) to do this since I have two
copies of X11 installed (don't ask, long story).

If this is still unclear, let me know and I'll try to figure out what
I really did...

-- 
Brandon M. Browning, Benevolent Ruler     Mail brandon+pgp for PGP key
 -*- Making the Internet safer for humans, one spammer at a time. -*-

Magic is always the best solution -- especially reliable magic.

---

From: Greg Badros <[email-masked]>
Date: 26 Jun 1998 10:00:26 -0700

> menu stick as well. Other than this quirk, I'm really pleased with the

Your patch looks great-- the first change you made is the way my fvwm2
is built (must've been a change that I made after the patch got posted); 
the second change is an improvement on my code (my window list *does*
act quirkily as you suggest).

Brady, it'd be a great improvement if you could make Bob's small
changes.

Thanks,
Greg

---

From: Dan Espen <[email-masked]>
Date: Sat, 27 Jun 1998 19:58:26 -0400

> 2.0.47b works fine for me.
Me too.
...
> stage; it's mainly manpage cleanups.

Speaking of man pages, I  don't see the "win" style  or the "anim" arg
in  the  fvwm2 man  page under "MenuStyle".    If Greg or someone else
doesn't have this  on hand, I will  volunteer to create  the patch for
this.

---

From: Greg Badros <[email-masked]>
Date: 27 Jun 1998 17:05:57 -0700

> doesn't have this  on hand, I will  volunteer to create  the patch for

Nope, looks like I forgot to update the man page there.  Mine does have
docs for my new SetAnimation and AnimatedMove primitives -- did these
make it into the docs for 2.0.47b?

Thanks,
Greg

---

From: Bob Woodside <[email-masked]>
Date: Sat, 27 Jun 1998 22:56:38 -0400 (EDT)

On 28-Jun-98 Greg Badros wrote:
> ...docs for my new SetAnimation and AnimatedMove primitives -- did 
> these make it into the docs for 2.0.47b?

        Yup, they're there (and the update to the Move primitive).

---

From: Dan Espen <[email-masked]>
Date: Sun, 28 Jun 1998 21:48:18 -0400

>         Yup, they're there (and the update to the Move primitive).

Ok then, heres the menustyle doc patch:

*** fvwm2.man.orig	Sun Jun 28 20:47:29 1998
--- fvwm2.man	Sun Jun 28 21:17:33 1998
***************
*** 1236,1249 ****

! .IP "MenuStyle \fIforecolor backcolor shadecolor font style\fP"
  Sets the menu style.  When using monochrome the colors are ignored.
  The shade-color is the one used to draw a menu-selection which is
  prohibited (or not recommended) by the mwm-hints which an application
! has specified.  The style option is either "fvwm" or "mwm", which
! changes the appearance of the menu.

  .IP "Module \fIModuleName\fP"
  Specifies a module which should be spawned during initialization.  At
  the current time the available modules (included with fvwm) are
--- 1236,1260 ----

! .IP "MenuStyle \fIforecolor backcolor shadecolor font style anim\fP"
  Sets the menu style.  When using monochrome the colors are ignored.
  The shade-color is the one used to draw a menu-selection which is
  prohibited (or not recommended) by the mwm-hints which an application
! has specified.  The style option is either "fvwm" "mwm" or "win",
! which changes the appearance and operation of the menus.
  
+ "mwm" and "win" style menus popup sub-menus automatically.
+ "win" menus indicate the current menu item by changing the
+ background to black.
+ "fvwm" sub-menus overlap the parent menu, "mwm" and "win" style menus
+ never overlap the parent menu.
  
+ The "anim" option is either "anim" or blank.  When this option
+ is "anim", sub-menus that don't fit on the screen cause the parent menu
+ to be shifted to the left so the sub-menu can be seen.
+ 
+ See also the "SetAnimation" and "SetMenuDelay" commands.
+ 
  .IP "Module \fIModuleName\fP"
  Specifies a module which should be spawned during initialization.  At
  the current time the available modules (included with fvwm) are

---

From: Pekka Marjola <[email-masked]>
Date: 30 Jun 1998 14:55:16 +0300

>>>>> In <[email-masked]>,
>>>>> On 23 Jun 1998 13:33:57 -0700,
>>>>> "Brady" == Brady Montz <[email-masked]> writes:

Brady> New version:
Brady> ftp://ftp.cs.arizona.edu/people/bradym/fvwm/fvwm-2.0.47b.tar.gz

Compiled and tested in HP-UX 9.05 (with none of the patches mailed
here):

usleep is not available in HP-UX 9, so I got lazy and used nap(3X)
instead which uses milliseconds and requires #include <codelibs/nap.h>
and -lcodelibs.

Nor is usleep available in HP-UX 10.01, and nap is no more available
(there is, for example, nanosleep). usleep can be used in HP-UX 10.20.

Unfortunately no patches included. I kludged a solution for myself and
I'm too lazy/busy to sort out problem completely...

-- 
Pekka Marjola * [email-masked] * http://www.iki.fi/pema/ * PGPid 0x2865206D

---

From: [email-masked] (Paul D. Smith)
Date: 30 Jun 1998 09:56:56 -0400

Here's a replacement for usleep() I've used in the past for those
systems which don't have it:

  #include <stdlib.h>

  #include <sys/types.h>
  #include <sys/time.h>
  #ifdef _HAVE_SYS_SELECT
  #include <sys/select.h>
  #endif

  int
  usleep( unsigned long usec )
  {
      struct timeval timeout;

      timeout.tv_usec = usec % (unsigned long) 1000000;
      timeout.tv_sec = usec / (unsigned long) 1000000;
      select(0, NULL, NULL, NULL, &timeout);

      return (0);
  }

FWIW.

-- 
-------------------------------------------------------------------------------
 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--Bay 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: Brady Montz <[email-masked]>
Date: 30 Jun 1998 10:14:03 -0700

>       select(0, NULL, NULL, NULL, &timeout);

God I hate HP-UX. 

I no longer have access to an HP to try things out. Can anyone suggest which
#ifdef I should protect this with?

---

From: Brady Montz <[email-masked]>
Date: 30 Jun 1998 10:17:24 -0700

> Ok then, heres the menustyle doc patch:

Applied.

---

From: Brady Montz <[email-masked]>
Date: 30 Jun 1998 10:33:49 -0700

>     don't know what happened, could be NFS.

I think so.

>     #define HasXpm  YES     /* NO */

Fixed.

>     I think the 'install' target should build the library.

I added a rule to the libs/Imakefile which should fix this.

>     because of the batch-character of the main makefile (imake).

I think we should forget about parallel make since we are going to be moving
to autoconf in the near future. 

> Bugs 

Oh my. I'll have to wade through these. I'll release the next alpha version
though first.

---

From: [email-masked] (Paul D. Smith)
Date: 30 Jun 1998 14:25:27 -0400

%% Brady Montz <[email-masked]> writes:

  bm> I no longer have access to an HP to try things out. Can anyone
  bm> suggest which #ifdef I should protect this with?

Well, once you move to autoconf this won't be a problem ;)

Actually, usleep exists on HP-UX 10.10, at least.  It's not there on
HP-UX 9.01 (these are the only two HP-UX versions I have access to).

I don't have any good ideas in an Imake environment, except to put a
note in the README for HP-UX 9.xx telling people to change an Imakefile
to set a constant like _DONT_HAVE_USLEEP.  Or something.

---

From: Dan Espen <[email-masked]>
Date: Tue, 30 Jun 1998 14:45:40 -0400

> #ifdef I should protect this with?

The "select" seems to be portable, you may want to just  use it in all
cases.