Subject: future of fvwm2 (featuritis?)

From: Dominik Vogt <[email-masked]>
Date: Wed, 25 Nov 1998 20:29:55 +0100

Wow, Jitterbug is definitely worth its money. It cut my inbox
down from 236 messages (one or two weeks ago) to 36 now 8-).
So I have time to talk about what we want to do with fvwm2 in
the future.

In the last few weeks we've seen some patches, requests and
suggestions for colourful and fancy features that (in my eyes)
only few people will use. If anybody would ask me I'd tell him
that we have already gone too far in some respects: who does
really need borders with pixmaps? Or 25 different ways of
managing icons or window styles that can be stacked until the
swap space is exhausted?

Granted, such features look nice and make it incredibly
flexible. A few months ago I talked with Tim why there was
so little going on on the list and he suspected most people
were eagerly looking at scwm because it 'beats fvwm on
configurability'. But where does this place us regarding
usability? In some cases fvwm lacks (or lacked recently) the
most basic features that really help the average user:
cursor key movement in menus, tear-off menus, a generic (and
working!) auto hide mechanism. Or for developers: clearly
defined debugging and parsing APIs.

The masses definitely do not need pixmaps everywhere, each
and every colour definable etc. What the average user will
like (except easy customizetion, but that's another topic)
are fantastic features like SloppyFocus or SnapAttraction.

I think after 2.2 we should concentrate on cleaning up the
mess we have right now in some parts and keep a tight lid
on the new-feature box. The philosophy of fvwm once was
being small and efficient. When I learned about fvwm it
was called 'the' window manager. It is still widely known,
but will it continue like that if we try to force in each
and every fancy feature?

Just my own thoughts. Comments?

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.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: Dominik Vogt <[email-masked]>
Date: Wed, 25 Nov 1998 20:41:17 +0100

One thing I wanted to add:

If people do not like fvwm because it does not have every
feature imaginable they can use another window manager. There
are *so many* of them already. We don't want to make everybody
happy. If it were like this all window managers would end up
roughly the same, huge and maybe slow too, and users would
wonder why they were all bloated with stuff they'd never
wanted to use whereas there would be no small, fast and
efficient wm.

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 25 Nov 1998 15:10:21 -0500

> Just my own thoughts. Comments?

I agree with most of what you said.

Since I just love my blue-marble window borders, I'll disagree on that
one.

Scwm has  a nice configuration language.   What  fvwm2 needs to  do is
make the configuration language irrelevant.   We need good ways for an
administrator to configure  for users, and  users to configure without
using a text editor.

One of the reasons I'm doing all this work on FvwmForm,  is that I see
FvwmForm  as part of  the solution.  Maybe  it isn't, but we need some
kind of GUI  that we can use to  configure all the important  parts of
fvwm2.

The only other thing I think is relevant is, "people always contribute
what they want".  In other words,  I spent all  that time on the built
in icon box, because thats the iconbox I use.   If I used FvwmIconMan,
or FvwmIconBox, there  is no  way I would   have done anything  to the
built-in  iconbox.  So, to some extent,  people will usually only work
on what they are interested in.

I think we just have to deal with features on a case by case basis.

As   far  as spending time  making    fvwm2  more efficient,  I'm  not
experiencing any performance problems.  Look at what I'm running:

last pid:  7317;  load averages:  0.00,  0.02,  0.04                   15:05:07
71 processes:  68 sleeping, 1 running, 1 zombie, 1 on cpu
CPU states: 98.0% idle,  1.2% user,  0.8% kernel,  0.0% iowait,  0.0% swap
Memory: 128M real, 8584K free, 48M swap in use, 952M swap free

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
17676 dane       1  -7    0   23M   17M sleep  23:26  1.18% xemacs-20.4
 7317 dane       1  34    0 1488K 1376K cpu     0:00  0.81% top2.6
  515 dane       1  34    0   20M   15M sleep  53:58  0.81% Xsun
  300 root       5  33    0 3816K 2560K sleep   7:22  0.14% automountd
24991 dane       1  34    0 2672K 1288K sleep  13:55  0.08% SSxbiff
 6104 dane       1  34    0 2968K 2344K sleep   0:04  0.06% fvwm2
 4007 dane       1  34    0 3360K 2744K sleep   0:02  0.04% rxvt
  550 dane       1  24    0 4872K 3048K sleep   1:41  0.03% xscreensaver
 4009 dane       1  31    0 1712K 1328K sleep   0:01  0.03% ksh
 6648 dane       1  24    0   26M   20M run     0:44  0.02% netscape
  579 dane       1  24    0 4168K 2392K sleep  19:28  0.00% workman
  523 dane       1  24    0 4656K 2320K sleep   0:33  0.00% contool
  324 root      11  33    0 2640K 1872K sleep   0:19  0.00% nscd
    1 root       1  33    0  680K  168K sleep   0:17  0.00% init
  549 dane       1  34    0 2008K  976K sleep   0:14  0.00% unclutter

I see 17Meg RES in XEmacs, 15Meg in my XServer, 20Meg in Netscape, and
2.3Meg in fvwm2.  Its smaller than rxvt, or workman...

I'll take everything back, seems like it can stand a lot more features.
(Just kidding.)

--
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: Dominik Vogt <[email-masked]>
Date: Thu, 26 Nov 1998 11:37:37 +0100

> I agree with most of what you said.

Thanks, I had hoped so.

> Since I just love my blue-marble window borders, I'll disagree on that

That is not the point I wanted to make. It may be nice to look at, but
it server no real purpose. There is no gain in usability. And usually
you want to keep the borders small so they don't take away so much
space.
 
> administrator to configure  for users, and  users to configure without

Yes, absolutely. I don't see me as part of the development here though.
 
> kind of GUI  that we can use to  configure all the important  parts of

I've never seem it, but there's the dotfile generator with a module for
at least fvwm version 1. Might that help us too?
 
> on what they are interested in.

Perfectly clear, I do the same. Well, at least I used to.

> experiencing any performance problems.

I find page switching and startup annoyingly slow and would like to speed
that up (9 seconds to start X and fvwm2). There is much room for
improvementt in the initial parsing pass of the config file

> Memory: 128M real, 8584K free, 48M swap in use, 952M swap free

Wow, you swap space alone is larger that my whole memory. Could you
put half your RAM in an envelope and send it to me? ;-)

> I'll take everything back, seems like it can stand a lot more features.

Oh, I didn't know it was so small. What about this menu-shadow feature
that was rejected? Perhaps we should include it after all ;-)

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 29 Nov 1998 23:07:25 -0800

My $0.02 on this:

The main advantage to fvwm, in my book, is modules.  Few, if any, other
WM's have these, and they allow people to pick and choose how fat or
skinny they want their WM without having to recompile special versions,
etc.  Also, it keeps the code clean, segregated, etc. etc.

I think we should absolutely try extra, extra hard to put new features
into modules wherever possible.  I also think trying hard to move
existing "fancy" features into modules wherever possible is A Good
Thing.

This may involve expansion/extension of the fvwm2-to-module interface.
That's fine w/ me.

It may involve examining and changing the current module configuration
scheme.  That's also fine w/ me.

Beyond that guiding principle, here're my items:

 1) We need theme support.  We should work hard with whomever is looking
    into this to be sure we can get fvwm2 to "do" themes in as painless
    a manner as possible.  Right now I don't think fvwm2 is very "theme
    friendly" from a config file point of view.

 2) Config file syntax.  I hate to bring up this bugaboo again, but the
    current syntax makes me nuts.  Plus, it seems like every time we
    turn around someone is adding a new feature that requires some new
    syntax, and much of it is added fairly helter-skelter.  It's kinda
    scary.  I've done a bit of it, and language design is a very, very
    hard thing to get right.  Fvwm2's config language is not too great:
    it's not regular enough, it's not easily extensible because the
    format is too open, etc.

    It may be that (Dan?  Bob?  Someone?) is right, and what we should
    be doing is trying to make that irrelevant by providing GUI config.
    While a laudable goal, it seems a long way off and still no excuse
    for excessively baroque syntax.

    Not sure exactly what to do here, except re-emphasize we should take
    hard looks at any enhancements which require config syntax changes,
    to make sure they're done as well as can be.

 3) It still seems to me like we have module overlap, and it would be
    good to generate a document with at least some basic strengths and
    weaknesses of each to allow users to make educated decisions.  And
    we should take a very hard look at things in extras: the goal here
    should be either to elevate them to modules, if they're polished
    enough (whatever that means :), or remove them from the dist (maybe
    make them available separately).

 4) My pet feature request: an icon manager that allows me to "group"
    windows by class (or instance, etc.) and, when iconfied, all windows
    in that class have only one icon.  When that icon is selected, a
    popup menu containing a list of windows in that group is provided.

    Just had to throw that in :)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.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: Todd Larason <[email-masked]>
Date: Mon, 30 Nov 1998 03:10:26 -0800

At the risk of boring everyone...

On 981129, Paul D. Smith wrote:
>     syntax, and much of it is added fairly helter-skelter.  

This is always the problem with configuration languages - they grow, and grow, 
and grow.  And they don't always grow very coherently.

>     popup menu containing a list of windows in that group is provided.

In scwm:

(define xterm-window? (class-match?? "XTerm"))
(define (popup-icon-menu)
  (cond ((xterm-window? (get-window))
	 (show-window-list-menu #:only (lambda (win)
					 (and (xterm-window? win)
					      (iconified? win)))))
	(else
	 (popup-menu 'menu-window-actions))))
(bind-mouse 'icon 3 popup-icon-menu)

will give you the kind of menu you're looking for, for xterm icons.

Adding a small, straight forward patch:

diff -u -p -r1.39 Makefile.am
--- Makefile.am	1998/11/16 22:43:11	1.39
+++ Makefile.am	1998/11/30 11:03:32
@@ -89,7 +89,7 @@ guile_snarfs = Grab.x add_window.x bindi
 decor.x deskpage.x events.x face.x font.x image.x menu.x menuitem.x \
 miscprocs.x module-interface.x move.x placement.x resize.x \
 screen.x shutdown.x window.x xproperty.x xrm.x constraint-primitives.x \
-drawmenu.x menulook.x virtual.x
+drawmenu.x menulook.x virtual.x icons.x
 
 BUILT_SOURCES = init_scheme_string.c scwmpaths.h scm_init_funcs.h \
 	$(guile_snarfs)
diff -u -p -r1.47 icons.c
--- icons.c	1998/11/18 00:04:15	1.47
+++ icons.c	1998/11/30 11:03:35
@@ -42,6 +42,10 @@
 #include "color.h"
 #include "focus.h"
 #include "xmisc.h"
+#include "callbacks.h"
+
+static SCM iconify_hook;
+static SCM deiconify_hook;
 
 /***********************************************************************
  *
@@ -688,6 +692,7 @@ DeIconify(ScwmWindow *psw)
       if (t->icon_pixmap_w)
 	XUnmapWindow(dpy, t->icon_pixmap_w);
       Broadcast(M_DEICONIFY, 3, t->w, t->frame, (unsigned long) t, 0, 0, 0, 0);
+      call1_hooks(deiconify_hook, t->schwin);
     }
   }
 
@@ -749,6 +754,7 @@ Iconify(ScwmWindow *psw, int def_x, int 
 
         BroadcastIconInfo(M_ICONIFY,t);
 	BroadcastConfig(M_CONFIGURE_WINDOW, t);
+	call1_hooks(iconify_hook, t->schwin);
       }
     }
   }
@@ -771,6 +777,7 @@ Iconify(ScwmWindow *psw, int def_x, int 
   psw->fIconUnmapped = False;
   BroadcastIconInfo(M_ICONIFY, psw);
   BroadcastConfig(M_CONFIGURE_WINDOW, psw);
+  call1_hooks(iconify_hook, psw->schwin);
 
   LowerWindow(psw);
 
@@ -831,6 +838,23 @@ SetMapStateProp(ScwmWindow *psw, int sta
 		  PropModeReplace, (unsigned char *) data, 2);
   return;
 }
+
+void
+init_icons()
+{
+  SCWM_HOOK(iconify_hook, "iconify-hook");
+  /** This hook is invoked when a window is iconified.
+It is called with one argument, WINDOW */
+
+  SCWM_HOOK(deiconify_hook, "deiconify-hook");
+  /** This hook is invoked when a window is deiconified.
+It is called with one argument, WINDOW */
+
+#ifndef SCM_MAGIC_SNARFER
+#include "icons.x"
+#endif
+}
+
 
 /* Local Variables: */
 /* tab-width: 8 */
diff -u -p -r1.153 scwm.c
--- scwm.c	1998/11/24 11:35:47	1.153
+++ scwm.c	1998/11/30 11:03:50
@@ -556,6 +556,7 @@ scwm_main(int argc, char **argv)
   init_placement();
   init_Grab();
   init_virtual();
+  init_icons();
 #ifdef USE_CASSOWARY
   init_constraint_primitives();
 #endif

And the following comes very close to giving you only one icon for xterms:

(define current-xterm-icon-window #f)

(define (xterm-iconify-hook window)
  (cond ((xterm-window? window)
	 (cond ((not current-xterm-icon-window)
		(set! current-xterm-icon-window window)
		(map (lambda (win) 
		       (cond ((not (eq? win window))
			      (set-show-icon! #f win))))
		     (list-windows #:only (lambda (win)
					    (and (xterm-window? win)
						 (not (iconified? win)))))))))))

(define (xterm-deiconify-hook window)
  (cond ((and (xterm-window? window)
	      (eq? window current-xterm-icon-window))
	 (let ((iconified-xterm-list 
		(list-windows #:only (lambda (win)
				       (and (xterm-window? win)
					    (iconified? win))))))
	   (cond ((eq? iconified-xterm-list ())
		  (map (lambda (win)
			 (set-show-icon! #t win))
		       (list-windows #:only (lambda (win)
					      (and (xterm-window? win)
						   (not (iconified? win)))))))
		 (else
		  (set-show-icon! #t (car iconified-xterm-list))))))))

(add-hook! iconify-hook xterm-iconify-hook)
(add-hook! deiconify-hook xterm-deiconify-hook)

I think all that's needed to finish it is to hook into new-window and 
set-show-icon! appropriately for new xterms, depending on whether or not
there's currently an xterm icon showing.  It's late, though, and I'm supposed
to be getting back on a normal schedule...

I expect the one-icon part can be done better.  I'm not a scheme expert by any 
means, and this was a half hour hack, C change included.
-- 
ICQ UIN: 37961006
--
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: Mon, 30 Nov 1998 08:24:01 -0500

> you want to keep the borders small so they don't take away so much

I felt  the same way about  borders UNTIL  I started using blue-marble
window borders.  I found them so visually appealing,  I was willing to
give up  the  screen space to 10   pixel borders.  A  21  inch monitor
helps.

> at least fvwm version 1. Might that help us too?

There is a fvwm2  version.    My first  complaint  is its  Tcl  based.
Second,  its   not interactive with  fvwm2.    I'm looking for tighter
integration with fvwm2.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 30 Nov 1998 14:47:41 +0000

> existing "fancy" features into modules wherever possible is A Good

I agree 100%.  I think there is scope for removing lots of cruft from
fvwm and putting it into modules.  I think Fvwm should be a window
manager and not try to be a complete GUI.  The modules can be the GUI,
fvwm should do simple focus management, window geometry,
desking,paging,iconifying,shading.  The modules should do animation
effects, window decoration, menu posting etc.

>     it's not regular enough, it's not easily extensible because the

I agree -100% 8-).  If you want a syntax language that has a BNF
definition, is Turing complete and all the other things that CS people
like then Scwm is where it's at.  The current syntax is simple to
implement (with the token stuff from fvwmlib) and is very quick to
code.  If we come up with a syntax it will only be a matter of months
before a new feature pops up that requires the syntax to be extended.

>     make them available separately).

Yeah, I know, it seems like 50% of the modules are the WindowList menu
in some form: FvwmWinList, FvwmIconMan, FvwmTaskBar, FvwmPager,
FvwmIconMan. They all do similar but different things.

Cheers,
Tim.

---

From: Michael C Tilstra <[email-masked]>
Date: Mon, 30 Nov 1998 10:34:16 -0600

>     friendly" from a config file point of view.

Actually I am going to have to dissagree with this to some point.  At one
time I put together a (IMHO) decent theme setup using PipeRead, a simple
shell script, and built up the pieces with Decors and a Function. (you
could almost add it to any existing config file with three lines(one to
build the menu, one to call the default item, and a addition to the pixmap
path)) It would switch themes without restarting fvwm from a built up menu. 
(but you did have to restart for it to reread the themes dir.) It still has 
a few bugs, but I've not done anything with it for a while yet either.

I will also have to say that this depends on what you call a theme.  From
my point-of-view, window titles&borders, menu colors&styles. But not the
content of the windows or menus.  (Its a complaint of mine when that kind
of stuff starts messing with menuitems or buttonbars.  I consider that
content and not themable.)

I could solidify what I have a bit and make it availible to people if
anyone is interested.

-- 
Mike Tilstra                                   Tadpol
[email-masked]  http://www.tc.umn.edu/~tils0007/
   Sanity is the playground for the unimaginative.
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 30 Nov 1998 18:21:40 +0100

> content and not themable.)

Personally I'd think a theme should include colour schemes as well.
This is really a pain in the ass. Did you ever try to put the same
background colour on all windows swallowed by FvwmButtons?
E.g. xosview doesn't accept '-bg', only .Xdefaults settings. What
I do at the moment: I #include a named colour scheme from a file
(that is rewritten when I change the scheme). Actually these
palettes are stolen from CDE. Then I use the #defines for my
application colours. For xosview I have to make xrdb swallow
a line with the xosview*background line, then waste as much time
as possible before starting xosview so that xrdb has finished
when xosview reads these entries. And still it fails about 20%
of the time.

Bye

Dominik

---

From: Michael C Tilstra <[email-masked]>
Date: Mon, 30 Nov 1998 11:54:36 -0600

> when xosview reads these entries. And still it fails about 20%

Sometime ago I tried, I gave up on that.  Some apps can be so evil about
changing little things like color.  I will agree that things like colors
and possibly fonts should also be themable.  However, I will also have to
say that it would probably be perferable to avoid trying to themize things
that are outside of fvwm. (anything not fvwm or a module)  Mostly because
there are so many little apps that people use, and massive chaos could
araise trying to keep track of all of them. (Besides, isn't this kinda of
what gnome is trying to do (among other things))

All in all, I think it comes down to the fact that we should decide what is
and isn't themable.  And then work up the methods for doing themes.
Just so we don't kill ourselves trying to do `everything', when a few small
things will do.