Today, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> The user should see a list of groups (I will call them this because I
> think groupings can be more general than just tasks). The UI tool will
> allow sorting and searching of the groups and when browsing individual
> packages it will be possible to see what groups they are part of. 

> The user can select that a group is of interest to them and mark it for
> 'installation'. Once done this means all packages currently in the group
> will be installed and all new packages added to the group in future will
> be installed. The UI tool will track when new packages are added to groups
> and present that information in conjunction with the traditional new
> packages display.

> A tree-like display can be used to show what packages are part of a group
> and allow individual selection. Since some groups are quite large it may
> make sense to categorize the packages lists into finer subgroups
> (primarily to help the user navitagate around, but they could be seperate
> at the top level too) that can all be individually selected for install. 
> [Example: task-python-critical, task-python-web, task-python-gui]


Hmm. I wonder if something like Keywords would help with that. For
example, emacs fits into many a description, say "Editor"
(understatement), "Desktop" and "Development/IDE" (sounds right to
me). Now, returning to tasks, if the user chose to use his computer as
a development environment, he could choose Emacs as his IDE.

Also, this would speed up searching a lot. When, for example, I want
to install a Tetris-like game, I could just search for the keyword
"Games/Tetris" and get every tetris-like game in the distribution, and
not only a substring match of some part of the description.

This, of course, would require the maintainers to have some sort of
discipline with the chosing of keywords for their packages, I think
every part of the program should be mentioned to make grouping the
packages and judging the package's value easier.

I presume that with keywords, a tree-like display with groups and
sub-groups could be done, but only where one can say "this thing
belongs down there", as with "Development/IDE", or
"Games/Tetris". Tetris is a game, not a physics package, so it should
be in the "Games" group. I think that many a thought will have to go
into the right naming of the groups, and their sub-categories. Also,
keep in mind that a package could be in many groups and sub-groups at
once, and therefore should be mentioned more than once in the package
managing UI. If the user opens the category "expert editors", Emacs
will show up, just as it does when the user opens the category IDEs in
Development.



This does not, in itself, solve the problem that ajt
described. Therefore, I think that we should also assign a certain
weight to a sub-category, as well as to a package in that
category. This could then look like this:

<control pkg=emacs>
Keywords: Desktop(0), Editors/Expert(20), Development/IDE(15)
</control>

Then, for every category and sub-category, there should be a package
(or something else, I can't think of anything else in the moment),
which has a control field "Category: <weight>" set, to make it a
group and to assign a certain weight to the
sub-category. Top-level-categories should have 0, I guess.

The top-level categories would then be what is a task now, while the
sub-categories would allow the user to refine his selection until he
reaches the package level.

> Jason


And we could let it have a telepathic user interface, and have it
speed up the internet by 2000%, and have it end world hunger, and ...

Anyway.

regards,
-- 
Andreas Stefan Fuchs                             in Real Life aka
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]         in NNTP and 
SMTP,
antifuchs                                        in IRCNet and
Relf Herbstfresser, Male 1/2 Elf Priest          in AD&D


Reply via email to