[email protected] wrote:
There is no Applications/Editor category in the PM. The subcategories
under Applications match the Applications menu. Items in the an
Applications subcategory, when installed, should appear within
corresponding Applications menu entry. Ubuntu has Add/Remove... in their
Applications menu that works the same way. Emacs-gtk and GVim are in the
Accessories subcategory. A primary requirement of a package to be
categorized under Applications/... is that it appear in the
corresponding Applications submenu after installation.
It would make more sense to get the categorization correct for the
packaging system, and move the menu items in Gnome (or whatever) around
later. I don't think it makes sense to set package cateogization based
upon arbitrary constraints in the current menu configuration.
It's more useful to keep the application menus and PM categories
aligned where possible. Categorization can be adjusted if/when the
menus adjust - it's just metadata.
It would be reasonable to classify gnu-emacs-gtk, gnu-emacs-x and other
packages under Applications/... when they are also installed in the
corresponding Applications (or System) submenu. Until then they need to
live elsewhere. Development/Editors seemed more appropriate to our
primary target audience, developers, than System/Text Tools.
I don't understand this argument. Applications isn't okay, because that
doesn't match the menu layout, but Development/Editors is okay, because
it doesn't match the menu layout? Huh?
We have an extra level of Development categorization in the PM vs
Applications/Developer Tools. Anything that goes into the menu goes
into Applications/Developer Tools.
Emacs-nox (terminal-based) is not listed within Ubuntu's Add/Remove.
Hypenate that to Emacs-no-x, otherwise it sounds like a version that's
been localized to Latin.
:-) But SUNWemacs-nox is the package name.
Add/Remove... does not list any terminal-based applications. Ubuntu
appears to agree with the proposition that terminal-based applications
are appropriate for only a limited number of highly computer-skilled
users. Mixing them in with GUI applications will only lead to a number
of issues for other users who will install them while browsing for
'interesting' applications, and, after installation, will not even be
able to find and start them. The highly-skilled users will have little
trouble finding them by searching or even browsing.
Therefore we should make it harder for the highly-skilled users to find
and install the terminal applications, since they're the ones most
likely to actually use them? I don't follow this argument either. I'm
also not in favor of treating any group of users as though they're
stupid.
Making something easier is not the same as treating a group as if they
are stupid. I'd make it easy for everyone if it were possible, but the
current constraints don't support that. Given the constraint, make
adjustmets so that all can accomplish what they need.
Frnak
|
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
