Reply
Thread Tools
Posts: 237 | Thanked: 157 times | Joined on Dec 2009 @ San Diego, CA
#21
Originally Posted by j.s View Post
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.
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.

Last edited by go1dfish; 2009-12-13 at 01:02. Reason: Added reference to Ubuntu App Installer
 

The Following 2 Users Say Thank You to go1dfish For This Useful Post:
Posts: 4,556 | Thanked: 1,624 times | Joined on Dec 2007
#22
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!).
__________________
Originally Posted by ysss View Post
They're maemo and MeeGo...

"Meamo!" sounds like what Zorro would say to catherine zeta jones... after she slaps him for looking at her dirtily...
 

The Following 2 Users Say Thank You to Laughing Man For This Useful Post:
Posts: 968 | Thanked: 974 times | Joined on Nov 2008 @ Ohio
#23
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.
__________________
*Consumer*, not a developer! I apologize for any inconvenience.
My script to backup /home and /opt
Samsung Galaxy S Vibrant, Huawei S7, N900(retired), N800(retired)
 

The Following 3 Users Say Thank You to lemmyslender For This Useful Post:
Posts: 32 | Thanked: 9 times | Joined on Nov 2009 @ Norway
#24
Originally Posted by Laughing Man View Post
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.
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
 

The Following User Says Thank You to adrianp For This Useful Post:
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,681 times | Joined on Mar 2008 @ UK
#25
Originally Posted by adrianp View Post
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.
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 :-)

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.
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.

Of course I may have no idea what I'm writing about here
Sounds like a good plan to me, TBH!
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#26
Originally Posted by Jaffa View Post
Second most popular is Add a new catalog for all CLI and library items. Two obvious problems with this:
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.

Brainstorm rant:
+1
 

The Following 2 Users Say Thank You to lma For This Useful Post:
jukey's Avatar
Posts: 246 | Thanked: 204 times | Joined on Jun 2007 @ Potsdam (Germany)
#27
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?
__________________
-> Join the SailfishOS Meetup Berlin - every first Monday a month <-

Me on twitter
 

The Following User Says Thank You to jukey For This Useful Post:
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,681 times | Joined on Mar 2008 @ UK
#28
Originally Posted by jukey View Post
What about Plugins (for settings or status area)?
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.
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#29
Originally Posted by jukey View Post
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?
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
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#30
Originally Posted by Jaffa View Post
Using a debtag it could go through the normal QA process but the final promotion takes it from -testing to -cli.
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.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 23:23.