Re: Install-*-menu policy
> another method of doing it which might prove more robust is to
> have an extra (optional) control file called "package.menu".
> This gets installed in /var/lib/dpkg/info/ along with
> package.{list,prerm,postrm,preinst,postinst}
Yes, that's an equivalent option.
> e.g. fvwm95 would provide a gen-menu.fvwm95 script, and register it with
> gen-menu.
That's already what I proposed: the install-menu script runs
all scripts/symlinks available in /etc/menu-methods/*, and there
the gen-menu scripts you proposed should reside.
(I mentioned this in my original mail to debian-devel, and it's
in the scripts in the "menu" package).
>
> gen-menu could be run from the command line, be an extra option in
> dselect's menu (between Config & Remove), run from cron, etc. With
> no arguments it would generate all menus for all window managers/menu
> systems.
OK, that's somewhat different from the way I saw it.
What I had in mind is that the package's postinst takes care of
creating the total menu once, and then, when an application that
wants to add one menu to the tree, /etc/menu-methods/manager-script is
called to update this one entry.
> The main gen-menu script should provide the input to the package
> specific scripts, pre-processing the input files as required.
What input files? The ones in /var/lib/dpkg/info/*.menu? But if you
want to pre-process them, why not make them the "right" format to
begin with?
> It reads
> all of the relevant input files and feeds specific types of menus
> (e.g. Applications, Games, Shells) into the sub scripts. It should also
> drop "type=X" menu items for text menus, and convert "type=VC" items to
> run in an xterm for WM menus.
That may indeed be usefull.
> other things it should be able to do include:
>
> generate a specific type of menu (e.g. Applications), optionally for
> a specific window manager (e.g. fvwm2). This is the key function,
> almost everything else can be built from this.
Could you tell me why anyone would want to create only Applications,
or only Applications/Graphics?
> easily customising the shells menu would be particularly useful to me
> - i have about a dozen machines i need to rlogin into (usually several
> times a day) so i have set up an XTerms menu in fvwm2 & fwwm95 which
> contains several lines like "XTerm -T hostname -e rlogin hostname" -
> whenever i need to login to one of those machines, i just pick it off
> the menu list.
But that what I proposed made that prity easy too:
install-menu X xterm-hostname .... "XTerm -T hostname -e rlogin hostname"
(and, if you only want to add the line to fvwm2, the old install-fvwm2-menu
could have done it just as easly).
I don't see what all of this extra overhead is going to buy us.
One down side I see, however, is, when a package wants to
register a menu-entry, it has to call (eventuall) gen-menu, and
this will then rebuild the whole database _from scratch_ (if
I get you correctly) for every window-manager.
The way I proposed it, install-menu will just ask the /etc/menu-methods/*
scripts to add this one menu entry (giving the menu entry as parameters
to the script), and only one entry gets updated (in the case of fvwm2,
adding just one entry costs virtually no time -- but rebuilding the
whole database from scratch costs a lot of time).
> this idea obviously needs more work. I know what i want but am finding
> it difficult to translate my conceptual model into words.
Well, I think I understand the concept quite well -- it's just I don't
really know what all this complexity buys us.
--
joost witteveen
joost@rulcmc.leidenuniv.nl
joostje@debian.org
--
Use Debian/GNU Linux!
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: