[Implemented] Command line applications and Extras
 

One of the topics of the last community meeting about Extras QA was if command line applications (CLI) should be available for regular users through the application manager or not. We can't reach a consensus, and it seems to generate very contradictory opinions inside our community.

We're talking about apps that doesn't have a UI nor place a icon in the desktop, nor are simple enables that display a message during/after installation.

Please note that this is not about ban some applications, is about the way of get some specific applications.

Here is the initial discussion: http://n2.nabble.com/Command-line-ap....html#a4068091

Moderator edit: http://maemo.org/community/brainstor...ns_and_extras/ (Brainstorm item)

Re: [Sandbox] Command line applications and Extras
 

I'm for it being available.

Re: [Sandbox] Command line applications and Extras
 

I would most certainly also vote for inclusion.

Re: [Sandbox] Command line applications and Extras
 

This is not about the inclusion or not of these apps, these apps will be available for sure, this is about the user experience, if you're a complete noob in the Linux world and install one of these apps you will have a very bad experience in my opinion, since the app doesn't provide any feedback and there's no application icon to start the app.

Quoting myself:
"Please note that this is not about ban some applications, is about the way of get some specific applications."

Re: [Sandbox] Command line applications and Extras
 

Perhaps this is what red/blue pill should be used for?

Re: [Sandbox] Command line applications and Extras
 

im a noob myself and cant be doing with command line. much rather have a ui. i say leave them out

Re: [Sandbox] Command line applications and Extras
 

Just make an Extras - Command Line repository and be done with it. Those that are scared of / hate CLI won't go there. And those that love/need CLI will have all the goodness of app-Manager.

Re: [Sandbox] Command line applications and Extras
 

Can you please propose this as a solution at Brainstorm ?

Thanks.

Re: [Sandbox] Command line applications and Extras
 

I'm a command line junkie, and I don't think command line apps as a general rule should be listed in the visual application manager.

Now that said there might be some exceptions, for example things like VIM, nethack, or other CLI apps that stay open and provide a constant interface. You can create a shortcut to these in the ui, and that can be helpful, and not necessarily confusing to end users. But they should be clearly labeled as the hardcore/niche/geek tools that they are.

But any app that you invoke on the command line with parameters, and no additional input, should likely be left out of the Visual App Manager.

I don't see how I could complain that I had to go to a terminal and use the apt-get command to install something like latex commands, or flac encoders etc... that they are certain to invoke from a terminal/script anyway.

It's not possible to show critical update notifications graphically even for non-graphical packages?

It seems like this sort of problem would also exhibit itself in critical updates for library packages?

Re: [Sandbox] Command line applications and Extras
 

I'm completely with goldfish and vdvsx on this one. If you like the command line you won't have a problem learning a few extra commands to install thngs. If you don't, and don't want to learn, all it's going to do is provide confusion.
"I installed mplayer but can't find it in the menu."
I think having an extras-cli repository would be a mistake because it would get enabled in order to install things like mplayer as a canola/kmplayer dependancy, and then we'd have exactly the same problem again.

Re: [Sandbox] Command line applications and Extras
 

Instead of going through the hassle of making another repo, one could simply signal that the app is CL-only (in app description perhaps?). This would be mandatory, possibly auto-added
Then the user could choose

Re: [Sandbox] Command line applications and Extras
 

This apparently requires yet another registration. I am at work and can not spare any more time on this. Maybe this weekend if someone else does not do it first.

I use apt-get exclusively on my desktops and laptops instead of whatever GUI is provided by the platform. but on maemo devices, I want the convenience of app-manager.

Re: [Sandbox] Command line applications and Extras
 

Voting open: http://maemo.org/community/brainstor...ns_and_extras/

PS. Can one of the mods change the thread title.

Re: [Sandbox] Command line applications and Extras
 

Thank you, that is a far better job than I could have hoped to do.

Re: [Sandbox] Command line applications and Extras
 

how will the case of popular apps like mplayer work? Its a command-line application that everyone would want to install. I see the people, for whom things are being done to keep them away from harm, easily exposed to the CLI world.

Re: [Sandbox] Command line applications and Extras
 

@archebyte, there is a graphical launcher for mplayer (sib) that hides the CLI.
I have voted for making CLI-only apps available only through apt. My understanding is that, as soon as there is a graphical interface available, the dependency will be solved? E.g. when launcher for the mplayer (graphical) appears in Application Manager, it won't bother the user the go to the terminal and install mplayer separately.

I think that this approach is consistent with the future of the Maemo platform, that will be mainstream (need for consistent user experience) but open to those more advanced users at the same time (go and install from terminal if you want).

Re: [Sandbox] Command line applications and Extras
 

Done. Brainstorm link added to first post also.

Re: [Sandbox] Command line applications and Extras
 

With all due respect, I do not believe that it is necessary to punish CLI users to avoid harming or even offending GUI users.

