unaccessability

[Michael Schwendt]

On Thu, 7 Nov 2013 12:28:46 -0500 (EST), Christian Schaller wrote:

> Hi,
> The core principle of the installer is that it operates on an application level and not a package level. The current way it determines if something is an application
>  is by looking for a .desktop file. So in theory you could put a bitchx.desktop file  into the bitchx package and it would appear in the installer. That said I don't 
> think it is generally a bad idea if command line/terminal applications are installed from the command line, but there is no hard policy blocking such applications from making themselves available in the installer.
> 

Please don't let it install applications, which cannot be started via the
graphical desktop user interface (such as a menu system or a list of
installed Applications). Users, who install software with the help of a
graphical program, expect that afterwards they can find and launch the
installed software via the graphical desktop user interface. Alternatively,
the installer ought to offer launching something as the next step.

If the installed software is only available at the command-line, there
ought to be a big fat warning about that. Or a special category, or a
hurdle to take, before a CLI program could be installed. It's similar with
clicking ".rpm" packages on a web page. Installing them has become easy
enough, but especially newbies are confused a lot, if the installation is
successful but there seems to be no way to start the installed stuff.
It's no helpful marketing, if in forums they get told that what they have
installed is command-line only and doesn't show up in the desktop GUI
anywhere. The installed thing ought to be "reachable" via the GUI, so
e.g. for a service/daemon, there ought to be a way to locate that thing
without having to use a terminal.