Subject: FVWM: The future of FVWM (was Re: Starting fvwm2 development)

From: "Charles Hines" <[email-masked]>
Date: Mon, 18 May 1998 16:27:12 -0400 (EDT)

>>>>> "GJGG" == German Jose Gomez Garcia <[email-masked]> writes:

GJGG> On Mon, 18 May 1998, Steve Robbins wrote:

>> On Mon, 18 May 1998, German Jose Gomez Garcia wrote:
>>
>> >    Well, after a long long time without having seen any improvements
>> > in the great fvwm2 I have decide to take up the task, but it will have
>> > a cost, I have reindented the full source (using indent -kr -bli0 -bl), so
>> > patches are not a good way to distribute it (last was greater than the code
>> > itself :).
>> >    My question is simple, is anybody working on fvwm2 now?
>>
>> Yes: Charles Hines.
>>
>> > if yes what are his goals?.
>>
>> My advice: check the archives of this list for his posts.
>>
>> > If nobody answer, I will start a new series in the fvwm2
>> > development (maybe something like 2.0.46.x :), and start to put patched
>> > versions at Adam Kopatz site, I would include most of the patches most
>> > commonly used (as FvwmPager Ballons, fvwmpython interface, etc...), so
>> > I asked the authors of this patches to contact me (I'm not going to repeat
>> > already done code :)
>>
>> Well, Charles Hines is actively maintaining fvwm2.

An admittedly lethargic active development though...

>> I'm sure your intentions are good; however, a post like yours might
>> seem like an attempt at a "hostile takeover" to some people.  I
>> wonder if a more cooperative approach would work better.

Yes, that original post aggrivated me quite a bit at first, but then I
realized that I was really more upset with myself for not having
enough time to do the work on fvwm that I really wanted to.  So I've
come to a decision, which I'll outline below...

>> That said, I've been wishing for a long time that the speed of development
>> be increased.  I've considered proposing a "linux style" dual tree: one
>> stable branch and in parallel, a rapid development branch.  Charles Hines'
>> develops in the "cathedral" style, well-suited to maintaining a stable
>> branch.  The only reason I haven't proposed a dual-tree development to the
>> list is that it would need someone with a lot of time to manage the
>> development branch, and I don't have this amount of time.

I've had many people write me (both on the mailing list and directly)
citing that same cathedral/bazaar paper:

  http://earthspace.net/~esr/writings/cathedral-bazaar/cathedral-bazaar.html

It's not that I was deliberately choosing the "cathedral" method of
development, but I just didn't have enough time to truly do a more
frequent development cycle.  I really wanted to (eventually) get a
good 2.1.0 version out, and then start dual stable & development
paths.  As you can see, I haven't quite made it there yet.

>> Whatever you do, please please *please* use the autoconfigured version of
>> fvwm 2.0.46, which you can find at:
>>
>> http://www.cs.mcgill.ca/~stever/software/fvwm/

GJGG>   Sorry if it seems so, but I only want to cooperate with you in
GJGG> the development of such a nice wm, but I wasn't subscribed to
GJGG> fvwm-workers list, so don't now anything about active
GJGG> development, I by no means want to seem a "hostile-taker",

I was hoping that was the case.

GJGG> on the contrary, but as the WEB Page doesn't get updated for a long
GJGG> time,

Several months between updates has been the norm for me for the past
couple of years, unfortunately, so I'm not sure that I would consider
5 months to be a "long" time considering that...

GJGG> I just think fvwm2 developer team has switched over to scwm, I
GJGG> know now that things are not so bad, many people are still
GJGG> working on it!, I would apply the changes to your version (the
GJGG> one with autoconf), and submit it to Adam Kopaz to be include in
GJGG> his page.

Please hold off on putting another fvwm pseudo-distribution out
there.  It really confuses things...

GJGG>   Any more info appreciated (mainly more patches I must include)

Ok, more info (and the decision I mentioned above):

As of today I'm giving up being fvwm's maintainer.  Unfortunately I've
finially decided to face facts and accept that I don't currently have
anywhere near the amount of time to devote to fvwm that it should
probably have.  It was a painful decision, but probably for the best
(besides, I guess I can still submit ideas and patches periodically).

I wish to thank everyone that has helped out, submitted patches &
ideas, or just plain used fvwm over the years that I've been involved
with it, especially the folks on the mailing lists.

In the not so distant past I spoke offline with Brady Montz, and I
asked if he might like to take over maintainership from me when I was
ready to give it up, as I felt that he was one of a few good
candidates from the mailing lists and that he might have more time to
devote that I do.  At the time he said he was interested.  After I
made my decision this morning, I wrote him again to ask if he was
still interested, but unforutunately haven't heard back from him yet.
I really wanted to hear back from Brady first before I wrote anything
to the mailing lists, but decided that I should speak up before too
many messages flew back and forth without my input (hope you don't
mind, Brady).  In the event that Brady has changed his mind and
doesn't want to (or can't) take over, I'm sure we'll be able to find
someone else.  I'll be sure and announce when this is all decided.

So, what's next?  Well, I'll hand over my current development snapshot
to the next maintainer after that's settled and they can start with
that or just toss it out and start with 2.0.46, whichever works out
better for them.  Then we'll see where they drive it...

My parting thoughts on the future of fvwm:

        - Please try and keep the base code lightweight, standalone
          (ie - minimal external code usage beyond Xpm), and as
          generic as possible.  Granted, it still needs more cleanup.
        - The configuration language definitely needs some more
          improvement, but I don't think I quite agree with adding an
          extension language like Guile, Tcl, Python, etc as I think
          they are all overkill.  Just my 2 cents on the subject since
          I was out of town and unable to respond when this thread
          came up again recently.
        - The current module interface needs more work as well, and
          should probably be encapsulated in another little lib to be
          shared amongst the modules as much as possible.
        - Dynamically loaded modules that use hooks into existing fvwm
          routines to make for tighter integration is probably worth
          looking into.  That'd probably help with modules being able
          to muck with decorations, multiple language interpreters,
          etc.

I could probably put down more, but I guess the TO-DO list and the
notes I keep in my local development ChangeLog already cover all this
and more...

That's enough rambling for now I guess.  Please be kind and
understanding to the next maintainer.  It's been fun.

Thanks,
Chuck

--
*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]

         "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" 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: 18 May 1998 15:57:29 -0500

>>>>> "CH" == Charles Hines <[email-masked]> writes:

CH> As of today I'm giving up being fvwm's maintainer.

Thanks, Chuck.  I know everyone appreciates what you've done, and I
personally have enjoyed coordinating things with you.  I do hope you'll
stick around and continue to provide guidance.

CH> So, what's next?  Well, I'll hand over my current development snapshot
CH> to the next maintainer after that's settled and they can start with
CH> that or just toss it out and start with 2.0.46, whichever works out
CH> better for them.  Then we'll see where they drive it...

Just to note, I will continue to supply mailing list, FTP and web service
for as long as it is wanted.  I can also provide a CVS tree (with anonymous
access and CVSweb) and anonymous rsync access.  I still don't have the time
to coordinate development, though.

 - J<

---

From: "Randy J. Ray" <[email-masked]>
Date: Mon, 18 May 1998 15:50:00 -0700 (PDT)

First off, I'd like to second Jason's sentiments and thank Chuck for all the
work he's done so far. he was particularly helpful with me a while back as I
muddled through the module API docs while writing the X11::Fvwm module for
Perl5.

I concur that Brady, if he has the time, is the best choice for picking up the
Fvwm mantle. However, if brady cannot do it, I will offer a slice of my 
(admittedly limited) spare time. I'd prefer it went to Brady, though.

Randy
-- 
Beware the sarcophogi being offered as "gratefully vacant".

[email-masked]

---

From: Brady Montz <[email-masked]>
Date: 18 May 1998 16:44:43 -0700

> someone else.  I'll be sure and announce when this is all decided.

I've had to think about this a bit since it's quite a time commitment, but I
think I'm willing to do it. I'd want to look into a way of splitting the
development between among a small group of people, perhaps with a public CVS
source tree with all checkins to be approved by me. Does anyone have
suggestions along this line?

-- 
 Brady Montz
 [email-masked]

---

From: German Jose Gomez Garcia <[email-masked]>
Date: Tue, 19 May 1998 02:48:08 +0200 (METDST)

Well, I think you have take the right way, your work in fvwm2
has been really fantastic, but GPL makes these things easier :)
I hope Brady will take over it, and I hope he'd choose a more open 
development mode, just because (IMHO) it is the only way to have a chance
against wm like WindowMaker, AfterStep, or Enlightment; I really have
no idea of what the current state of your fvwm2 devlopment tree is, so
may be I am wrong (I hope so :)

	And about my patch, I've almost finished, and after great work
I have applied it to smr-2.0.46.4 version of fvwm (the one with the 
autoconf), I will post a snapshot tomorrow (Tuesday GMT), beacuse many
people have misunderstand what the patch is made for, I hope you like
it and decide to include it in the main tree. Another important thing
may be to choose a good indentation mode (I just think currently (2.0.46)
indentation is a bit chaotic) because if you choose a baazar approach
it would be too late :)

	Well, after all, things are changing in the fvwm2 scene, and
I can just wait to the day fvwm2 rulez again!

	Thanks Charles for all your good work (I hope you'd continue
active development, your experience is just too valued to be lost),
thanks!

<>-------------------------------------+-----------------------------------<>
   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"
<>-------------------------------------+-----------------------------------<>

On Mon, 18 May 1998, Charles Hines wrote:

.......	just too many things ...... :)

---

From: Jason L Tibbitts III <[email-masked]>
Date: 18 May 1998 20:27:49 -0500

>>>>> "BM" == Brady Montz <[email-masked]> writes:

BM> I'd want to look into a way of splitting the development between among
BM> a small group of people, perhaps with a public CVS source tree with all
BM> checkins to be approved by me.

Well, I'm happy to run a CVS tree (because I'm already running one for
another project).  There's no way to do 'approved' checkins other than
having folks mail you patches for you to commit.  CVS is really quite
useful, though.

BTW, it's probably best to hammer out any details on fvwm-workers and let
the main list know what the result is and what they can expect.  I've set
Reply-To: appropriately.

 - J<

---

From: Andrew Veliath <[email-masked]>
Date: Tue, 19 May 1998 01:33:11 -0300

.........----------------==================----
..--==-  Mon, 18 May 1998 16:27:12 -0400 (EDT),
..--==-  Charles Hines (CH) mentioned (truncated version):

 CH)  As of today I'm giving up being fvwm's maintainer.
 CH)  Unfortunately I've finially decided to face facts and accept
 CH)  that I don't currently have anywhere near the amount of time to
 CH)  devote to fvwm that it should probably have.  It was a painful
 CH)  decision, but probably for the best (besides, I guess I can
 CH)  still submit ideas and patches periodically).

 CH)  That's enough rambling for now I guess.  Please be kind and
 CH)  understanding to the next maintainer.  It's been fun.

 CH)  Thanks, Chuck

..
 ~~~~~~~~~================-------------......---

Chuck,

It's sad to hear that you have decided to leave as fvwm2 maintainer.
It would be nice if Brady does takeover development, and Jason
mentioning CVS does sound like a good idea.  I just hope fvwm2 doesn't
splinter (at least not with the same name fvwm).

Please do drop in occasionally though so we don't suffer from
withdrawal symptoms :-).

Best regards,
Andrew

--

        Andrew Veliath
	[email-masked], [email-masked]

---

From: James_Kingdon <[email-masked]>
Date: Tue, 19 May 1998 09:12:08 +0100

Hi,

I guess there'll be too many of these messages, but I wanted to say
thankyou to Chuck for all his efforts on fvwm - they are much
appreciated!

Regards,
James.

-- 
James Kingdon
Parallel Applications Centre
2 Venture Road, Chilworth
Southampton, SO16 7NP, UK

tel: +44 1703 760834
fax: +44 1703 760833

mailto:[email-masked]
http://www.pac.soton.ac.uk/
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Albrecht Kadlec <[email-masked]>
Date: 19 May 1998 13:24:59 +0200

> > someone else.  I'll be sure and announce when this is all decided.

I'm sorry that I've been harsh to chuck in late '96, when I wanted to speed
up development. He wasn't ready to pass on the torch, then and he still has
not enough time to review all that patches and still do own modifications.

> suggestions along this line?

yes: try do a complete split & reindentation of the code as fast as
possible, so that work can begin.

I'd like to have a more methodically split: e.g: menu code was spilled over
several files in 2.0.43-45, don't know of .46

Indentation is pretty bad, since people had to keep the patches small
(diff -w is no good for indentation)

To get rid of the patches-backlog, you should get development up & running
as fast as possible, with a quick brushed up release as a basis for all
those patches. (don't try to first include gazillions of patches that were
for 2.0.43 to .45) 

Then you should ask the authors of the most important patches to redo them
for that release. Then you can quickly select / apply those.
I don't think they'll be offended, if they have to redo a patch once and
then have it included.
Many of these patches have been re-done several times, because they didn't
make it into .41, then they didn't make it into .42 and so on.

After this catchup on the patches backlog, most of the "I detected a bug in
2.0.46" -> "Yes it's been there since 2.0.39, use this workaround" traffic
on the lists should cease, leaving more time to fiddle with code.

Then we can focus on the unknown bugs and enhancements.

BTW:
we should still finish the discussion, wether we want

	1) a new language / languages ??
	2) export fvwm's data & special functionality
	3) reinvent the wheel while adding one feature after the other to
		the existing language (delay ?).
	
I already posted an idea to have fvwm-core without any language, but just a
bytecode interpreter (maybe with a callout for unknown opcodes).

The syntax-analyzer / semantic parser would be a standalone program
producing bytecode output, being piped to fvwm.
We could even have different ones.
Modules would also output bytecode -> no redundant syntax & semantic
checking.

The bytecode interpreter (i.e. most of current functions.c & builtins.c)
would be a shared library which can be unloaded (swapped out !), when all
configuration is done and no functions have been defined (minimal user).
We could even split the language into a startup config part (always
unloaded) and a dynamic executing part (functions)

this is all some sort of brainstorm, so don't hesitate to comment, ask for
elaboration, etc ...
I also hope you don't mind the intermixing of we / you. I tried to use "you"
for things only You (as the maintainer) can do, and "we" for things we can
do as patches, that can be included fairly easy, when there's a comon base
for patching. (2.0.46 ?, 2.0.46 autoconf, what versions else do exist now)

Maybe we can re-acquire some spin-offs or borrow / lift some code there ?
-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
Hi!  Darren's answering machine is broken.  This is his refrigerator.
Please speak very slowly, and I'll stick your message to myself with
one of these magnets.
				-- answering machine message
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Bob Woodside <[email-masked]>
Date: Wed, 20 May 1998 20:34:44 -0400 (EDT)

I'm very much saddened to hear that Chuck is having to hand
over custodianship of my Favorite Virtual Window Manager to a new
maintainer. I'm sorry that this brave and painful decision had to
be made. 

        I wish Brady the best of luck in his new role (as well as
in his upcoming doctoral exams).

        Chuck, I do hope your schedule will allow you to continue to
participate from time to time in the role of Guru Emeritus. Thanks for
your many contributions and your leadership over the past few years.

---

From: William Denton <[email-masked]>
Date: Wed, 20 May 1998 23:06:09 -0400 (EDT)

Hi,

I've been using FVWM for two years now, and like it more than any
other window manager I've tried.  Along with the others, I'd like to
thank Chuck for all his hard work, and wish good luck to Brady.

Bill
-- 
William Denton | Toronto, Canada | http://www.vex.net/~buff/ | Caveat lector.
		    "Let's keep the party polite."

---

From: Chris Siebenmann <[email-masked]>
Date: Thu, 28 May 1998 13:44:01 -0400

[I know, this is ten days old:]
| [...] just because (IMHO) it is the only way to have a chance
| against wm like WindowMaker, AfterStep, or Enlightment; [...]

 I don't think that fvwm2 should be considered to be competing with
other window managers. I would prefer to think of it as each window
manager having its own philosophy and goals, and one works to make the
window manager come as close to those goals as possible. Some people
may like the philosophy; some people may not. It would be wrong to add
things that go against the philosophy just to attract more users.

 I'm biased, of course, because I like fvwm2's current philosophy,
and I don't like the philosophy of other window managers (or I'd
probably be using one of them).

	- cks

---

From: [email-masked] (Paul D. Smith)
Date: 28 May 1998 14:36:52 -0400

%% Chris Siebenmann <[email-masked]> writes:

  cs>  I'm biased, of course, because I like fvwm2's current philosophy,
  cs> and I don't like the philosophy of other window managers (or I'd
  cs> probably be using one of them).

Hmm.  What _is_ fvwm2's current philosophy?

What are the others'?

Just curious... :)

-- 
-------------------------------------------------------------------------------
 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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Thu, 28 May 1998 15:02:19 -0400

> Hmm.  What _is_ fvwm2's current philosophy?

Well, I had the  same thought, but then I  re-read the  Description on
the fvwm2 man page and that satisfied me.

If  anything sets fvwm2  apart, its that its  small and  fast, and has
just the right amount of built-in features.

> Just curious... :)
> 
> --
>  Paul D. Smith <[email-masked]>

--
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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Bruce Stephens <[email-masked]>
Date: 29 May 1998 10:10:02 +0100

> just the right amount of built-in features.

Well, it also ought to be configurable to a significant extent,
consistent with it being small.  

One of the things which I find useful is that it's *documented*.  I
had a look at WindowMaker recently, but just couldn't get it to be
usable.  There is documentation, but it seems out of date.  I
understand there's an extra program that I could have got, which would
have made the configuration point and drool, but there was no clear
advice to do that.  So I'm back with my comfortable fvwm2 setup.

fvwm2's documentation and configuration may be a bit weighty, but it's
all there.

---

From: John Culleton <[email-masked]>
Date: Fri, 29 May 1998 08:14:17 -0400

> One of the things which I find useful is that it's *documented*.  I
...and it has some useful modules ready to go. I use two button bars and
a pager. I really can't live without the pager. I tried scwm which some
have touted as the "future" of fvwm. But I couldn't figure out how to
transfer my button bars & pager. Until someone gets around to providing
that level of functionality on the newer window managers I will stick
with fvwm. I would hope that the development comunity would not abandon
fvwm just yet. We need you!

-- 
John R. Culleton, Jr.  [email-masked]
Sykesville, MD 21784 U. S. A.
(410) 795-1159
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Eddy J. Gurney" <[email-masked]>
Date: Fri, 29 May 1998 09:39:09 -0400

On May 29 at  8:14, John Culleton wrote:
,--
| Bruce Stephens wrote:
| > Dan Espen <[email-masked]> writes:
| > > Well, I had the same thought, but then I re-read the Description on
| > > the fvwm2 man page and that satisfied me.
| >
| > > If anything sets fvwm2 apart, its that its small and fast, and has
| > > just the right amount of built-in features.
| >
| > Well, it also ought to be configurable to a significant extent,
| > consistent with it being small.
| >
| > One of the things which I find useful is that it's *documented*.  I
| >
| ...and it has some useful modules ready to go.
`--
Although I agree with everything that has been said (and note that `fvwm2'
is the most widely used window manager at our company by a huge margin,
thanks to a user-configurable "standard configuration" I came up with using
the wonders of FvwmM4), there are some things that I would like to see
addressed in future versions of `fvwm2':

 . It should support multi-headed displays without having to run multiple
   copies of itself. `vtwm' and other window managers can do it, `fvwm2'
   should do it as well.

 . Likewise, it would be nice if programs like FvwmButtons and FvwmPager
   could support multiple instantiations without having to run a separate
   copy for each button bar/pager/etc.

 . The idea of forking a new application to do auto-raise, window list,
   etc. seems totally silly to me. I would much rather have "dynamically"
   loadable routines linked in when I start `fvwm2' and see just a single
   process listed when I do a `ps': fvwm2. Not: fvwm2 (twice, once for each
   screen), FvwmAuto (twice, once for each screen), FvwmButtons
   (twice, one for each screen), FvwmPager (twice, once for each screen),
   etc. Not to mention all the memory wasted by having all these modules
   "separate". Although it is difficult to tell how much memory FvwmAuto
   is *really* using (due to shared libraries and such), my guess is that it
   is not insignificant:

   USER       PID %CPU %MEM   SZ  RSS TT       S    START  TIME COMMAND
   eddy      5954  0.2  1.2 2576 1424 console  S 09:17:17  0:00 FvwmAuto
   eddy      5955  0.1  1.2 2576 1424 console  S 09:17:17  0:00 FvwmAuto

   Seems kind of silly when a feature like "auto raise" is really only a
   a few K of code. I would much rather see this features somehow "dynamically
   linked" to `fvwm2' at run-time (adding that few K of code to `fvwm2's
   process space instead of forking a whole new process).

Just my thoughts!

Eddy

P.S. I've patched `fvwm2-2.0.46' to add some useful features:

     . Automatic pointer warp to transient windows (great for programs
       like Netscape that pop-up Find windows and such.) This would be
       a great "style" feature (i.e., WarpToTransients/NoWarpToTransients).

     . When placing a window (i.e., dragging around the "grid"), I have
       redefined the mouse buttons to work as follows:

       Button 1 = Place window (no change)
       Button 2 = Place window, but allow it to be resized (i.e., while
                  holding button 2, you can drag to the window borders and
                  resize it while it is being placed. Very useful). If you
                  don't use the "mmw" style menus, this works already.
                  If you use "mmw" style menus, you can see how this works
                  by holding down "shift" and using Button 1. Not sure why
                  this feature is tied to mmw-styled menus, but I'd rather
                  see it always mapped to button 2.
       Button 3 = Place window, but maximize its height (i.e., when you
                  click button 3, you select the top-left corner of the
                  window, but it is automatically resized so that it extends
                  all the way to the bottom of the screen. Great for xterms.)

     If there is any interest in these patches, let me know where to send
     them. I'd love to see them included in the next release of fvwm2.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Bruce Stephens <[email-masked]>
Date: 29 May 1998 16:14:26 +0100

>    copies of itself. `vtwm' and other window managers can do it, `fvwm2'

Yes, it ought to do this.  Actually, I thought it did, but I've never
been in a position to try.

>    copy for each button bar/pager/etc.

Why is this important?  Don't the multiple instantiations share most
of their memory?

>    etc. seems totally silly to me.

Yes, some features look silly as modules.  Dynamic loading is a good
idea, and nowadays it's reasonably doable.  Back in the old days (when
the modules were first introduced) dynamic loading was much more of a
nightmare, and I suspect that's why Robert didn't try to offer that as
a mechanism.  (Some things do make sense as separate processes,
though, in the absense of preemptive threading, which is difficult
with Xlib apparently.)

I'd like dynamic lowering too, to remove windows that I'm obviously
not interested in.

---

From: Brady Montz <[email-masked]>
Date: 29 May 1998 09:42:51 -0700

>      them. I'd love to see them included in the next release of fvwm2.

Send them to me.