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

Re: Changes to menu packgae



> A couple more things... I had brought up most of these before your trip,
> but I'll repeat them again:

I was afraid I was missing something...

> 
> Currently, menu entries for a package are not generated unless the package
> is in state "install ok installed".

I know, but I considered that as a BUG, and was gonna fix that anyway
(regardless of any new format I was going to use).

> This is bad, because packages that are
> (say) on hold but installed don't get menu entries. The right thing to do
> would be to generate menu entries like that:
> 
> if ( state == "remove * *" and postrm of package is currently running)
> 	Do not generate menu entry
> else if (state == "install * *" and postinst of package is currently running)

No, even that will not do (I'm testing for that at the moment, but it's wrong).
The thing is, dslects starts one run of dpkg to install hundreds of packages,
and dpkg only updates the status files after a full run of dpkg, so the last
of those "hundreds" packages will not see the other "hundreds"-1 packages,
and no postinsts of any of those packages are running.

> 	Generate menu entry
> else if (state == "* * installed)
> 	Generate menu entry
> else
> 	Do not generate menu entry.

on startup: try to open /var/run/update-menu.pid with O_EXCL


  if it fails, just open the file, and send a USR1 signal to the pid
    listed in theire (if that's update-menus, that is).
  
  Then open /var/run/update-menu.pid again O_EXCL (should work now, see 
  above)
  set up a USR1 signal handler that unlinks /var/run/update-menu.pid,
  and then terminates.
  then go in a loop that checks if dpkg is running anywhere,
  and sleeps one second.

  When we leave the last loop, we are sure that
    -there is no dpkg running any more (at least the last status file is
     saved),
    -we are the onlu update-menus running.
  and thus we can do the "old" update-menus stuff, like
  
    if (state == "*install*") then generate menu-entry
  
I hope this would at least be more reliable, but I'm interested in
seeing comments to this (I already posted something like this
some time ago to debian-devel).

> Also, it would be nice to do the following by default:
> 
>  s/Apps/Applications/           
> 
> Other root menu entries are longer than 'Applications', so there's no point
> in abbreviating it to 'Apps'.
> 
>  s/WindowManagers/Window Managers/
>  s/XShells

The one disadvantage is that as far as I'm aware this would break fvwm2,
and probably most other window managers. But I guess the /etc/menu-method/*
scripts could be re-written to allow this.

> Finally, I don't know if afterstep or menu is to blame for this, but I
> don't get menu titles under afterstep. This causes menus with only one or
> two entries not to be lined up properly, etc. Would it be possible to get
> (say) the menu that pops up when you select 'Games' to be titled 'Games'?

Hopefully the fault of the afterstep menu-method, but I'll look into
that. Thanks.

-- 
joost witteveen     joostje@debian.org
    
I came, I saw, ..., well, it wasn't free so I left again. (LUA, 1988)


Reply to: