Re: Debian Menu policy leads to confusion
On Mon, Mar 20, 2006 at 12:12:40AM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> > Well I see the Terminal entry as a window-manager specific
> > configuration, so it does not belong in Debian menu.
>
> I see your point. But then there is no reason to separate terminal
> emulators from other applications, therefore I suggest moving them to
> "Applications/Terminal Emulators". It might confuse old users, but
> having things organized in a consistent intuitive way is more important
> that traditions, in my opinion.
No opinion here.
> >> How about "Lockers"[1] and "Savers"[2]? Everybody knows what a term
> >> "screensaver" refers to. Locker could mean a drawer or a cupboard for
> >> native English speakers, though. Or maybe not.
> >>
> >> [1] Screen/Lockers
> >> [2] Screen/Savers
> >
> > It is clearer than Lock and Save.
>
> Another alternative would be:
>
> Screen/Security - for locking
> Screen/Power - for blanking the screen
I don't think anybody will guess what that means...
(Especially if the Screen Security team start to wear "Screen Power!"
tee-shirt).
> Nowadays a screensaver (moving graphics) is really just a toy that saves
> neither screen, nor power, so renaming this to "Power" might make
> package maintainers rethink what belongs there. A single entry to start
> a screensaver is fine, but is there a good reason for not having entries
> for all sorts of graphics hacks (I like this term much more) in
> "Games/Toys" or similar? The configuration GUIs should also go to
> "Applications/System/Administration".
> >> The question is, do they really deserve a separate section? (8 entries
> >> in total) The ability to draw to root window does not indicate the
> >> purpose of an application. Many can do that. Many do. Most are in
> >> different sections.
> >
> > There a bit related to bug #162849. They are application that do not
> > open windows.
>
> The bug report is about daemons. I do not thinks these applications fall
> under this category. Some of them even are purely GUI applications
> (chbg, wallp).
>
> [ What concerns actual daemons, I see no point in having them in menu at
> all. If you have to look at output of "ps" in a terminal to see if it is
> running, would it be too hard to type in the name of said daemon in the
> same terminal? Anyways, this is only my point of view. ]
Daemons really mean programs that does not require user interaction, for
example xsnow, xhangglider, p2p clients etc.
It should be possible to provide a pair of menu entry that start and
stop the service.
> > Root-window should be reserved to menu entries (not programs) which sole
> > purpose is to modify the Root-window. But it is not clear there are
> > enough of them to warrant a subsection.
>
> I see "modify the Root-window" as entertainment. How is "xphoon"
> different from, let us say, "xdesktopwaves" found in "Game/Toys"?
>
> >> Maybe allow WM specific top level entries? Something like
> >> "Configuration" in Fluxbox root menu. These could be named after WM that
> >> uses them (for example "FVWM"), or simply "Modules". A person running a
> >> WM that uses modules can be expected to know what they are.
> >
> > In fact, they are already allowed. However this should not prevent us
> > to improve the recommandation.
>
> I would go with "Modules" as top level section. Nice and clear.
I agree.
> > I think games should be classified by the kind of interaction between
> > the computer(s) and the player(s).
>
> I am not sure I understand you. Could you please explain?
I think we should keep the spirit of the current classification:
We have Arcade for games that require the player to be fast,
Strategy for gamer where timeis not an issue,
Cards for games that require the player to deal with cards, etc.
Whether the game plot is sci-fi or heroic fantasy or two-headed
dinosaurs, is less important because there is too much possible plot to
be organised in a menu.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: