Subject: Menus as a module ?

From: Matthias Clasen <[email-masked]>
Date: Thu, 21 Jan 1999 10:06:00 +0100

I promised not to send any more patches before 2.2, but
here is an idea which i had some days ago. I just wasn't
courageous enough to try to implement it...

The idea is to move the whole menu code to a module. The
impetus for doing so would be not so much memory consumption
(exept for the few people who never use menus), but rather
to allow alternate implementation. I was thinking of an
implementation using gtk-menus; to improve fvwms integration
in a certain gtk-based desktop.

Has this idea been considered and rejected ? Would it be possible
at all ? 

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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, 21 Jan 1999 10:21:34 +0100

> Has this idea been considered and rejected ? Would it be possible

Considered yes, but not seriously. A *very* big problem is that
menus and functions share the same code. There is no difference
between a function and a menu at least as is how they are
stored internally. I'd love to reimplement this bit as it wastes
a lot of RAM for function entries (e.g. why should a function
item have a font or a menu style?).

Another thing to consider is that this would force *every* single
fvwm user to rewrite his config file.

Any ideas?

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 21 Jan 1999 11:51:04 +0100

> fvwm user to rewrite his config file.

Yes, the problem of config file syntax was one I had already
considered. Perhaps one would have to make the menu-modules 
"special", you could start at most one of them and would
have to register them in a special way (MenuModule FvwmDefaultMenu ???)
Then Fvwm could treat the config lines dealing with menus 
specially and send them to the menu-module. Just an idea.

Matthias

---

From: Richard Lister <[email-masked]>
Date: Thu, 21 Jan 1999 11:25:40 -0500

On Thu, 21 Jan 1999 10:06:00 +0100
Matthias Clasen <[email-masked]> 

Matthias

I gave quite a lot of thought to this idea quite some time ago. I wanted
to make some menu code improvements and decided the way to go was to
write a module. Then I decided to use an existing toolkit. I tried
several things. If I remember correctly (this was quite a long time
ago) I tried a Tcl/Tk menu using FvwmPipe (trivial implementation),
a TkPerl/FvwmPerl module, and a gtk module. It was all pretty easy
to code, but the problem was speed. Running on a P200/64Mb it was
just annoyingly slow popping up a menu on a mouse click. Part of this
is the wait to load a whole toolkit, part is the overhead of starting
a new process. I decided to try ripping the Xlib menu code out of
fvwm and wrapping it in a module. Then I took a look at the menu code
and abandoned the idea :-)

So my conclusion is that if people want to write a range of modules
to implement different kinds of menus, then cool, go ahead. I may even
try the gtk module again myself sometime. But we should leave in the
fast builtin menu code for people without supercomputers :-)

Cheers
Ric

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

---

From: Danek Duvall <[email-masked]>
Date: Thu, 21 Jan 1999 09:18:09 -0800

On Thu, Jan 21, 1999 at 11:25:40AM -0500, Richard Lister wrote:

> [...]

I know this has come up several times before, but it's always struck me
that the right way to do this sort of thing when speed is critical is as a
shared object.

The concensus in the past about shared libraries has generally been, `Yeah,
that may be the right way to do it, but it would limit the number of
platforms we can run on, and none of us really knows how to do it,' etc.

Zsh does a pretty good job of accommodating both sides of the fence.  If
you can use shared objects, it's configure script figures that out and does
it.  Otherwise, it just loads in all the modules statically.  Sure, it
increases the size of the binary, but in the case of standard menus
(probably the only menu system that *must* be included statically, and
possibly the only menu system that actually ships with fvwm), it's there
now anyway.

If someone were to get this working, it could probably also be used for
modular decorations, as has also been suggested before.

Anyway, since fvwm is now in pretty active development again, it wouldn't
necessarily be a bad thing if someone wanted to try it, starting out with
the easy case -- anything that supports dlopen() and friends (Linux,
Solaris, others?) and expanding it as time goes by.  An experimental option
that you have to explicitly turn on if you want to use.

If no one else wants to try, this may be the impetus I actually need to
start coding for fvwm.  Work should calm down somewhat in a week or two,
and I might actually have time.  (He he.  I shouldn't make jokes so early
in the morning. ;-)

Danek

---

From: [email-masked] (Paul D. Smith)
Date: 21 Jan 1999 12:22:49 -0500

%% Richard Lister <[email-masked]> writes:

  rl> I gave quite a lot of thought to this idea quite some time ago. I
  rl> wanted to make some menu code improvements and decided the way to
  rl> go was to write a module. Then I decided to use an existing
  rl> toolkit. I tried several things. If I remember correctly (this was
  rl> quite a long time ago) I tried a Tcl/Tk menu using FvwmPipe
  rl> (trivial implementation), a TkPerl/FvwmPerl module, and a gtk
  rl> module. It was all pretty easy to code, but the problem was
  rl> speed. Running on a P200/64Mb it was just annoyingly slow popping
  rl> up a menu on a mouse click. Part of this is the wait to load a
  rl> whole toolkit, part is the overhead of starting a new process. I
  rl> decided to try ripping the Xlib menu code out of fvwm and wrapping
  rl> it in a module. Then I took a look at the menu code and abandoned
  rl> the idea :-)

Dominik has done a lot of work with menus, so it's probably better.

Anyway, I think a module for popping menus should be written to be
invoked at init time and constantly running (at least as an option).  It
could then get requests from fvwm2 at runtime and avoid the overhead of
starting a process for each menu popup.

  rl> So my conclusion is that if people want to write a range of modules
  rl> to implement different kinds of menus, then cool, go ahead. I may even
  rl> try the gtk module again myself sometime. But we should leave in the
  rl> fast builtin menu code for people without supercomputers :-)

Or even those of us who don't want the fancy stuff (why not use
Enlightenment if that's what you want)?

I agree 100%.  I still use the builtin windowlist (I remember when it
got removed briefly, and I yelled along with others) even on my new
P450 (well, actually, I just got it Tuesday and I haven't gotten Linux
installed on it yet, but when I do I'm still going to use the builtin
windowlist :).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Richard Lister <[email-masked]>
Date: Thu, 21 Jan 1999 12:34:28 -0500

On 21 Jan 1999 12:22:49 -0500
[email-masked] (Paul D. Smith) 
> starting a process for each menu popup.

Yes, I thought about that as well. A little menu daemon that
sits there and fields requests to pop up menus. I can't remember
if I attempted an implementation ... I'll have a dig around my
vast repository of old abandoned code :-)

> installed on it yet, but when I do I'm still going to use the builtin

I agree with this sentiment.

Ric

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 21 Jan 1999 22:13:00 +0100

> fast builtin menu code for people without supercomputers :-)

This may be a misunderstanding of what I meant.  I can
well imagine speed problems if a module is started every time
I popup a menu. My idea was to have the menu-drawing-module
hang around all the time, having pre-built the menus from
the configuration info, and just send an "Pop up menu blah"
command from fvwm to the module if a menu is to be popped up.
The module would then do its thing and send the selected item 
back for execution to fvwm. I would expect such a setup to
be somewhat slower than builtin menus, but not terribly slow.