Re: Menu package, user updates, include (Was: KDE/SEUL)
Ah, sorry, I see I should have been more precise in my wording (once
again :( )
joost witteveen writes:
> > 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.
>
> What "menu files" do you mean?
[...]
> Or do you mean "menu- generated files", like system.fvwm2rc etc.
Yes, these ones. But AFAIK, system.fvwm2rc doesn't get generated by
menu. It rather includes menudefs.hook, which is the one to be
generated.
> Also in that case you are wrong, as update-menu only runs the
> scripts in ~/.menu-method, and not the ones in /etc/menu-method/.
[it seems you forgot "iff ~/.menu-methods/ exists" in that sentence]
[Note: the manpage I have documents "~/menu-methods" without a dot]
> So the user can choose what scripts to re-run and what not.
Ah, I understand the user can use symlinks to select that. Right...
But unless the user writes its own (fvwm2-, if it is the only relevant
wm) method himself, the menu-generated items in .fvwm2/menudefs.hook
WILL still mostly duplicate /etc/X11/fvwm2/menudefs.hook.
With 100 users doing that on a system (seems reasonable ?), 10 to 15Kb
per menudefs.hook, that will give 1 to 1.5Mb, most of which will be
wasted. Maybe that's not so much space, but... that's stuff that gets
backed up...
> > 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.
>
> Unfortunately, that is not possible. At least not with something that
> is as complex as generating menufiles for _all_ available Window-Managers
> and even www stuff. Some of those wm's want first the submenus, then the
> rest, some what it the other way around.
Yes, it may not be menu's role to try to do such things. It would
rather be the menu-method that should do that, but I don't know
whether the current formalism for menu-methods is powerful enough for
this (never had to use it), but probably you can tell.
What I meant here is that menu should (if it doesn't already) allow
for such a behaviour when possible.
> I'd have to parse those file, that
> all have completely different structures, to see where to add/remove a
> line. And, still, I'd have to parse the whole file (no, the world is
> bigger than just fvwm2. That's about the only one that can even read in
> extra files (like #include) in it's system.fvwm2rc, but also here it's
> really difficult to build it the way you seem to think is easy).
Sorry, but I didn't suggest that the method should modify any file.
What I was suggesting is to generate, in the user's menudefs.hook,
only the menus that need to be overriden there. As an example, if the
user has only an entry in Games/Arcade in its .menu/ dir, then the
menudefs.hook will look like:
====
# Automatically generated file. Do not edit (see /usr/doc/menu/README)
DestroyMenu "/Debian/Games/Arcade"
AddToMenu "/Debian/Games/Arcade" "Arcade" Title
+...
[...]
+...
====
That doesn't involve modifing any file or copy of file, but IMHO just
some additionnal testing to decide when to generate a menu entry in
that file. Yes, i think it could be quite easy.
I would now suggest even a step further: if we can detect that all
entries (as defined in .menu/) in a specific menu refer to *new* menu
items only, we even don't have to destroy the menu at all, just:
====
AddToMenu "/Debian/Games/Arcade" ...
AddToMenu "/Debian/Games/Arcade" ...
====
But I'm not sure we will gain much there.
> > 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.
>
[...]
> Actually, I think that even fvmw2 (the
> only one that can even do what you want) would slow down on startup
> significantly if you start to put every submenu (there are _many_!) in
> a different file. All those different submenu-files have to be read
> on _every_ startup. Not very good.
Note that I didn't suggest to have each submenu in a file, but just to
keep a set of timestamps. Maybe a single file would do that:
====
Debian/Apps:<that-date>
Debian/Games:<this-other-date>
[...]
====
> > I think of using something like menu files with "needs=login-shell",
> > and bash/tcsh/whatever providing methods to handle this.
>
> This I don't quite understand. Would the "login-shell" ask for a passwd?
> If so, how does a not-yet-logged-on user specify that he wants to
> actually run that menuentry?
"login-shell"-aware methods would just generated a file to be sourced
at the appropriate time from the shell's startup file. This generate
file would contain commands to run (like "update-menus -u"), or global
variables settings (think of CVSROOT, for example. This one would be
set in a local file; LESSCHARSET may be a good candidate too)
> > 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.
>
> More like it's better to make sure the programs run properly without
> the environment vars. Setting all those environment vars in /etc/profile
> (or wherever) takes time, and if 1000 packages start to do this, I
> will not be able to logon any more on my system.
> (that is, if 1000 packages do it properly, i.e. in their own file.).
I didn't tell all packages would configure themselves like that. It
would just be a convenience, allowing to integrate such packages in
Debian without needing to patch them to enforce our policy into them,
maybe confusing users migrating to/from another platform, or having to
use the same software on different platforms for some reason.
BTW, I hope newer menu-aware system (kde, gnome and such) will be, as
fvwm2, capable of what I try to expose. If they are not, that's worth
a wish report, so that adding support for this stuff in menu gets
useful ;)
--
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: