On Fri, 2005-01-21 at 12:28 -0800, Jeremy C. Reed wrote:
> On Fri, 21 Jan 2005, Julio M. Merino Vidal wrote:
> 
> > Now say our Joe User changes the alternative in his personal
> > configuration:
> >
> > 	$ alternatives manual bin/vi /usr/pkg/bin/vim
> >
> > What will happen is that the vi wrapper will see his configuration
> > and vim will be executed.  But the manual page will still be pointing
> > to nvi.
> 
> Thanks for the further explanation. It now makes sense because this is to
> support individual's own alternatives too. I wonder if supporting per-user
> alternatives is overkill -- it is sort of like supporting per-user
> PKG_SYSCONFDIR configurations.

Well, individual configurations is just one case (and it's not really
hard to support; I'd even say "trivial" ;).  But the same problem can
arise if two different hosts sharing /usr/pkg decide to use different
alternatives.  Then, the wrapper could pick up what's preferred by
each host, but the manual page could be pointing to one of the two
packages only.  And I'd say that '.so' is even worse than symlinks
because you'd need to modify the contents of PREFIX (which may well be
read only).

> Can any of your new code be extended to handle creating menu databases for
> dynamically updating window manager menus? (I have code for this in an old
> PR.)

Hmm you are the second person to ask that ;)  But I don't think so,
at least I can't see how alternatives can help.

However, I think we can start supporting menus in an easy way,
following the menu specification published by freedesktop.org (and
being a "standard" that more and more people are starting to support,
I think this is the way to go).

It is fairly flexible.  You have a pool of menu entries in
share/applications, each one in its own .desktop file.  And then, you
construct the menu based on these files, either following the Categories
property in them or by using an external XML file that describes the
menu structure).

All we'd need to do to start this could be to bundle .desktop files for
the packages we want in menus, and we'd even feed back them to the
authors, I think.

GNOME and KDE support could come for free.  For other window managers,
we'd need a tool that does the same as the major desktop do (read the
.desktop files and construct the menu).  I don't know if there is any
such program already, but if it's not, I think it may not be that hard
to implement if we reuse some of the existing code.

FWIW, GNOME 2.10 will come with a library, gnome-menus, to manage all
this stuff.

But this is worth another thread ;)

Cheers,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/