Re: Install-*-menu policy
On Thu, 7 Nov 1996, joost witteveen wrote:
> 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?
yes, the *.menu files.
The reason for pre-processing them is to build menu definitions which
can be passed to the WM menu builders - each package installs only a
single .menu file which contains one or more menu entries. They all
have to be gathered up, and sorted into menu type (application, games,
etc) before the menus can be built.
so, first gen-menu needs to figure out what menus need to be built, then
it has to build the menu structures, and then it feeds those structures
into the menu builders for each menu system/window manager.
> > 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.
it could even be set up so that it's not hard coded to use an xterm, but
allow each sysadmin (or user) to choose whether they prefer xterm or rxvt
or whatever.
> > 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?
no, but by sequentially building menus for applications, graphics, net,
and so on, you have built all the menus. not terribly useful in isolation
but great when called repeatedly :-)
> > 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).
install-fvwm2-menu wasn't around when i did this. if it had been
available, i almost certainly would have used it.
In the meantime, i had my own .fvwm2rc file and a fvwm2rc directory
containing an awk script, a source input file listing the machines i
needed to login to, and a Makefile to generate xterms.fvwm which was
Read by ~/.fvwm2rc.
> 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.
no, in what i was proposing, individual packages shouldn't call
gen-menu. generating the menus could be a significant task on a fully
installed machine. The package's repsonsibility is over once it has
registered its menus in the install menu database.
> 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).
yes, you have a very good point there.
my main concern was making sure that when a new window manager was
installed it had ALL applications available in it's menu, not just
those which were installed AFTER it was installed. This is really only
possible if you keep a database of what menu entries to make.
I think the two methods can be merged though...they're complementary,
not competing. If install-menu not only updates the menu but also
updates a menu-entry database then that kills two birds with one stone.
Then a gen-menu script could be called only when a new window manager is
installed.
> > 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.
two main things:
- ability to install a new WM and have all its menus automatically
generated and up-to-date.
- flexibility. we're not just limited to the menus which are hard coded
into install-menu. Not only the menu entries, but the menus (and
submenus) themselves are fully configurable
Craig
--
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: