On 01/28/2014 03:12 PM, Richard Hughes wrote:

On 28 January 2014 18:43, Przemek Klosowski <przemek.klosowski@nist.gov> wrote:

There are two separate issues here: 'abandonment', and 'GUIness'. As to the
latter, I think it's a mistake to have a primary application installation
tool that only deals with GUI apps, because it relegates text-based tools,
such as 'units', to a second-class status of being hard to find and to
install.

That's not the tool we've designed and built. We've built a GUI
application installer, not a package installer.

[sorry fo the delayed answer---I got wrapped up and had this draft sitting open for two weeks]

While it's not the fault of the installer, I am concerned about that distinction. For better or worse, a lot of useful tools seem to be out of scope for a 'GUI application installer'. GCC, perl, git, octave, R, units, mysql/sqlite3, this kind of thing. It doesn't even make sense to shoehorn them into GUI app world by embedding them in terminals, because their natural environment is command-line interaction.

The emphasis on GUI is great, but it should enhance rather than deprecate the old-style interactive command model that arguably is the core idea in Unix. Your tool, while improving the GUI app experience, could also support non GUI software---or at least not completely ignore its existence. I do get it that there is a class of GUI users that need to see a window with buttons and help, and non-GUI apps simply baffle them with a blinking command prompt, at best. OTOH, I believe there should be a setting in the installer about that, "do not show me commandline software". I believe that it should be off by default, but maybe I am wrong about that.

Do you really think it's impossible?

By the way, I even use some commandline-like apps on my Android. In fact, I dislike the fact that the 'GUI app' view of the world results in separate app for every function: an app for Slashdot, and a slightly different app for Reddit.