Re: Menu package, user updates, include (Was: KDE/SEUL)
joost witteveen writes:
> For #2, "I don't like it that the user has to run update-menus every time
> the admin has installed a new package", the solution isn't all that
> simple (i.e., I'll have to actually do something).
Yeah, that's a problem.
> I see 2 ways to fix it:
>
> 1) (as discussed on the KDE list, and elsewhere)
> make update-menus parse /etc/passwd, read all user homedirs, and
> check if any user has ~/.menu or ~/.menu-method dirs. If so,
> parse them, and update the user "system.fvwmXXXrc" &c. files.
>
> 2) Add a flag (maybe "-u", update) that will (when run as UID != 0)
> cause update-menus to check the modification time of the most recent
> file in /usr/lib/menu (and others), and compare that with
> the mod time of ~/.menu-last-ran. If the system admin has recently
> modified /usr/lib/menu, only then update-menus will start the whole
> udating stuff, otherwise it will just do nothing. The idea then is
> that the user simply puts a "update-menus -u" in his ~/.bashrc.
> (of cource, after the run ~/.menu-last-ran will be touched)
The main disavantage of these 2 solutions is that the user-created
menu files will still, in most cases, duplicate most of the system
ones.
As an example, if I just want, as a user, to add a menu entry for a
program in say ~/bin/, I still have to recreate ALL menu entries.
I think that a best idea (theoretically at least), would be that the
user-generated files just override the relevant parts of the relevant
menus.
I don't really know about the other methods, but fvwm2 first reads the
system menu, the the user menu. If the user menu just overrides the
relevant parts, then we win most of the game.
What will still remain will be that if I add an entry in say
Games/Arcade, then the Games/Arcade still losts sync with the system
menu, but what we gain is that all others, untouched, menus, will be
in sync.
Then one of your proposals will still need to be used to update the
relevant files.
Going further, it would be nice if we could have update-menus run only
when the relevant menu has been modified on the system level, more
recently than on user level. That would signicantly reduce the CPU
load dedicated to menu-generation.
This could be achieved by using a set of one time-stamps per
(sub-)menu on system level, and one time-stamp per
user-level-generated (sub-)menu.
> So, personally I would be in favour of 2), but I do appreciate your
> views on this (or, maybe better options).
Although my last proposal would address the second drawback you
mentionned for your 1st solution, I would also be in favour of the
second one. It's not so hard to have the userrun this script.
I thought of inserting a call to "update-menu -u" or such in
/etc/profile, but it won't please tcsh users. Maybe some way of
registering commands to be run at login time could be used ?
I think of using something like menu files with "needs=login-shell",
and bash/tcsh/whatever providing methods to handle this. With a bit
of work, setting variables would work too, and we could then allow
programs to be globally configured using environment vars, which we
can't (and is AFAIK forbidden, maybe because we don't have such a
mechanism) for now.
--
Yann Dirson <ydirson@a2points.com> | Stop making M$-Bill richer & richer,
alt-email: <dirson@univ-mlv.fr> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: