Re: Bug#90867: Menu is more important than it would seem

[Erik Steffl <steffl@bigfoot.com>]

Julian Gilbey wrote:
> 
> On Mon, Mar 26, 2001 at 12:56:11PM +0100, Jules Bean wrote:
> > > >From my work with fvwm, the primary issue seems to be that if every
> > > time a menu is requested, the window manager needs to determine
> > > whether the menu has changed, there is a significant performance hit.
> >
> > If that hit can be reduced to a single call to stat() or fstat() (and
> > I can't see why it can't) then I can't believe that amounts to much of
> > a performance hit.
> >
> > Of course, there's a performance hit in the event that the menu
> > actually has changed, but that seems acceptable to me.
> 
> At the moment, the menus are called using the standard fvwm
> configuration file system.  While this is possible (and desirable), it
> would mean rewriting some low-level source code to provide for this
> possibility.  It may have already been included in version 2.4 (yet to
> be released, AFAIK), but if not, perhaps it should be submitted
> upstream as a wishlist item?

  fvwm supports dynamic menus, there are examples of having e.g. content
of a directory as a submenu etc... it's just that current fvwm package
is designed so that the menu is read once in the beginning. nothing
prevents us (somebody:-) to change it so that menu definition is
periodically checked or that update-menu does something that causes fvwm
to reread the menu... (this might get messy, I guess it could get
implemented by menu methods...)

  of course, it should be solved for all (most, I know, some do not have
menus:-) window managers, not for fvwm only.

	erik