[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 > 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:


 > > 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: