Re: Menu package, user updates, include (Was: KDE/SEUL)
> > 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.
OK, menudefs.hook, whatever you want. Please, remember that fvwm2
is in a small minority that can actually do an "#include" statement,
and thus allows install-menu to generate a "menudefs.hook" file.
For the majority of wm's, install-menu generates the system.*rc file.
> > 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]
Yes
> [Note: the manpage I have documents "~/menu-methods" without a dot]
Thanks, fixed.
[..]
> What I was suggesting is to generate, in the user's menudefs.hook,
[..]
> DestroyMenu "/Debian/Games/Arcade"
> AddToMenu "/Debian/Games/Arcade" "Arcade" Title
OK, this is possible, and looks like desirable. There is ofcource this
one drawback: it only works for fvwm2. Maybe also for some others, but
not many.
This was actually how the original system worked. It got abandoned because
it only works for fvwm2, and we wanted the menu system to be something
more general.
But you are right in thinking that it should be easy to add a rather
bad hack to install-menu to add this functionality to it.
First some words on why the hack isn't all that nice at all:
The menuentry files are read by update-menus (only once). This program
doesn't know anything at all about window managers (or www or whatever),
it just generates a big array with all the menuentries in it (converted
to new format, BTW), and starts executing the menu-methods, piping the
big array of data to the menu-methods via stdin.
As update-menus will never know that the fvwm2 menu-method doesn't need
the menuentry files outside ~/.menu (that is, if ran by a user, and
~/.menu-methods/fvwm2 doesn't exist), it will happily pass all the
menuentryfiles to the fvwm2 menu-method. This will not be possible to change.
However, to enable better error-reporting (new in version 1.4 I think),
update-menus doesn't just pipe the menuentry data to the menu-methods' stdin,
but also the filenames. The actual data that update-menus writes to stdout is:
[..]
!F /usr/lib/menu/thrust
command="/usr/games/thrust" needs="vc" section="Games/Arcade" title="Thrust"
command="/usr/games/xthrust" needs="x11" section="Games/Arcade" title="Thrust"
!F /usr/lib/menu/xonix-jahu
command="xonix-jahu" needs="x11" section="Games/Arcade" title="JahuSoft Xonix"
[..]
So, it will be possible for the fvwm2 menu-method to check for the
filenames, and stop reading (or at least processing) menuentries upon
reading eighter "!F /etc" or "! /usr". It should be possible to
add an option like
useronlyuserfiles="Yes"
that will turn on this behaviour. But to me this looks like a rather
bad hack, that will probably always do the right thing.
I'll probably add it somewhere in the future (think days/weeks).
> 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,
This I don't agree with. To be able to detect that a menuentry is new,
we would eighter have to have a cache file that contains all menuentries,
or isntall-menus would have to continue reading all the extra input
that update-menus gives it (about the /usr etc menuentryfiles). The
latter will take a lot of time, and the former is way to much work
for *just* fvwm2 (and will probably also take some time). Note that
I don't mind spending time on improving menu, but I do want to make
sure this time is spent to improve all wm's not just fvwm2.
> 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>
Ah, another file. Another cache method. The caching of timestamps, menuentry
data, etc, has already been tried. It was the first thing I thought of,
and it seemed to work reasonably on my system. But apparently others
didn't quite run the various scripts etc in exactly the same order as I
did, and it created many problems on their systems. It wasn't actually
me who started arguing for the removal of those cache files, it were
others. But once they convinced me, I really saw that this new cache-free
way was The Right Way. It is so much easier, created so much less problems,
even on my system (and certainly on the systems of others), and it wasn't
even all that much slower.
>
> > > 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)
Still I don't see. Suppose I create a package "joosteto.deb", that creates
a file "/usr/lib/menu/joosteto" that contains:
?package(joosteto):needs=login-shell command="rm -rf ~" title="tryme"
What happens? When is the user able to select this useful command?
Who (what command) adds it to my ~/.bashrc? I'm now mostly thinking
of users that _don't_ run update-menus themselves, but if you want
to propose this to set env. vars that will be needed by other programmes,
then the "needs=login-shell" stuff should also work for users that
do not run update-menus themselves (or have ~/.menu dirs).
> > > 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.
I know you don't want all packages to configure themselves like that.
But that is probably exactly the problem: they will :). Or rather,
not all of them, but too many. Opening 100 files on startup will already
be sufficiently noticable, I guess. As we only can setup policy to
eighter allow adding files to a directory /etc/profile.dir (or whatever
directory), or disallow it, it seems the best bet to simply disallow it.
Note that I didn't advocate current the policy on that point before,
and I'm now only echoing what I remember what others said when I started
suggesting adding stuff to /etc/profile.
--
joost witteveen, joostje@debian.org
Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).
--
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: