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

Re: Applications menu for Fvwm



Philippe Troin wrote:
> As every wm configuration file is different, I suggest that every wm
> package provides an install-menu-<wm> script which will handle
> removal and additions to the window manager menus...
> Then install-menu would dispatch the request to all installed wms.

Yes, I think that's the way to go. Should it just call all executables
matching the pattern /usr/sbin/install-menu-* , or should it use
/etc/X11/window-managers for finding out which wms are installed ?

> > Now, I can think of some open questions:
> > * What information should be provided to install-menu ?
> >   This must be enough information such that all window managers
> >   are happy with it.
> 
> We probably want:
> 1) an action (add/remove)
> 2) a package name
> 3) a category (nobody wants menus filling the whole screen)

Yep. Additionally, I propose the action "initialize" which
takes the name of a wm as an argument. e.g.
	install-menu initialize fvwm2
This will be invoked by the postinst of fvwm2.
It will then call install-menu-fvwm2 for all entries
install-menu's database.

> > * Should we use the package section as the name of the menu ?
> >   (This will be more consistent and thus probably easier for the user)
> 
> Duh ? Makes sense as long as the package name does the same (I think
> that if the package `xterm-color-3dscrollbar' (if it ever comes to
> life) shouldn't appear like that in the menu.
Of course not. I thought more about using package sections (such as
graphics) as the name for the category. So, e.g. "tgif" will end up
in the submenu named "graphics" because the tgif package belongs to
the section "graphics". But probably this should only be used as
a general guideline and not be mandated by the implementation of
install-menu. 

> Some additional remarks...
> 
> We'll be faced with the same problem as with /etc/skel.... What about
> if users copy the wm file and modify it (which is quite common) ? The
> case will happen much more often than /etc/skel (I mean /etc/skel 
> files aren't changed very often, at least less often than this case), 
> as any X package will want to update the menus.
Yes that's an important issue.

> I've always considered a nice thing to update all of the users
> menus... 
This would really be cool.

> But what if the user changed the conf file beyond
> recognition ?
> I suggest using a meta comment, like this:
> 	#---DEBIAN-UPDATE-CONFFILE---
> With some other comment around saying that if this line is 
> changed/deleted, automatic updates won't be possible anymore...
Meta-comments should also be used to denote the part of the config
file which may be changed by install-menu-<wm>.

> Additionnaly, what about the existing installed Debian base ? We must
> think about a roadmap...

For the migration phase, install-menu could come with an overrides database
of menu-entries. 

> > * Who writes it ? =
> 
> >   [I know that I'm kind of volunteering for it when I ask this
> >   question ;-)]
> 
> I could try to help (when I'll have upgraded my packages to the new forma=
> t :-)
Oops, I'll have to do this for my packages, too.

-Chris

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: