On Mon, Apr 28, 2003 at 03:35:17PM -0400, Colin Walters wrote:
> Hi David,
>
> On an unrelated tangent, let me say: darcs is cool :)
Thanks! :)
> On Mon, 2003-04-28 at 13:51, David Roundy wrote:
> > I would hope that rather than such generic terms, one could specify
> > more specific tags for highly specialized packages and have these tags
> > imply a certain degree of specialization. So this way a user
> > interested in a specific specialization would be able to browse
> >
> > specialized
> > bioinformatics
> > physics
> > mpb
> > mpb-mpi
> > chemistry
>
> Well...there are already "chemistry" and "biology" tags. I do agree
> that specialization::{high,low} or whatever isn't perfect, but having
> both say "chemistry" and "specialized::chemistry" seems worse.
>
> I guess it sort of depends too on how tags like "biology" will be used.
> If say someone wrote a nice easy to use educational GNOME/KDE program
> that provided an introduction to biology, it seems to me it should be
> tagged "biology", but shouldn't be tagged specialized::biology.
>
> What solution do you propose?
I meant to suggest not an additional specialized::chemistry tag, but that
any package having the chemistry tag would also automatically have the
specialized tag. The counterexample you gave is valid: a chemistry game
for preschoolers would be flagged for specialists only. Perhaps what I
would want would be more like a set of "field of endeavor" flags all of
which would indicate the field in which it would be used. So I imagine the
following "field of endeavor" flags for this example
education
chemistry
physics
biology
Then we might define as specialized any package which has at least one
field of endeavor (of course, some packages like text editors won't have
a field of endeavor), but doesn't contain education. Obviously, education
isn't likely to be the only exception, but if we define specialized in this
sort of a manner, I think it would make it easier to define other variants
on it (as long as packages have been correctly categorized in terms of
field of endeavor).
On the other hand, even within a field of endeavor there are highly
specialized packages (of which mpb is an excellent example, which most
physicists probably would not be interested in), so something more might be
needed. But I would guess that you could get by pretty well with just a
set of field of endeavor tags.
I should perhaps mention that I don't think "field of endeavor" is a good
name, certainly not to expose to the user, although it's the best I can
come up with off the top of my head.
> > Again, I would hope that a less general tagging of packages could be
> > achieved, with the user level inferred from more specific tags. For
> > example, it would be nice to have tags indicating the style of user
> > interface a package supports. I imagine something like
> >
> > userlevel::novice = !specialized && (interface::gui || interface::curses)
>
> Maybe. But your proposal above brings in almost all the packages.
> Basically anything that's not biology or physics or whatever. That's
> far from what I want. I mean, the difference for a novice user between
> rhythmbox and (to pick a random example) mp3blaster is pretty large, in
> my opinion.
>
> This isn't to bash mp3blaster; it has a different (more technical)
> audience.
Hmmmm. That is one problem with trying to include curses apps (which I was
a little worried about, but didn't want to leave out aptitude).
I think a great tag to have (but perhaps cumbersome to add to so many
packages) would be a set of keybindings tags, which would try to indicate
the default keybindings (since that is what a novice is going to see). So
packages could advertise keybindings::vi or keybindings::emacs, which would
exclude them from novice level... Aaack. I just checked, and off the top
of my head, I would categorize aptitude as keybindings::vi (since it
supports j and k for up and down. Then if gnome and kde were to agree on
some standard keybindings (they may already--I don't use either, except for
galeon), then we could have something like keybindings::kdegnomelike... or
just keybindings::windows or something. But I'm thinking maybe this would
be way too complicated, and while it would drop oleo off the novice list
probably wouldn't hid mp3blaster. Maybe novices should only be shown gui
programs after all. They probably don't want to be using a shell
anyways...
> I understand that goal. I hope my argument above is persuasive enough
> to convince you that something like userlevel:: is a good idea.
Well, I'm certainly convinced that at the very least some work would have
to be done with a userlevel:: goal specifically in mind. I'm not sure I
like my keybindings:: idea, since it seems a bit ugly[1], but I would hope
that something like it could be done, which might make it easier to define
other sets of packages without having to tag every package with yet another
in-or-out tag. On the other hand, you'd have to weigh this against the
cost of having to tag every gnome package with interface::gui,
keybindings::standard etc (although I guess the 'gnome' tag would probably
imply all the others...).
[1] How exactly does one define vi keybindings in programs other than text
editors? my only thought would be to look for the j and k for down and
up...
--
David Roundy
http://civet.berkeley.edu/droundy/
