Subject: pre2.0.46 ready for worker evaluation

From: "Charles Hines" <[email-masked]>
Date: Wed, 13 Aug 1997 15:22:48 -0400

Howdy all.

Ok, I finially have pre2.0.46 ready for any workers who are willing
and/or able to give it a quick test.  As always it doesn't have
everything I wanted to get in there, but it has been way too long
since a beta was released and this should be good enough for now, so
if it seems ok for you folks that can try it out for me, I'll release
it to everyone else as 2.0.46 and then continue working on 2.0.47...

Like ususal, it's in the pre-beta .test dir:

            ftp://ftp.hpc.uh.edu/pub/fvwm/version-2/.test/

Looks like so:

   -rw-rw-r-- 1 chines fvwm 806625 Aug 13 14:10 fvwm-pre2.0.46.tar.gz

Here's the ChangeLog summary:

======================================================================
pre-2.0.46
       1. Patch to remove forgotten CLICKTORAISE #if check, from
          Markus Gutschke
       2. More mini xpm files
       3. Fix to XTerm font change problem
       4. Fix to clever placement (icon location) problem from Anthony
          Martin
       5. Updated extras/FvwmScript from Frederic Cordier
       6. Changing default XORValue to 0, which now means "try and
          guess what a good XORValue is for my display" (using recommended
          method in the XLib Programming Manual)
       7. Updated FvwmM4 & Cpp man pages to show correct invocation...
       8. Updated extras/fvwmperl from Dan Astoorian
       9. FAQ updates
       10. Imakefile fixes
       11. Added info to FvwmIdent (transient)
       12. Brought back 1.xx like CursorStyle command (based on old
           patch from Kit Smithers)
       13. Patch from Patrice Fortier to allow xpm backgrounds in
           FvwmButtons (noticed some problems with this)
       14. Updated FvwmCommand from Toshi Isogai
       15. Builtin WinList fixes (geometry string makes more sense now,
           plus alphabetic sort option from Eric Schott)
       16. Fix from Andrew for NoButton 0 problem
       17. GetDecor SCO CPP patch from Andrew
       18. Patch from Andrew for MWM buttons functions problems
       19. Fix from Dave Goldberg for NoTitle & MiniIcon conflict
       20. Move/Resize frame drawing bug patch from Makoto Matsushita
       21. Patch to FlipFocus (under MouseFocus) from Markus Gutschke
       22. Added patch from Rob Whapham/Thimo Jansen for FvwmPager
           miniicons (plus small enhancements)
       23. FvwmBacker patch from Tim Phipps to have it run fvwm
           commands instead of unix commands, so borders & the like
           can be changed too (just use Exec to get old functionality)
       24. Latest FvwmIconMan (v1.0) from Brady Montz
       25. Fix for static buffer overflow in SendDataToModule in read.c
           (when IconPath/PixmapPath greater than 255 chars)
       26. Patch from Tim Phipps to add Current op (like Prev & Next,
           but operates only on Current window) and enhanced conditionals
           for Prev/Next/Current/None (like the addition of !<name>)
       27. Added FvwmWharf to extras dir (ported from AfterStep by who??)
       28. Added FvwmTaskBar to extras dir (ported from fvwm95 by Don Mahurin)
       29. Added FvwmWinList miniicons patch from Don Mahurin.  Still
           need to update docs for it...
       30. Patches from Randy Ray to make windowshade module packets
           more "standard" & add filename to MINI_ICON packet
       31. Patch from Barry Warsaw to make multi head code work
           slightly better (although it probably needs a total rewrite
           to really work well - ctwm good model?)
       32. Patch to echo builtin needs to remove final \n if there is
           one (Greg Badros sees this, but I don't so it might be a system
           dependent bug)
       33. Patch from Dan Espen for keeping long icon names on screen
       34. Made builtin function searching faster (hopefully) using
           simple binary search (mostly to help speed up startup
           time).  Please let me know how this works since my
           relatively simple setup isn't a good test case for this...
       35. Removed 'raise_it' entirely, since no longer used
       36. Made window move paging match Edgescroll values instead of
           always doing full screens (should this be an option?)
       37. Focus command no longer raises - use an interpreted
           focus-and-raise function if that's desired
       38. Minor menu code bug fixed - wasn't always ungrabbing the
           cursor before executing function (timing dependent - most
           of the time ok)
======================================================================

There are going to be a few more betas before 2.1.0, I think.  I'd
really like to get more stuff cleaned up and think that it'll be
better to do a little more before 2.1.0.

Please let me (via the workers list) know how this goes for you all.

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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: Jason L Tibbitts III <[email-masked]>
Date: 13 Aug 1997 15:01:06 -0500

Builds OK on Solaris 2.4 with gcc.  I'll test on Linux this evening.

make install did complain:

make[1]: Entering directory `/home/tibbs/work/fvwm-pre2.0.46/sample.fvwmrc'
make[1]: *** No rule to make target `system..fvwm2rc', needed by `/usr/openwin/lib/fvwm2/system..fvwm2rc'.  Stop.
make[1]: Leaving directory `/home/tibbs/work/fvwm-pre2.0.46/sample.fvwmrc'
make: *** [install] Error 2

Weird.

For the release, we really need to provide patches.  I tried generating
them with CVS but it didn't work. (2.0.44 + patch-2.0.45 != 2.0.45.)

 - J<

---

From: Charles Hines <[email-masked]>
Date: Wed, 13 Aug 1997 16:44:33 -0400

>>>>> "Jason" == Jason L Tibbitts <[email-masked]> writes:

Jason> Builds OK on Solaris 2.4 with gcc.  I'll test on Linux this evening.
Jason> make install did complain:
....
Jason> Weird.

Whoops!  Fixed like so:

======================================================================
--- sample.fvwmrc/Imakefile.orig        Wed Aug 13 16:41:21 1997
+++ sample.fvwmrc/Imakefile     Wed Aug 13 16:31:31 1997
@@ -8,5 +8,5 @@
 NullMake()

 #if InstallSample
-InstallNonExecFile(system.$(FVWMRC),$(FVWMDIR))
+InstallNonExecFile(system$(FVWMRC),$(FVWMDIR))
 #endif
======================================================================

Jason> For the release, we really need to provide patches.  I tried generating
Jason> them with CVS but it didn't work. (2.0.44 + patch-2.0.45 != 2.0.45.)

I generally have the whole dir tree from the previous & current
releases sitting in my dirs at the time I ftp the tar file up, so I'll
try and remember to generate a patch off those for 2.0.46.

Chuck

---

From: Jason L Tibbitts III <[email-masked]>
Date: 14 Aug 1997 08:11:35 -0500

In case anyone tried to fetch the package and couldn't, our campus backbone
router blew up yesterday leaving me without network connectivity.  I see
rapid fetching of the file up until the point where things went away.

It should be OK now; at least I have _some_ connectivity.  Sorry for the
inconvenience.
-- 
  Jason L. Tibbitts III - [email-masked] - 713/743-3486 - 622PGH
System Manager:  University of Houston Department of Mathematics 
              1994 PC800 "Kuroneko"     DoD# 1723
--
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: Larry Gensch <[email-masked]>
Date: Thu, 14 Aug 1997 14:57:25 -0400 (EDT)

On 13 Aug, Charles Hines wrote:

> and/or able to give it a quick test.

Only one critical problem for Digital Unix (Alpha -- 64 bit
architecture):

cc:  Warning:  virtual.c, line 543:  In this statement, the referenced
     type of the pointer value "&val1" is "long", which is not compatible
     with "int".
  n = GetTwoArguments(action, &val1, &val2, &val1_unit, &val2_unit);
------^

cc:  Warning:  virtual.c, line 543:  In this statement, the referenced
     type of the pointer value "&val2" is "long", which is not compatible
     with "int".
  n = GetTwoArguments(action, &val1, &val2, &val1_unit, &val2_unit);
------^

There are other compilation warnings, which I'll pass along if you are
interested.  However, these two could cause run-time problems (stray
pointers) and should be fixed.

Also, from your checklist...

>            relatively simple setup isn't a good test case for this...

I think an even BIGGER win here would be to use gperf to generate a hash
table for quicker lookup for builtins.

-- 
(void) lar3ry();                                      [email-masked]

     "Sometimes it happens.  People just explode.  Natural causes."

---

From: "Charles Hines" <[email-masked]>
Date: Thu, 14 Aug 1997 16:47:05 -0400

>>>>> "LG" == Larry Gensch <[email-masked]> writes:

....
LG> Only one critical problem for Digital Unix (Alpha -- 64 bit
LG> architecture):

LG> cc:  Warning:  virtual.c, line 543:  In this statement, the referenced
LG>      type of the pointer value "&val1" is "long", which is not compatible
LG>      with "int".
LG>   n = GetTwoArguments(action, &val1, &val2, &val1_unit, &val2_unit);
LG> ------^
....
LG> There are other compilation warnings, which I'll pass along if you are
LG> interested.

Sure - send them directly to me, since I don't imagine others would be
interested.

LG> However, these two could cause run-time problems (stray pointers)
LG> and should be fixed.

Hm.  This has been in the code for a while, I believe - have you seen
any runtime problems (coredumps or otherwise) that you could attribute
to it yet?  Just curious.  Anyways, looks like it should be an easy
fix - declare them as int's instead (which I've just done for 2.0.46).
Not sure why they were declared as longs.

LG> Also, from your checklist...

>> relatively simple setup isn't a good test case for this...

LG> I think an even BIGGER win here would be to use gperf to generate
LG> a hash table for quicker lookup for builtins.

Well, I don't think that it'd be that much of an improvement.  After
all, we're only going through approx 85 items, so a simple binary
search should be more than sufficient, I believe.  I'd prefer to stay
with this much simpler approach if it does prove to be adequate.

Chuck

---

From: Greg Badros <[email-masked]>
Date: 14 Aug 1997 14:40:32 -0700

Larry Gensch <[email-masked]> writes:

(warnings stuff deleted)

> table for quicker lookup for builtins.

I did this with gperf, and it's not a huge win (20% startup speed
improvement, or so) but it is faster.  See my patch (including the
*very* very nice (IMHO) menu rewrite and animation enhancements) from my
web site.  I believe I posted the patch (to 2.0.45) here, as well, a
couple months ago.  Its available at:

http://www.cs.washington.edu/homes/gjb/patches/fvwm-2.0.45-menus-animation-gjb.patch

The most important thing I wrote is complete fixing of the menu code to
allow greater and more orthogonal flexibility and *much* MUCH cleaner
keyboard navigation of the menus.  Automatic assignments of shortcuts
still needs to be added, but long menus are split into cascaded shorter
menus as they are created (e.g., the xlock menu from TheNextLevel is too
long to fit on my 1024x768 screen).

I'd really love to see my patches in a new version before 2.1.0.

Greg J. Badros
[email-masked]
Seattle, WA  USA
http://www.cs.washington.edu/homes/gjb

---

From: Anthony Martin <[email-masked]>
Date: Thu, 14 Aug 1997 17:34:41 -0700 (PDT)

On Wed, 13 Aug 1997, Charles Hines wrote:

The following patch should be applied to placement.c.  It undoes one of my
patches for CleverPlacement that turned out to cause more problems than it
fixed.  You must have missed the original post back in January.  Please
apply the following patch to fix it.  Thanks.

Tony

--- placement.c.orig    Thu Aug 14 18:08:31 1997
+++ placement.c Thu Aug 14 18:08:08 1997
@@ -270,8 +270,7 @@
     return -2;
   for(testw = Scr.FvwmRoot.next ; testw != NULL ; testw = testw->next)
   {
-    if((testw == t) || (testw->Desk != Scr.CurrentDesk) ||
-       !(testw->flags & MAPPED))
+    if((testw == t) || (testw->Desk != Scr.CurrentDesk))
        continue;
     if((testw->flags & ICONIFIED)&&
        (testw->icon_w))

---

From: Dan Espen <[email-masked]>
Date: Fri, 15 Aug 1997 08:13:00 -0400

> I'd really love to see my patches in a new version before 2.1.0.

Me too.

I have to say, I  didn't really care for the  added complexity of  the
gperf  change, BUT, the  stuff Greg did  to the menus was outstanding.
I've been  using it  ever since (on   my home machine)  and its really
first rate.

I didn't really need the  long menus, but I  did test them and the way
they get  an automatic keyboard shortcut was  pretty  cool.  Automatic
keyboard shortcuts sounds great.  I can hardly wait.

I really  think the  menu code  needs this revolution,  the  evolution
we've been doing (Ie. LEFT_MENUS) just isn't enough.

--
Dan Espen                                    Phone: (908) 699-5570
[email-masked]
444 Hoes Lane  Room RRC 1C-214
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: [email-masked] (David S. Goldberg)
Date: 15 Aug 1997 14:34:06 -0400

It looks good to me except that I like Dan Espen's colorlimit patch.
Pity it didn't get in.  Fortuantely it applies easily to pre-2.0.46 if
patch is called like this:

patch -F 3 --ignore-whitespace

Using the colorlimit patch required a couple other things be fixed
after applying it:

In both extras/FvwmScript/types.h and xpmroot/xpmroot.c, there are
explicit includes of X11/xpm.h.  With the color limit patch applied,
these lines must be removed (or, I suppose, the include of
../../libs/fvwmlib.h could be moved before it).  Otherwise, there's a
conflict with X11/Intrinsic.h.

Another problem with the colorlimit patch is that FvwmTaskBar calls
the function GetPicture, which is ifdef'd out by the patch.  I didn't
bother to try to fix that since I don't really care about the taskbar.
I'm assuming it wouldn't hurt anything to add the function back in to
the library, or perhaps there's a better function for the taskbar to
call.

Another nit, unrelated to the patch: In the sample.fvwmrc directory,
there's a bug in the Imakefile that causes make install to break.
Here's the fix:

*** Imakefile.orig	Fri Aug 15 13:21:44 1997
--- Imakefile	Fri Aug 15 13:21:51 1997
***************
*** 8,12 ****
  NullMake()
  
  #if InstallSample
! InstallNonExecFile(system.$(FVWMRC),$(FVWMDIR))
  #endif
--- 8,12 ----
  NullMake()
  
  #if InstallSample
! InstallNonExecFile(system$(FVWMRC),$(FVWMDIR))
  #endif

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Fri, 15 Aug 1997 14:57:47 -0400

[email-masked] (David S. Goldberg) writes:
> Pity it didn't get in.

I had an e-mail discussion with Chuck on this, I think the patch
will eventually see the light of day.

> Fortuantely it applies easily to pre-2.0.46 if

Yes, I remember encountering this conflict and resolving it in a couple
of other places.  Why the XPM library conflicts with Intrinsic.h
is a mystery.  I don't think FvwmScript was around when I made up the
patch, or I missed it.

> the library, or perhaps there's a better function for the taskbar to

As I remember, I ifdefed  it out because  it wasn't used.
I'm pretty sure FvwmTaskBar wasn't around either.  I don't see
any problem with "GetPicture" going back in.

---

From: Greg Badros <[email-masked]>
Date: 15 Aug 1997 14:03:02 -0700

Dan Espen <[email-masked]> writes:

> gperf  change, 

Unfortunately, I have to say that I tend to agree, too. But mostly
because I think I didn't do a great job of integrating the running of
gperf into the build process.  This could be fairly painless, but an
option needs to exist for people who don't have gperf available.

> BUT, the  stuff Greg did  to the menus was outstanding.

Thanks!

> we've been doing (Ie. LEFT_MENUS) just isn't enough.

I couldn't agree more! :-)

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: "Charles Hines" <[email-masked]>
Date: Fri, 15 Aug 1997 18:56:02 -0400

>>>>> "Greg" == Greg Badros <[email-masked]> writes:

>> > I'd really love to see my patches in a new version before 2.1.0.

I have to admit that I really like the animated menus, so (as I told
Dan in some private email) some variation of that patch will most
likely appear in 2.0.47.

But I didn't like the thought of wholesale changes to the menu code at
this point in time, which is why it's not in there now, although I do
agree that it needs to be cleaned up.  I figured that after 2.1.0
would be better, but perhaps not for this particular instance.

Since we're talking about menus, an additional item I wanted to add
was the ability to provide different attributes (fg & bg colors,
fonts, etc) for individual menu items, which has been requested in the
past, and a cleaner way to specify the pixmaps.  It thought a slight
enhancement to the menu syntax might be in order which would acomplish
both - an optional field between the string and the action, perhaps
like so:

AddToMenu RootMenu "Root Menu"  {Color red/black}        Title
+                  "New Window" {SPixmap mini.xterm.xpm} Popup NewWinMenu
+                  ""                                    Nop
+                  "Calculator" {Pixmap xcalc.xpm}       Exec exec xcalc

This would also cleanly eliminate the problem with stray pixmaps
appearing in the window list because the window title had strange
characters in it (can you say Emacs?) and provide a small speedup
because the strings wouldn't have to be searched for the pixmap
delimiters, and not every entry would have this special field.  What
do you all think?

Also, I plan to clean up the MenuStyle command for 2.0.47 as well
(make it more like the other *Style type commands in that it won't be
so rigid in syntax).  Something like:

  MenuStyle fvwm, Color black/grey/dimgrey, Font 7x13
                        ^^(fg/bg/stip)^^^^

>> I have to say, I  didn't really care for the  added complexity of  the

Greg> Unfortunately, I have to say that I tend to agree, too. But mostly
Greg> because I think I didn't do a great job of integrating the running of
Greg> gperf into the build process.  This could be fairly painless, but an
Greg> option needs to exist for people who don't have gperf available.

That "option" is exactly what I did - the [very simple to implement
and most likely universally available] binary search should be
producing a decent speedup, mostly likely only slightly less than what
the hashtable would provide in this instance.

Now I could be wrong, which happens occasionally ;^).  So if someone
provides me with actual evidence that the the hashtable provides a
major benefit over the binary search, I'll consider changing it.

Well, this took way too long to type (which is why I didn't reply
earlier) and I really have to get back to work so I can go home at a
quasi-reasonable hour tonight...

Chuck

---

From: Larry Gensch <[email-masked]>
Date: Mon, 18 Aug 1997 09:30:29 -0400 (EDT)

> major benefit over the binary search, I'll consider changing it.

The major benefit of a hash table over a binary search is that lookups
using a "perfect" hash table are constant (one lookup).  A binary
search algorithm on a sorted table takes an average of log2(n)
lookups.  Thus, for fast lookup, hash tables win.

On a more practical note, with only 80-100 items in the table, lookup
times may not be too much of an issue, especially when running on a
500 Mhz Alpha system [smile!].

In addition, somebody on this list also indicated that people without
access to gperf may not be able to compile fvwm2.  My answer to that is
it should be simple enough to include the gperf output as well as the
input in the fvwm2 distribution.  One would only need gperf if one was
going to extend the command table.

I don't have the free time right now to acutally implement gperf in
fvwm2, so I would like to keep it as a suggestion for possible
improvement and not as a practical necessity for fvwm2.0.46.

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 18 Aug 1997 10:52:54 -0400

>>>>> "Larry" == Larry Gensch <[email-masked]> writes:

>> major benefit over the binary search, I'll consider changing it.

Larry> The major benefit of a hash table over a binary search is that lookups
Larry> using a "perfect" hash table are constant (one lookup).

Correct.

Larry> A binary search algorithm on a sorted table takes an average of
Larry> log2(n) lookups.

Actually, I believe that it's worst case is log2(N) - the average
should actually be slightly less.

Larry> Thus, for fast lookup, hash tables win.

I never denied that.  It was the relative benefit vs complexity that I
was arguing.

BTW - the 'actual' evidence I had in mind was something along the
lines of a table comparing the actual startup times for the two
different implementations for a sampling of different startup scripts.

Larry> On a more practical note, with only 80-100 items in the table, lookup
Larry> times may not be too much of an issue,

That was part of the point I was trying to make - worst case is 7
compares for 65-128 items, many of which will move on after checking
only 1 character.  That shouldn't take very long at all, especially
compared to the previous O(N) linear search which was probably doing
an average of over 40 compares each time with a worst case of ~85.

Larry> especially when running on a 500 Mhz Alpha system [smile!].

Now that'd be nice to have...  I'd love to replace my Intel box at
home with one of those running Linux.

Chuck

---

From: Dan Espen <[email-masked]>
Date: Mon, 18 Aug 1997 11:16:54 -0400

> +                  "Calculator" {Pixmap xcalc.xpm}       Exec exec xcalc

I can't  find  any other use  of  "{" (curly  brace) in  current fvwm2
syntax.  We have "["  after "next", and the  heavy  use of "("  in the
module config syntax.  I would recommend "(".

If  I had a request for  more color in the   menus, it would  be for a
color for the hotkey  letter.  I find the underscore  hard to see.   I
would assume this color would belong in the MenuStyle command.

In the example you specify,  only the "title" has a  unique color.  If
that is   all you wanted   to color,  that  would   also be a  logical
"MenuStyle" command.

Assuming SPixmap stands for "SidePixmap"  I would vote for spelling it
out.  (Sorry, I guess  I spent too   many years writing COBOL and  old
habits die hard.)

I have lots of existing .fvwm2rc config files.  I would have to figure
out how to transform:

+ "%mini.window.xpm%&W. Window Operations" Popup Window-Ops
to
+ "&W. Window Operations" (Pixmap mini.window.xpm) Popup Window-Ops

Doesn't look like it should be that hard.  I would attempt to put this
in my fvwm2 start-up script.

>   MenuStyle fvwm, Color black/grey/dimgrey, Font 7x13

This also seems to be fairly easy to automatically convert.  I notice
the first paramter to MenuStyle remains a "positional" parameter.
I think this would be a little more consistent:

  MenuStyle Type fvwm, Color black/grey/dimgrey, Font 7x13

---

From: Greg Badros <[email-masked]>
Date: 18 Aug 1997 09:43:48 -0700

> would be better, but perhaps not for this particular instance.

Unfortunately, the animations are pretty tightly bound to the rewritten
menu code.  The problem is that the menu code (before my rewrite) limits
the number of levels deep to 3 -- it only remembers the previous menu,
the current menu, and the next menu in scalar pointers (i.e., not in an
array).  To make matters worse, the notion of what the current menu is
varies between the menu styles (mwm style has different semantics from
fvwm style, etc.).  The animations require reliable navigation of
greater depth so that intermediate menus can be animated back to the
right as the user unwinds to higher level menus.

If the current menu code were robust, I'd agree about not changing
stuff;  however it's *buggy* big time!  And the bugs are often due to
various major design flaws, and cannot be corrected individually (I
tried; I didn't want to rewrite as much of the menu code as I had to,
but the more I understood what was going on, the uglier it all looked).

> past, and a cleaner way to specify the pixmaps.  It thought a slight

You have to be careful w/ colors, as that can interfere w/ the highlight
mechanism.  The cleaner way to specify pixmaps should've been done to
begin with, IMHO.

> characters in it (can you say Emacs?) and provide a small speedup

This is just a bug-- I've fixed it in my patches;  just due to scanning
for the pixmaps when created the window list-- you don't have to do
that.  (Though someone wrote me that they wanted that behaviour; I think
that that is wrong, but if we need to do that, we need a more obscure
sequence of special characters).

> the hashtable would provide in this instance.

My guess is that a good speedup could be gotten by remembering the last
command dispatched and prechecking for that w/ a strcmp and go right away
(avoiding the binary/linear scan of the command table) if it's the
same.  This is a primitive dynamic version of the obvious idea to do a
linear search w/ the most frequently used commands at the head of the
list.  My claim is that the most frequently used command is the prior
command (i.e., commands are often repeated; e.g., a "AddToMenu" section
might have hundreds of such commands all in a row).  [This is especially
true when aggressively using m4 to preprocess the fvwm2rc files like
TheNextLevel does].

Another reason that now is the time for the menu patch is that it'll be
easier to apply now (it applies cleanly to 2.0.45, and the further away
we get from that, the more work it'll be to get the changes back in the code).

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: Greg Badros <[email-masked]>
Date: 18 Aug 1997 10:20:10 -0700

> I never denied that.  It was the relative benefit vs complexity that I

Development effort is minimal, since it's already done.  As Larry
suggested, using a prepackaged gperf output for those w/o gperf
eliminates that as a concern.

> different implementations for a sampling of different startup scripts.

As mentioned in my patch description, the hash table reduced my startup
time by 15% or so in 2.0.45 on my rather lengthy .fvwm2rc (about 100k after
FvwmM4 processing).  Note, too, that since I do use FvwmM4, that
accounts for a bigger chunk of startup time than others would
experience.  Said another way, I'd expect better than 15% improvement
for those who write pure .fvwm2rc, not using FvwmM4 (or FvwmCpp for that
matter [though why would you do that???]).

> only 1 character.  That shouldn't take very long at all, especially

It's the function calls that takes time, not the compare.  The fact that
"strcmp" can short-circuit the compare after 1 character doesn't change
the running time much (besides, a lot of commonly used commands share
prefixes, anyway).

Bottom line, it empirically does make a difference, and makes more of a
difference as more commands are added, and is already written, and isn't
much more work and adds only a little bit of complexity (mostly to the
build procedure--it actually simplifies the code quite a bit;  a binary
search is a lot easier to get wrong than a simple hash table lookup).

I vote for using the hash table implementation as an option for now, and
later remove the complexity of the alternative methods if there are no problems.

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: "Josh M. Osborne" <[email-masked]>
Date: Mon, 18 Aug 1997 13:52:15 -0400

In message <[email-masked]>, Larry Gensch writes:
[...hash tables vs. bin search...]
>500 Mhz Alpha system [smile!].

Note: one "perfect" hash lookup is O(1) memory reference, one binary
tree lookup is O(log N) memory references.  The memory system on
the 500Mhz Alpha is a *lot* slower then anything else (except I/O)
on that Alpha.

So the speed diffrence between the "perfect" hash and a bin lookup
is likely to be more then you expect on faster CPUs!

>going to extend the command table.

They do this sort of thing with the perl distribution, you need bison
(or flex and bison?) to add new keywords to perl, but you don't need
them to just compile perl.

A similar thing is done with the xtank distribution.

If you are careful with the make targets (i.e. make clean doesn't
remove your ability to re-build) nobody complains.  If you are
careless folks complain...

[...]

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 19 Aug 1997 18:22:37 -0400

>>>>> "Dan" == Dan Espen <[email-masked]> writes:

Dan> "Charles Hines" <[email-masked]> writes:
....
>> +                  "Calculator" {Pixmap xcalc.xpm}       Exec exec xcalc

Dan> I can't  find  any other use  of  "{" (curly  brace) in  current fvwm2
Dan> syntax.  We have "["  after "next", and the  heavy  use of "("  in the
Dan> module config syntax.  I would recommend "(".

Heavy use of "()" in module config syntax?  The only one that really
uses parens is FvwmButtons, no?

Not that it matters - I suppose that any of them would probably be as
good as another in this situation.  But you're right, {} isn't used
anywhere else currently so using one of the other two might be better,
and () probably is the better choice out of those.

Dan> If  I had a request for  more color in the   menus, it would  be for a
Dan> color for the hotkey  letter.  I find the underscore  hard to see.   I
Dan> would assume this color would belong in the MenuStyle command.

Hm - not a bad idea, I think.  I'll have to keep that in mind.

Dan> In the example you specify,  only the "title" has a  unique color.  If
Dan> that is   all you wanted   to color,  that  would   also be a  logical
Dan> "MenuStyle" command.

Merely a coincidence.  The original request(s) were to make arbitrary
entries various colors (like [c]twm?).  Although perhaps a default
color setup for the titles might not be a bad MenuStyle addition.

Dan> Assuming SPixmap stands for "SidePixmap"  I would vote for spelling it
Dan> out.  (Sorry, I guess  I spent too   many years writing COBOL and  old
Dan> habits die hard.)

I fully agree (I prefer the more verbose syntax myself) - I was just
being lazy when I typed that, as well as trying to have my example fit
in 80 chars. :)

Dan> I have lots of existing .fvwm2rc config files.  I would have to figure
Dan> out how to transform:

Dan> + "%mini.window.xpm%&W. Window Operations" Popup Window-Ops
Dan> to
Dan> + "&W. Window Operations" (Pixmap mini.window.xpm) Popup Window-Ops

Dan> Doesn't look like it should be that hard.  I would attempt to put this
Dan> in my fvwm2 start-up script.

Yeah, I didn't think it would be to difficult to change, although I'm
sure it'll bite some people and we'll see several notes saying "hey,
how come my menus are all messed up now?".

....
>> MenuStyle fvwm, Color black/grey/dimgrey, Font 7x13

Dan> This also seems to be fairly easy to automatically convert.

Yup, should be, although as I said above we'll probably see lots of
notes because people forgot to convert it or didn't notice the change.
But then, isn't that what these betas are for?  Small incompatable
changes that make people who don't follow the mailing lists
miserable... :)

Dan> I notice the first paramter to MenuStyle remains a "positional"
Dan> parameter.  I think this would be a little more consistent:

Dan>   MenuStyle Type fvwm, Color black/grey/dimgrey, Font 7x13

Actually, I figured it could recognize "fvwm" and "mwm" as single
parameters, much like the many single parms that the Style commands
recognize.  The fact that I put it first above was coincidence and not
an indicator of "positionality".

Chuck

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 19 Aug 1997 18:56:27 -0400

>> would be better, but perhaps not for this particular instance.

Greg> Unfortunately, the animations are pretty tightly bound to the rewritten
Greg> menu code.
....
Greg> If the current menu code were robust, I'd agree about not changing
Greg> stuff;  however it's *buggy* big time!  And the bugs are often due to
Greg> various major design flaws, and cannot be corrected individually (I
Greg> tried; I didn't want to rewrite as much of the menu code as I had to,
Greg> but the more I understood what was going on, the uglier it all looked).

Yeah, I think that doing this before 2.1 might not be a bad idea.  It
defintely does need to be overhauled sometime, and I think I would
like the menu animation in there before 2.1, so as I said I'll
probably put some form of the menu update into 2.0.47.

Whoops - I need to finish up 2.0.46 first!  :)
I'll see if I can finish that up in a few minutes and get it out to
the masses this evening.

>> past, and a cleaner way to specify the pixmaps.  It thought a slight

Greg> You have to be careful w/ colors, as that can interfere w/ the
Greg> highlight mechanism.

Of course that will have to be altered as well.

Greg> The cleaner way to specify pixmaps should've been done to begin
Greg> with, IMHO.

I fully agree.

>> characters in it (can you say Emacs?) and provide a small speedup

Greg> This is just a bug-- I've fixed it in my patches;  just due to scanning
Greg> for the pixmaps when created the window list-- you don't have to do
Greg> that.

I know you fixed it in your patch, that was one of the reasons for
suggesting this menu syntax change in the hopes of making it all
cleaner and not having to scan the text for that at all, just for the
hotkey.

This brings up another thought - specify the hotkey in the new section
too?  Then we wouldn't have to worry about any special chars in the
string at all, the hotkey could be a character that isn't in the
string at all (making the builtin winlist generation slightly easier),
and the hotkey could be universally placed at the beginning of the
menu entry instead of highlighting it in the string.  Or allow both
ways?  Thoughts?

Greg> (Though someone wrote me that they wanted that behaviour; I
Greg> think that that is wrong, but if we need to do that, we need a
Greg> more obscure sequence of special characters).

Probably not necessary - they probably wanted it for the builtin
winlist which now has the mini icon capability which should serve the
same end goal.

....
>> the hashtable would provide in this instance.

Greg> My guess is that a good speedup could be gotten by remembering the last
Greg> command dispatched and prechecking for that w/ a strcmp and go right away
Greg> (avoiding the binary/linear scan of the command table) if it's the
Greg> same.  This is a primitive dynamic version of the obvious idea to do a
Greg> linear search w/ the most frequently used commands at the head of the
Greg> list.  My claim is that the most frequently used command is the prior
Greg> command (i.e., commands are often repeated; e.g., a "AddToMenu" section
Greg> might have hundreds of such commands all in a row).  [This is especially
Greg> true when aggressively using m4 to preprocess the fvwm2rc files like
Greg> TheNextLevel does].

Hm.  That perhaps isn't a bad idea.  I already was prechecking for a
'+' character, figuring that would be a large portion of peoples
files, but yes I imagine the people using preprocessing could
potentially benefit more from this precheck previous command approach
(and the '+' performance would be almost as good as well).

Greg> Another reason that now is the time for the menu patch is that
Greg> it'll be easier to apply now (it applies cleanly to 2.0.45, and
Greg> the further away we get from that, the more work it'll be to get
Greg> the changes back in the code).

That doesn't really bother me all that much, since I generally have to
hand apply patches anyways, as well as occasionally reimplementing
them differently (for whatever reason).  Plus, I don't think I want to
put some of your patch in anyways, specifically the animated move
stuff.  I know that last comment is going to aggravate some people,
but my reasoning is thus - people who move (interactively) opaquely
won't want to see and animated move because that's about what they
already did, and those using the frame moves are probably doing it
because they don't want to eat up the server resources, etc.  So,
since this probably wouldn't be used interactively, this could
probably be implemented as a module...

Chuck

---

From: Greg Badros <[email-masked]>
Date: 19 Aug 1997 16:20:17 -0700

(lots of good discussion deleted)

> probably be implemented as a module...

Well, here's my use of animated moves of windows.  I, in fact, do use
opaque windows, and much prefer the way the CSM-f keystroke lets my eyes
know what has happened to the window by moving it to the top left corner
with animation, rather than just having the window jump there w/o visual
cues.  To be complete, the framed move should do the animation, too (I'm
pretty sure I don't support that);  to me it's a question of visual
feedback that even a low-resources machine might benefit from.

However, the one very important thing missing from AnimatedMove is a
flag that toggles whether the pointer moves with the move or not.  i.e.,
you can imagine moving the pointer an equivalent distance so that the
pointer stays in the same position relative to the window.  This is good
behaviour if you are moving the current window.  BUT, if you are moving
another window, moving the pointer is a big mistake (it'd go off
screen).  There should be an argument that lets you say
"MovePointerToo", "NoMovePointer", or "Automatic" (the default) which
would only move the pointer when invoked on the current window (is this testable)?

# FixWindowSize is really nice on a small screen,
# when you get a window way too big-- this makes
# it 85% of the screen by 85% of the screen, and puts
# it in the top left
AddToFunc FixWindowSize
+ "I" Resize 85 85
+ "I" AnimatedMove 0p 0p

Key f 		A	CSM	FixWindowSize

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: Greg Badros <[email-masked]>
Date: 19 Aug 1997 16:26:38 -0700

> menu entry instead of highlighting it in the string.  Or allow both

You could allow specifying it via a <> option, and if it is, then make
that be a letter in front of the menu item.  Using the current method
could mean underline it -- that way the user can use either method (or
mix them) w/o adding a new menu style.

The big things I care about are *at least* warning when a shortcut key
is used repetitive times and splitting long menus into multiple menus.
Ideally, we could have a mechanism to say "automatically" pick a
shortcut key.  My TheNextLevel does this w/ preprocessing, but breaks
when you are dealing w/ long menus that get split since at the FvwmM4
level, it still thinks of the menu items as belonging to the same
super-long menu and won't reuse shortcut keys.  Fvwm can and should be
smarter.  The complication is that you can't assign the shortcut key
until after the whole menu is created (i.e., not until when the menus
get built internally).  Consider

"Foo" <AutoShortcut> Function Foo
"Bar &foo" Function Bar

Here I think that the Bar item should get the F shortcut, but the
obvious algorithm for the auto shortcuts would have already assigned
that shortcut to do the Foo shortcut.  Because of the dynamic way menus
are created, you need to defer selection of auto shortcuts until later.

Greg J. Badros
[email-masked]
Seattle, WA  USA

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 19 Aug 1997 19:30:22 -0400

>> I never denied that.  It was the relative benefit vs complexity that I

Greg> Development effort is minimal, since it's already done.  As Larry
Greg> suggested, using a prepackaged gperf output for those w/o gperf
Greg> eliminates that as a concern.

The complexity arises in adding things in the future (either by myself
or by those submitting patches affecting the function list).  Plus in
the readablilty of the source code.

>> different implementations for a sampling of different startup scripts.

Greg> As mentioned in my patch description, the hash table reduced my
Greg> startup time by 15% or so in 2.0.45 on my rather lengthy
Greg> .fvwm2rc (about 100k after FvwmM4 processing).  Note, too, that
Greg> since I do use FvwmM4, that accounts for a bigger chunk of
Greg> startup time than others would experience.  Said another way,
Greg> I'd expect better than 15% improvement for those who write pure
Greg> .fvwm2rc, not using FvwmM4 (or FvwmCpp for that matter [though
Greg> why would you do that???]).

Ok, but that is over the original linear search.  I'd still be willing
to bet that the binary search provides very close to that same
improvement amount.  But then, perhaps not - I haven't had a chance to
do any actual timed comparison yet (and no one else has offered one
either).

>> only 1 character.  That shouldn't take very long at all, especially

Greg> It's the function calls that takes time, not the compare.  The fact that
Greg> "strcmp" can short-circuit the compare after 1 character doesn't change
Greg> the running time much

Ok, I'll give you that.  But it would probably be pretty easy for me
to implement that binary search inline instead of using the bsearch &
compare function approach, eliminating most/all of the extra function
calls.  And it would still be rather simple code.

Greg> (besides, a lot of commonly used commands share prefixes, anyway).

True, but the only real significant ones are currently Add[To]* and
Window*.  Putting in your last command precheck idea will probably
help a bit to get around that problem as well.

Greg> Bottom line, it empirically does make a difference, and makes
Greg> more of a difference as more commands are added,

Both very true.

Greg> and is already written, and isn't much more work and adds only a
Greg> little bit of complexity (mostly to the build procedure--

Which means it mostly inconviences me. :)  And any patch submitters, of
course.  Perhaps this makes me a little biased?

Greg> it actually simplifies the code quite a bit; a binary search is a
Greg> lot easier to get wrong than a simple hash table lookup).

True - I do have to make sure that I keep the table in proper ascii
order (ignoring case).  But that isn't too difficult most days... :)

Greg> I vote for using the hash table implementation as an option for
Greg> now, and later remove the complexity of the alternative methods
Greg> if there are no problems.

Sorry, I'm not trying to be a pain in the ass about this, but I really
don't want to add it right now - for all the reasons I've already
stated: I think the simple binary search (especially with the
additional last command precheck you suggested) should provide a more
than adequete speedup (admittedly less than the hash table) without
really adding complexity to any portion of the code or build process.

Perhaps I'm wrong, but no one has changed my mind yet (and I can be a
little stubborn at times - ask my wife). :)

Chuck