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

Re: Debian menus policy



Thomas Hood wrote:
...
> But programs that are data-oriented also have functions, and
> so belong in the function-oriented tree too.  I don't see any
> reason why a program should not appear in multiple places in
> the menu hierarchy.  A program might even appear multiple times
> in one of the two trees---if it has several functions or if
> it operates on several kinds of object.  What is most important
> is that it appear in at least one place; and it will be a
> convenience to the user if s/he knows that every program
> appears at least in the function-oriented tree.

  IMO that should be 'tweakable' by user. IMO it would be useful if each
program had primary 'keyword' (functionality, or whatever) which would
be used to construct the minimal menu tree, where each program is just
once. there might be other keywords that would be used to put program in
additional submenus.

> It was suggested earlier that the user be able to choose
> between the two different kinds of tree, but I think it will
> be simpler and more useful if we simply include both trees.
> Thus the top-level menu would have the following entries:
>    Apps by function
>    Apps by object
>    Help
>    Screen
> 
> Returning to the question of the connection with package
> classification, what we might do is add new tags to the
> package description for function and object type which would
> have the same permissible set of values as there are menu

  it has to be slightly more complicated since one package might provide
more then one program that would be in the menu but in general I'm all
for that.

> titles.  Thus a network-enabled text editor would appear
> under Apps_by_function|Editors|Text and under
> Apps_by_object|Text|Editors and the package would have the
> tags "Functions: editor" and "Objects: text".  We could
> then get debhelper to set up menu entries for us.  How 'bout
> that?

  looks like that might work, of course in somewhat more complicated
form...

	erik



Reply to: