unaccessability

[Kevin Kofler]

Michael Schwendt wrote:
> What I don't like is the situation that somebody uses a graphical tool to
> install "software", and the installed stuff doesn't show up anywhere in
> the graphical desktop user interface (such as a menu system), but is only
> listed as installed. That's the "WTF?" scenario, where the user needs to
> be an expert to figure out that the installed thing is CLI-only (or not
> even "executable" at all) and something that cannot be "used" from within
> the desktop UI.

While I have had such a "Huh?" moment a couple times too, I mostly blame the 
descriptions for that. Command-line tools rarely include "command-line" in 
their descriptions, ImageMagick (your example) even claims to be "for the X 
Window System"!

> If an "application installer" will be able to install arbitrary
> "packages", I would welcome a very obvious distinction in the UI,
> a special interface for specific types of components and "add-ons".
> Not old-school ambiguous "categories". What I don't like is a graphical
> "package tool" that tries to handle the 40,000 "packages" by sorting them
> into categories. And the user is confronted with many thousands of "lib"
> packages, for example, which are no "applications" (no "programs" to
> use). A developer (or a sysadmin) has different requirements.

And the problem there is how to decide what should be shown to the user. 
There are many examples of packages which users WILL want to install, yet do 
not directly show up in the menus as applications, e.g.:
* plugins of all sorts. For example, multimedia codecs.
* library overrides such as freetype-freeworld or atlas-sse2.
* themes and other artwork, that can be selected in configuration dialogs 
once installed.
* fonts (arguably a special case of "artwork" above).
In fact, comps only contains stuff that was manually added to some group 
because there are users that will want to install that package explicitly. 
Pure library packages do NOT show up when you browse the categories, only 
when you search the complete package set for some name / description / ….

There are also library packages (mainly used as libraries other software 
links to) including some examples that can be useful on their own, sometimes 
in a -tools subpackage, sometimes not; sometimes with a .desktop file, 
sometimes not. Are those "applications" or "libraries"?

        Kevin Kofler