Right now, app-manager is by far the most convenient way to browse for and install applications to Nokia nXXX. If the number of applications available ever explodes, I will probably go to apt-get.

Re: [Under Consideration] Command line applications and Extras
 

Currently winning is A new category/switcher should be implemented in HAM: great, fantastic, wonderful. It's an excellent suggestion; we've even discussed it in the thread. Except who's going to do the coding? Will Nokia accept the patch? Which MU is it going to be scheduled for? When will it get into users' hands? What do we do in the meantime?

Second most popular is Add a new catalog for all CLI and library items. Two obvious problems with this:

1. It suggests putting codecs for gstreamer & other sorts of plugins in there too. Hang on, why? The use cases for command-line apps which require parameters and transparent enrichment of the Media Player are totally different.
2. How do we handle the QA process? Is it a duplication of -devel, -testing and Extras? Just the first two? What features in maemo.org/packages/ and elsewhere get delayed whilst Niels works on it?

Brainstorm rant:
This is the fundamental problem with Brainstorm: solutions don't have pros/cons stored against them. Solutions are presented as being equal. Positions can't change and people's opinions move; the debate never changes and there's no scope for consensus. The more we use it, the more I'm convinced it's a fundamentally flawed approach. Since when was the most popular technical solution the right one?

Selecting a technical solution is a case of experts and stakeholders getting together to discuss the issues and come out with a consensus, reflecting the technically possible; the pragmatic and the underlying requirements. Technical problem solving by committee and popular vote - show me an instance where this has ever worked. Please!

Re: [Under Consideration] Command line applications and Extras
 

Apart from the outstanding questions about QA and workload (which are pretty big outstanding questions!) and my nit about it including user-friendly codecs and the like; this may still be the best approach for applications which don't have a daemon.

It doesn't answer the question about them being in /downloads/ (perhaps only if the author can be bothered to) or what section they appear in in that repository (presumably the standard set so they appear in HAM). If even some appear in Downloads, it's only a matter of time until someone accidentally gets the repo enabled and sees more stuff than they wanted.

Perhaps, even if solution #5 is selected, it should be combined with solution #4. I'm loathe to create a new solution as many votes have already been cast and will people re-vote?

Re: [Sandbox] Command line applications and Extras
 

As I mentioned earlier in this thread, I am a heavy CLI user.

Making command line apps only accessible via apt does not feel like a punishment to me. CLI apps can be ported from their existing versions at a much faster rate than their GUI counterparts.

If they all end up in the app browser, it will flood out all the more Maemo-specific apps, and I feel that would sully *my* user experience, even knowing what they all are.

It feels more context specific that the graphical app manager is where you install graphical apps.

And apt-get for everything else, I'm not saying a graphical frontend to apt might not be a bad idea, but I think the maemo app manager should be focused on Maemo oriented apps.

