Active Topics
-
Porting apps to Leste (49)
to Maemo 7 / Leste by teroyk - 3 hrs, 7 mins ago -
Maemo repository (39)
to Community by teroyk - 3 hrs, 22 mins ago -
Help needed to recover from botched user config preventing boot (8)
to MeeGo / Harmattan by nphuracm - 1 day, 9 hrs ago - more...
| The Following 2 Users Say Thank You to go1dfish For This Useful Post: | ||
|
2009-12-13
, 01:50
|
|
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!).
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
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...
|
|
2009-12-13
, 02:37
|
|
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.
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)
*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)
|
|
2009-12-13
, 13:37
|
|
Posts: 32 |
Thanked: 9 times |
Joined on Nov 2009
@ Norway
|
#24
|
Originally Posted by Laughing Man
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.
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.
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: | ||
 |
|
2009-12-13
, 13:52
|
|
Posts: 2,535 |
Thanked: 6,681 times |
Joined on Mar 2008
@ UK
|
#25
|
Originally Posted by adrianp
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 :-)
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.
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
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
|
|
2009-12-13
, 14:36
|
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#26
|
Originally Posted by Jaffa
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.
Second most popular is Add a new catalog for all CLI and library items. Two obvious problems with this:
Brainstorm rant:
| The Following 2 Users Say Thank You to lma For This Useful Post: | ||
 |
|
2010-01-08
, 16:17
|
|
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?
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?
__________________
| The Following User Says Thank You to jukey For This Useful Post: | ||
|
|
2010-01-08
, 16:23
|
|
Posts: 2,535 |
Thanked: 6,681 times |
Joined on Mar 2008
@ UK
|
#28
|
Originally Posted by jukey
They should be outside of this. There are two things which fall into this category, OTTOMH:
What about Plugins (for settings or status area)?
- 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
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 |
|
2010-01-08
, 16:24
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#29
|
Originally Posted by jukey
You're talking about something else, and it's a much more general issue that is in need of consideration and resolution:
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?
http://talk.maemo.org/showthread.php?t=39073
__________________
Unofficial PR1.3/Meego 1.1 FAQ
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?
|
|
2010-01-12
, 20:14
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#30
|
Originally Posted by Jaffa
I still don't understand an advantage of another repository versus some section in regular one.
Using a debtag it could go through the normal QA process but the final promotion takes it from -testing to -cli.
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.
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