Software center doesn't show whether an app is a CLI or a GUI app

[Jon Loldrup]

Binary package hint: software-center

When considering whether to install an application or not, most users find it quite significant whether the application is CLI based or has a GUI. As it is now, this information can only be had if the textual software description states it explicitly, or if a screenshot is available. In this way, this piece of information cannot easily be read when browsing the Software Center, and theres no guarantee that it is there at all (example given: the 'ftp' package).

Suggested solution:
The problem could be solved by adding a boolean parameter to each package, stating whether it is CLI or not. This information can then be communicated to the user by adding a CLI-icon to all CLI-based packages.

If adding an extra icon to all applications is unacceptable, the following suggestion could offer a partial solution:
Right now the Software Center has one generic icon for all software packages that lacks their own icon. Replacing this icon with two generic icons (one showing a CLI, another showing some fancy desktop-stuff) will help communicate whether the app is CLI-based or not, at least for all the packages that doesn't come with their own icons. This solution doesn't help much for those that does.

[Jon Loldrup (loldrup)]

How do I state that this bug also affects the 100 paper cuts project? The "also affects project" link is useless: it offers me to link this bug to some upstream URL (??) or to the 'softare store project'. Thanks but no thanks.

[Robert Roth (evfool)]

@Jon Loldrup: I have set it for you as affecting the One Hundred Papercuts project for you: There was a Choose another project link on the Also affects project page.

[Matthew Paul Thomas (mpt)]

Sorry, this is not a papercut, because it would need non-trivial design work before it became fixable.

[Robert Roth (evfool)]

Sorry for assigning it then to the papercuts, but as a comment @mpt : as you said, "it would need non-trivial design work before it became fixable", but afterwards, it would be easy to fix I guess (desktop files do contain a Terminal entry). So i guess that it still meets the papercut requirements, because:
- it is a problem occurring within an existing piece of software, software center
- it's presence makes a computer less pleasant to use (if you want to use an app, you install it from SC and you can not start it, it makes a computer less pleasant to use)
- it is easy to fix, see above
- the average user encounters in in a default application in Ubuntu
So maybe the definition of a papercut should be a bit more precise, e.g. the "easy to fix" bullet could be "does not require more than one man-day of work(coding, design, etc)".

[Matthew Paul Thomas (mpt)]

I should have explained what design work is needed. What we need now is two things.

First, ideas, in the form of wireframe sketches, about how USC should present console applications differently from graphical ones. Some points to start off with:
* For most people, most of the applications they see in USC will be graphical ones. So, using text or any obvious marker to say that they're graphical could get annoyingly repetitive.
* In some subsections (for example, "Developer Tools" > "OCaml"), all -- or nearly all -- of the items are for use at the console. So any obvious marker for those could get annoyingly repetitive within those sections too.
* Maybe there could be a marker just for console applications, not for graphical ones.

Second, a more specific plan about how USC should tell the difference between the types of package in the first place. Could Launchpad set the flag automatically when building a package, e.g. by examining the package for executable files vs. .desktop files? Or would the maintainer need to do it manually? If so, how would they do it?