Taking apt-get away would be a punishment to us (which I'm sure some carriers will eventually try to inflict), this is not.


I think a good example to look at here is the Ubuntu Add/Remove programs dialog. It to is just a frontend to apt-get, and by and large, it only presents options that will end up creating icons to gui apps.

Of course apt-get/synaptic etc... is still available for more esoteric packages.

Re: [Under Consideration] Command line applications and Extras
 

As long as it doesn't duplicate any functionality on regular extras (like use libraries that could conflict) I am fine with having another repo.

Though a possible alternative if we just stick with extras is to tag each command line application with the acronym cli in front of the application's name. It would also have the side benefit of making them easy to find (just look in the C section!).

Re: [Under Consideration] Command line applications and Extras
 

Question:

I'm an end user, not afraid of cli. I buy a N900. I'm looking for a media player (mplayer). I look in the app manager. I don't see anything like what I'm looking for. I decide the N900 isn't that great after all, heck, it doesn't even have mplayer ported.

If not in a repository, where will a list of available cli apps be kept? Howw will I know what cli's are available? I generally use synaptic (gui) to find and install packages in ubuntu (at work). If it wasn't for the search feature, I wouldn't have installed half the stuff I have, including cli stuff.

For the non-expert, non-newbie, semi-advanced user, a gui solution to find these types of things would make life much easier.

Re: [Under Consideration] Command line applications and Extras
 

I was going to suggest an additional repository, e.g. extras-cli., but have no idea how packages go from extras-devel/testing -> extras as I haven't started looking at the infrastructure behind extras.

Perhaps a tag in the control file could be used to specify the package for extras-cli so it would be moved to the extras-cli repository instead of extras (perhaps an existing control field could be used for this). In addition it would have to be specified that an extras package could never be dependent on a extras-cli package and obviously anyone using extras-cli would have to enable extras, which also means all libraries would have to be installed to extras.

I like the idea of an additional repository as the same tools can be used to install and categories can still be used to separate the packages.

This could also mean splitting a cli program(s) from a package if others depended on a library in that package (as has been done in Debian), so the library could be extras and the cli program(s) would be exras-cli.

Of course I may have no idea what I'm writing about here ;)

Re: [Under Consideration] Command line applications and Extras
 

If you have any questions about the detail, get in touch with X-Fade on #maemo - I'm sure he'd like to share some of the coding :-)

This sounds like a reasonable proposition. Using a debtag it could go through the normal QA process but the final promotion takes it from -testing to -cli.

Advantages:

• Packages interface doesn't need duplicating.
• QA process remains the same.
• Only a small change to highlight on a package's page what its final destination will be.

Disadvantages:

• Anyone with -testing enabled will see all -cli packages.
• We may still want to encouage a standard icon & sentence for -testing users and those Extras users who get it enabled semi-accidentally.

Sounds like a good plan to me, TBH!

Re: [Under Consideration] Command line applications and Extras
 

Another problem is dependencies. Imagine a CLI package foo and a GUI wrapper gfoo that depends on foo. I think we all agree that (once past QA) gfoo should be in extras, and visible in h-a-m. However if foo is not somewhere where h-a-m can find it gfoo is not installable unless the user enables the new catalog and then we're back to square one.

+1

Re: [Under Consideration] Command line applications and Extras
 

What about Plugins (for settings or status area)?

They are also often "invisible" to the user but also not available to the command line.

IMHO they should also get an icon (or category) to show the user what he can expect.

So maybe this brainstorm should be extended to "applications not shown in the application menu".

What do you think?

Re: [Under Consideration] Command line applications and Extras
 

They should be outside of this. There are two things which fall into this category, OTTOMH:

• Desktop widgets/status area widgets/control panel plugins
• Plugins for existing systems (OMWeather themes, sharing plugins, telepathy plugins, gstreamer codecs, album art downloaders)

These are accessed through the GUI, and their description should make it clear what they do and how you access them. I think, therefore, they're out-of-scope.

Re: [Under Consideration] Command line applications and Extras
 

You're talking about something else, and it's a much more general issue that is in need of consideration and resolution:
http://talk.maemo.org/showthread.php?t=39073

Re: [Under Consideration] Command line applications and Extras
 

I still don't understand an advantage of another repository versus some section in regular one.

As I understand it is a call to separate a regular user from CLI stuff and it assumes that user would not execute it because he doesn't work with shell. But there are GUI packages which use CLI tools as library tool like ifconfig, awk etc. The separation of CLI tool would complicate an installation. Moreover, it is possible that some CLI tool may be considered as extra in some GUI package and user would have temptation to work with new repository because of that.

Re: [Under Consideration] Command line applications and Extras
 

I think it is two sides of the same problem.

Re: [Under Consideration] Command line applications and Extras
 

I for one would not feel punished if CLI apps were moved to CLI.

Apt is so much more efficient and easier to work in than the Package Manager (my experience comes from N810, mind you.) So often the packages I wanted to install were already hidden and would require Red Pill mode to see anyway.

But.. that's just my opinion. GUI for GUI.. CLI for .. well.. everything.

Re: [Under Consideration] Command line applications and Extras
 

Check the second-from-top users comment here:

http://maemo.org/downloads/product/Maemo5/mplayer/

Clearly, CLI apps need to be marked better in app manager. It is also bad marketing to have CLI apps in downoads/product section of maemo.org website. It creates the message that "this product is for command line users".

Still having CLI apps in a separate repository would be bad. For example many GUI apps use CLI apps (such as mplayer) as their engine.

I would suggest having CLI apps in a separate section (CLI/ ?) in app manager.

Re: [Under Consideration] Command line applications and Extras
 

I'm not so sure about that, command line applications are typically the most useful Linux applications.

Perhaps what is needed is clearer indication when a given package does not include a GUI, for example a little xterm icon and a warning message.

Re: [Under Consideration] Command line applications and Extras
 

Ideally, mplayer wouldn't have got through to Extras without using the standard icon (or badge) and including a sentence in its description:

(Assuming that it doesn't have the basic GUI like it did on diablo)

Re: [Under Consideration] Command line applications and Extras
 

[QUOTE=Jaffa;518234]Ideally, mplayer wouldn't have got through to Extras without using the standard icon (or badge) and including a sentence in its description/QUOTE]

I don't that is enough. Assume the following things happen:

1) users asks why his/her video doesn't play
2) forum people tell him/her to install mplayer
3) user finds mplayer from HAM and installs without bothering to look at icon or description
4) "it doesn't work, I didn't get any icon"

popup is not useful either, HAM is already polluted by the legalese popup so people just ignore them.

Separate section or "apt-get only" makes it clear, and means that forum users need to explain at step #2 that it is a command line application.

Re: [Under Consideration] Command line applications and Extras
 

FYI: http://talk.maemo.org/showthread.php...831#post558831

Brainstrom moderators: Please move this to implemented(solution 4)