Re: Debian menus policy
Thomas Hood wrote:
> Well, the problem is that not every program has a medium,
> although every program has a function. Every program does
> something, but not every program really does something
> _to_ something: e.g., shells, browsers, games. What is
> the "medium" of a game ... the high score file? So your
> list still makes for some strange bedfellows: Graphics,
> Sound, Text, ... System?
Sure. The system is something that is operated on by configuration tools,
status monitors, etc.
You're right that the scheme isn't completely consistent because not all
programs operate on something. But for those that do, it makes the most
sense to group them together. Those that don't operate on anything in
particular (such as games and shells) can be grouped accordingly (Games,
XShells).
Again, I feel that a sound editor and a sound player have more to do
with each other than they do with a text editor or a text viewer. So it
doesn't make sense to me to have the sound editor and the text editor in
the same section, but the sound player and text viewer off somewhere
else (whether together or not).
> However that isn't a fatal problem. We can have two trees.
> Every program will appear on the function-classified tree.
> Those programs which operate on data will appear on a
> separate data-object-classified tree.
I don't like the redundancy of that. How about, those programs that operate
on some kind of "document" (text, graphic, sound, movie, spreadsheet,
desktop publishing, etc.) go into a "data-oriented" tree, and those that
don't (games, shells, most network protocol clients) can go into a more
function-oriented tree.
Or maybe, if we don't mind back-end redundancy that can be hidden from
the user, we maintain enough information about the menu that either a
function- or data-oriented view may be constructed, and then make it a
user preference which one he wants to see.
Craig
Reply to: