My ideas for changes to the way apps work.


I dont think its a good thing to compare us to Apple, i thought it was a selling point that pandora was not Apple.

There is no reason why the Pandora should not be as easy to use though, is there?

No your right it should be as simple as it can be. My hesitation to the apple comparison is mainly resource difference, they certainly have a lot more leverage than the community can offer. Not to say we cant match, but in some situations we may under perform or not look as flashy. Or it may just take longer.


Reading the posts after we should pull the goods ideas, apply them to the existing projects (for the reason i gave above).


I think many are quick to criticize your ideas Craig cause you didnt seem to suggest (and have obtained the reputation (granted or not)) of not wanting to improve existing projects.


Is it possible to apply these ideas if they make sense to the pndstore?
 
I think the easiest solution to this problem is to sell Pandoras with software preinstalled SD cards with instructions.


These cards could be user specific according to what the buyer is looking for.


Or there could just be an 'all in one card'.


Adjust $$ accordingly.
 
Last edited:
Scanning the root and +1 directories is a good idea.


For the naming convention, i strongly suggest :


NAME VERSION ARCH BUILD ORIGIN


picodrive-1.80-armv7a-1_Apps.pnd


or


qbittorrent-1.3.3-armv7a-1_Repo.pnd
 
Filenames shoudl be friendly, imho; the versioning and detailed app info is already _in_ the pnd, why put it on the filename? Sillyness, I say ;)


jeff
 
Filenames shoudl be friendly, imho; the versioning and detailed app info is already _in_ the pnd, why put it on the filename? Sillyness, I say ;)


jeff
If I'm understanding this right (I'm probably not), because Craig doesn't want to open the files when he scans them, to make the scanning quick? So you can place PNDs anywhere on your SD card, but if they're named even slightly off from the correct format, they won't be recognized correctly. Yeah... user-friendly...

I think many are quick to criticize your ideas Craig cause you didnt seem to suggest (and have obtained the reputation (granted or not)) of not wanting to improve existing projects.
Yes, I do get the feeling that Craig likes to have control. It allows him to stay focused and organized, but he's also the last person in the room to recognize a good idea that doesn't come from himself.

Interesting to see the person who started all the bullshit about the appstore has vanished, which was the whole reason I didn't want to use someones elses software - if they vanish you're stuck.
Of course, the thing about open-source software is that others can pick it up, which is what happened.
 
Last edited by a moderator:
Shh, I was waiting for Craig to say it ;)


Yes, you can put version info in filenames, but then you run the risk of any old file rename totally breaking things :)


More to point, the PXML and icon and such are in there _anyway_; you can't scan a filename and get the icon out of it magicly, nor can you find out if it runs with or without X11 etc (midn you, few apps use such options, but ti can matter.) But very specifycally --


Scanning a filename does not..


-- get you icon


-- get you categories


-- etc.


You need to look in the pnd _anyway_, and thats the rub.


--


Options are to use subdirectories to manage categories, for which I point you to loooong discussions we've had in the past, where we imply category based on path; I forget if I put that into libpnd or mmenu yet or not. But it still doesn't get you icon.


--


We _have_ thought about these things, we didn't just make shit up off the top of our heads :)


jeff


edit: okay, sure, you coudl pull out the icon once and cache it .. thast what we do now. Coudl also cache the version info, without polluting the filename with it.


We can do all that now, without breakign the repo specs or anything; I've implemented cachign into mmenu and libpnd before, but not committed it, and someone else was working on a better form of caching awhile back but vanished. But thats neither here nor there.
 
Last edited by a moderator:
I'd like to point out there is one MAJOR flaw in Craig's reasoning.

Right, great, I'm sure Apple would move to this system if you just showed them it!
That IS how Apple does it. The Apple and Google stores are not websites that you visit through your browser, they are applications that run on the device (or on your PC, especially in Apple's case) that communicate back to their respective hosts via a custom http request. This app (or perhaps a similar one, with no front end but acting as a daemon) is then responsible for keeping them up to date.


This is almost exactly how PNDStore works. It is PNDStore that is doing it the way the big names are doing it. Your AppStore is the deviant. Way, way back when you first started working on it, I told you exactly how to set it up so there would be an icon on the desktop that said "Download Apps" that would take you to the web store and would allow them to download apps and those apps would go into the correct directory on their SD card. As far as an end user was concerned, it would have just worked, behaved just like the Apple and Google app stores. Easy. You chose to ignore that advice. Now that someone has implemented something that does behave in this way, intuitive, easy, automatic, you're crying foul.


You are the person who has repeatedly chosen to do your own thing, purposefully ignoring suggestions that would start to go towards solving the very problems you are now saying you are receiving complaints about. You could have implemented the AppStore how I suggested a year ago, and downloading on the Pandora would be a snap and require no thought. You could have agreed that the app store protocol that the users developed was a good idea, even contributed to it yourself, which would make it easy for all apps to be kept up to date no matter where it was downloaded from or how it was installed, but you said it wasn't necessary, that if other sites wanted your data they could just screen scrape.


You say you don't want to be difficult, but with every suggestion you outright reject you belie that stance. You want to be part of the community, be part of the Gordanged community! Don't say "that idea sucks" and implement your own idea, and then complain when something community developed supersedes your idea: by that point in time it is too late for complaints; you had your chance to shape the software and you ignored it.


For Pete's sake, Craig! Why does everything you do have to be done your way? You are not a bad guy, but you are stubborn to a T sometimes. You're allowed to be wrong, make mistakes, give bad suggestions. You're as human as any of us and that is what we humans do! We try something, we fail, we try again, we get closer, we communicate, we share ideas, we improve, and eventually we succeed.
 
I'm sure every "casual gamer" will immidiatly be friend with that suggestion.

:/ Craig said

"Pandora Apps adds a key to the file names which are downloaded eg:
'Snes9x.pnd' would become 'Snes9x.Pv1.PND'"

But indeed this naming was a bit misplaced. Better this :


NAME VERSION BUILD ORIGIN


picodrive-1.80_Apps.pnd


or


qbittorrent-1.3.3_Repo.pnd
 
Last edited by a moderator:
Sounds good to me Jeff.......MAKE IT SO! :)


Chris
 
Last edited by a moderator:
...


So..


Steps are..


1) you add repo spec support to your site (easy, and big wins)


2) we add pndstore (say) to hf6 nand


3) we get templer/whoemever to add command line support to pndstore, in a standardized way (so that other upcoming repo clients can offer the same function to mmenu/etc)


4) mmenu uses cmdline api to repo client to find out about possible updates, or to apply udpate requests


Easy pleasy, no rocket science, just logical steps that we take, one after the other. It'll take a few weeks of work to do it, subject to developer availability. (Sorry, I'm a pro, I talk like that :)


I'm agreeing with you, but trying to do it in a standards way, where standards are things we already have built over the last year or two.


jeff

This makes perfect sense to me, come on Craig, make it so!


@Craig : It's time to let go of the reigns a little. A great strength of Pandora is the community aspect, the community are pretty clear what they want. Why not give the nod, let the organic growth of Pandora standards continue and if you don't like the result in 2 months suggest another way.


What's been suggested here is more than easy enough for your typical pandora user. Using PNDstore for updates is superb, sure it's a little rough round the edges but it's a diamond that will polish up a treat. Adding this into minimenu with notification icons is also pure win.


It's a huge job to make a system user friendly for noobs, my understanding is you tend to be pretty pushed for time, there are talented people making Pandora better for free, encourage them to continue. Look at the Repo & PNDstore for what they are, i.e. a huge improvement on existing alternatives which were provided by the community, don't make the mistake of emasculating this kind of thing before it has the chance to grow.


It seems to me we stand at a crossroads....


PS Craig, it is really heartening to see your dedication & commitment to Pandora and your determination to bring it to a wider market. Viva la Pandora !
 
We're still at the beginning of a lot of things..


You may rercall a couple months ago where I mentioned integration of somethign like pndstore into mmenu -- ie: coudl make a call to pndstore (or equivilent) that woudl return a list of app unique-ids that have updates.


Mmenu coudl then show a badge on the icon to indicate upgradable, and offer two options..


1) upgrade all


2) upgrade this icon you're poking


Then it woudl invoke pndstore (or equivilent) to do the actual udpate task.


Abstracting it out of mmenu using a simple little command line interface means the actual technology douing the updates can be replaced or configured as to user preference.


--


The repo spec we have now fulfills this stuff pretty easily; coudl also add additional oepration 'can you check this particaulr app for me' perhaps to make it easier for tools to use, but right now its 'suck down the list of everything on repo, and app can do whatever it wants', which is okay too. (JSON is trivial to produce and parse)


--


So..


i) Scanning root of SD is somethign can add, as discussed other thread (and somethign I've been mulling around for quite some time)


ii) Scanning root + one more ... that coudl balloon to a lot of dirs still, but doesn't sound too bad on the surface. (And _yes_ Craig, scanning directories _can_ be very slow .. depending on the number of files, the type of media, the type of device; you're assuming a small class 6-10 SD but what if its a slow giant SD, like a class 4 64GB SD? Or w a external hdd on USB, with slow spin up, etc? We have to allow for average case, but also for edge cases :)


iii) I think pndstore is still young, it does need a cleaned up UI etc, but its not bad; it (or equiv) shoudl be in NAND for hf6, and in the menu


iv) I think if pndstore (and others, since a couple more are in the works) add command line interface, so that mmenu (and others) can ask them 'list updates' and 'do update for app x', then we can simplify the experience via mmenu and xfce


1) add "update all" menu to xfce, which just calls cmdline pndstore to do it


2) optionalyl enable pndstore scan every Xth connection to the net? (configurable to disable it)


3) mmenu could add badges to the icons as mentioned above


--


I think a lot of ideas have been bouncing around, but we shoudl be careful to proceed in an organized fashion :)


We have built lots of cool tech, we shoudl leverage it.


jeff

This is preposterously complicated.


All you have to do in minimenu is the following and we all win and it's the most efficient AND optimised solution:


Scan the root and one level deep for PND files.


If the app name contains a source, call the URL and see if the file is the latest version (you can of course have an option to disable this).


That's it.


I don't understand this obsession with wanting to make this over complex. It is what is killing the user friendliness of the Pandora and seriously - it's upsetting me to see this situation becoming an issue for new users.


I'm also depressed that you keep mentioning this scanning DIRs myth. Right now I think you open the files to extract things - I don't want you to open them for this search until afterwards - once you have indexed their locations. DOS could scan all the ROOT dirs in a couple of second in 1992. Things have only increased in speed since then. And mentioning scanning a HDD, for heavens sake, this is a portable console.


Why does everything like this have to result in such petty points being brought in to the debate? Can't you see this is WHY these projects never reach user friendliness of closed projects like the iPhone? This is why Ubuntu is never going to go mainsteam - because they cannot just 'do' things, everything is a huge pointless argument.


There should be a Pandora motto here, above all the user friendliness comes first. If that means dropping an app someone has spent a long time writing because we can incorporate it's functions in to fewer clicks then so be it, we have to be brutal to push forward to the next level or we will be stuck with what will essentially be a really cool developers little computer and nothing more.


When I send out review units I have to spend hours setting up and SD card or I know the direction the review will take, that the Pandora isn't user friendly enough for the man in the street.


These posts are me trying my hardest to make even the most hardcore stuck in their ways devs please realise it is killing the project to not make things easier and simpler as soon as possible.


There isn't anything more I can really say. I have the most direct contact with the customers and reviewers. I'm telling you what is happening. I don't want to have to write all the software myself, that's why I'm trying to convince Jeff to add it to minimenu, but if I have to I will write it and push it on to the system.


I know I don't have the time to do that, but I'm sure I'll find a way if I have to because for the future I know it has to be done.
 
We're still at the beginning of a lot of things..


You may rercall a couple months ago where I mentioned integration of somethign like pndstore into mmenu -- ie: coudl make a call to pndstore (or equivilent) that woudl return a list of app unique-ids that have updates.


Mmenu coudl then show a badge on the icon to indicate upgradable, and offer two options..


1) upgrade all


2) upgrade this icon you're poking


Then it woudl invoke pndstore (or equivilent) to do the actual udpate task.


Abstracting it out of mmenu using a simple little command line interface means the actual technology douing the updates can be replaced or configured as to user preference.


--


The repo spec we have now fulfills this stuff pretty easily; coudl also add additional oepration 'can you check this particaulr app for me' perhaps to make it easier for tools to use, but right now its 'suck down the list of everything on repo, and app can do whatever it wants', which is okay too. (JSON is trivial to produce and parse)


--


So..


i) Scanning root of SD is somethign can add, as discussed other thread (and somethign I've been mulling around for quite some time)


ii) Scanning root + one more ... that coudl balloon to a lot of dirs still, but doesn't sound too bad on the surface. (And _yes_ Craig, scanning directories _can_ be very slow .. depending on the number of files, the type of media, the type of device; you're assuming a small class 6-10 SD but what if its a slow giant SD, like a class 4 64GB SD? Or w a external hdd on USB, with slow spin up, etc? We have to allow for average case, but also for edge cases :)


iii) I think pndstore is still young, it does need a cleaned up UI etc, but its not bad; it (or equiv) shoudl be in NAND for hf6, and in the menu


iv) I think if pndstore (and others, since a couple more are in the works) add command line interface, so that mmenu (and others) can ask them 'list updates' and 'do update for app x', then we can simplify the experience via mmenu and xfce


1) add "update all" menu to xfce, which just calls cmdline pndstore to do it


2) optionalyl enable pndstore scan every Xth connection to the net? (configurable to disable it)


3) mmenu could add badges to the icons as mentioned above


--


I think a lot of ideas have been bouncing around, but we shoudl be careful to proceed in an organized fashion :)


We have built lots of cool tech, we shoudl leverage it.


jeff

This is preposterously complicated.


All you have to do in minimenu is the following and we all win and it's the most efficient AND optimised solution:


Scan the root and one level deep for PND files.


If the app name contains a source, call the URL and see if the file is the latest version (you can of course have an option to disable this).


That's it.


I don't understand this obsession with wanting to make this over complex. It is what is killing the user friendliness of the Pandora and seriously - it's upsetting me to see this situation becoming an issue for new users.


I'm also depressed that you keep mentioning this scanning DIRs myth. Right now I think you open the files to extract things - I don't want you to open them for this search until afterwards - once you have indexed their locations. DOS could scan all the ROOT dirs in a couple of second in 1992. Things have only increased in speed since then. And mentioning scanning a HDD, for heavens sake, this is a portable console.


Why does everything like this have to result in such petty points being brought in to the debate? Can't you see this is WHY these projects never reach user friendliness of closed projects like the iPhone? This is why Ubuntu is never going to go mainsteam - because they cannot just 'do' things, everything is a huge pointless argument.


There should be a Pandora motto here, above all the user friendliness comes first. If that means dropping an app someone has spent a long time writing because we can incorporate it's functions in to fewer clicks then so be it, we have to be brutal to push forward to the next level or we will be stuck with what will essentially be a really cool developers little computer and nothing more.


When I send out review units I have to spend hours setting up and SD card or I know the direction the review will take, that the Pandora isn't user friendly enough for the man in the street.


These posts are me trying my hardest to make even the most hardcore stuck in their ways devs please realise it is killing the project to not make things easier and simpler as soon as possible.


There isn't anything more I can really say. I have the most direct contact with the customers and reviewers. I'm telling you what is happening. I don't want to have to write all the software myself, that's why I'm trying to convince Jeff to add it to minimenu, but if I have to I will write it and push it on to the system.


I know I don't have the time to do that, but I'm sure I'll find a way if I have to because for the future I know it has to be done.
Why don't you just send Pandoras with already 'set up' sd cards per request??


Why is this not easier for the user and OP??


Sorry, but I just don't understand .
 
Last edited:
My 2 penn'orth:


My (admittedly limited) contact with Apple devices is that there is a button on the screen that links you to iTunes, where you choose and app. It downloads, and is them available to play/run/whatever. I assume that a background process occasionally (or when you load iTunes) for updates.


So we need an app that is included in the firmware by default, that appears on the desktop and connects to the app store / repo of your choice (probably customisable on first run). It presents the apps, you choose and download. The user gets a request to ask where it should appear (menu, desktop, both, possibly with configuration options so we can decide which "folder" it's to go in - emulators, games etc). It puts them in the correct place on your SD card.


This way the user doesn't have to bother with the correct place, and we get to keep the very sane locations we have at present. The app could also have options to move apps from one place to another and check for updates (automatically if wished).


So new users, when they turn the Pandora on are asked for their basic details (name, password etc). The first screen they see is either minimenu with the "app store" or "app repository" (your choice) application, or the desktop with the same icon if they boot straight to XFCE.


Advanced users can still download and place wherever they like. Of course, this doesn't solve problems of where to put the ROMs (though we could have an option to open the Appdata folder for an app in the file browser from the app-store application), but you've got to start learning somewhere.


And there's no need for "new users read this.txt" on the desktop.


D.
 
File association for PND in the browsers.


Prompting you:


* Install location? left SD, right SD or other. (Tell you size and label of SDs for the forgetful.)


* Launch from? menu, desktop or both.


* Run the application now? Yes or no.


Install a PND, creating the folder structure if needed. (pndstore? sorry haven't tried it yet.) Need browser integration, so user-friendly installing works from any website with a PND for download.


RSS feeds of new releases, most downloaded, highest rated, updated versions - could be pre-installed in browser bookmark toolbars.
 
Last edited by a moderator:
It's late, i'm tired, need to get up early, no joy to read into detail.


But overviewing the thread, i'm missing something.


Craig, your newbee troubles could be reduced with some kind of introduction documentation on the desktop or in minimenu. Yes, i know, people don't like reading docs, how about an introduction GAME how to use the pandora? A quiz or "did you know" tutorial. Anything interactive?


On the other hand, why do you want to make the pandora luser approved? You can't produce enough pandoras to feed them and if you keep the price in mind, you'll miss that target group for sure.

'Snes9x.pnd' would become 'Snes9x.Pv1.PND', doing this removes the need to 'repack' the PND, but marks it so minimenu can see where the app has come from 'P' (for pandora apps) and the version of the app (v1). It's quick and simple.
I see why you want to trace back to the source of the pnd. The maintainer will update that one if he choosed that repo/whatever for publishing. I like the idea with the automatically version number of the file. (Doing it during upload into the database will reduce later renaming for history on the user side).

My first thought about the download source tagging into the filename was: Branding.


Well, crediting the source is a respectable thing, it was done long time ago by the file_id.diz file included into many file archives of BBS systems. I'm not sure about how the sequence of evolution was, but stand alone BBS systems like remote access or maximus got somehow connected into a network, doing file transportation for free- and shareware over the POTS by modems. Those networks were working together to reduce high telephone cost of long distance calls. They invented automatic file distribution as well, sharing the same files on their systems for the benefit of users. The automatic distribution used the file_id.diz to gather the file description and created a filelist of the available files. I see you re-inventing the wheel somehow. :D


Well, modern times makes things faster and opens unforseen possibilities of the past. Shareware authors used the remote data transmission for spreading their work over the land. Today, they restrict the distribution referring to copyright law, for - what for? Getting page hits and knowing how popular their work is?


The pandora is based on open source. It is based on sharing. Giving software to others and to provide their right to share it with more people. That's why it hurts as branding comes into my mind.


Following the spirit of sharing i can't see any reason why different appstores or repos (or whatever you like to call it) shouldn't share and sync their file archives. That way there is no need for branding. Additionally it will give us backups of the file archive.


The appstore and repo operators will share the same files but can do their own frontpage or functional layer for their web presence.


So please keep this spirit in mind. Do not annoy users by forcing them to one source only. Don't forget those background sync and share the file archive as easy as possible for site operators.
 
craig, listen to your people. and pickle said it best, not being an apple product is one of OPs main selling point
 
Let's not talk about a Pandora 2 yet .

it's upsetting me to see this situation becoming an issue for new users.

i've been lurking these forums for quite a long time and, honestly, haven't seen much complaints about PND system. On the contrary.


We all know you are the boss, you get more feedback. Let's move on. I agree with making it more and more user-friendly, but I really don't see Pandora changing its niche to satisfy apple fanboys. Not gonna happen imho. Downloading apps from official repo or milkshake's one or even PNDStore are very straightforward . A little note would have prevented new users' doubts.


Having all those pandora shipped is far far more important atm. It will bring more people to help development, the new firmware, the path to Pandora 2.0
Please no talk about a Pandora 2 yet.
 
Theres no dispute over scanning root if SD, its been on my list for quite some time. (I'm goign to go one further, since I like the idea you had there of scanning tiop 2.. I'm going tyo make it configurabhle to depth-N on a per-chunk basis, so some dirs coudl be deep forever,l some coudl be 1 level, some coudl be 2, etc. User configurable as always, but default to sensible.)


The proposal that we scan filenames to find url hints, to then do url polls back to see whats updatable and then some other mechanism to suck down replacements.. its doable, but why make another system when we have a perfectly workable system that doesn't pollute the filenames, etc. (Remember, mmenu _already_ knows all the details about an app, it just needs a master source to get the updated list from so it can show the updated apps.)


And guess what.. that file is the JSON repo spec :)


ie: The easiest way to do it then, for mmenu (ignoring xfce :/) is --


Given: mmenu knows everything about the apps it found already, a given (it knows version and everything)


1) Post the app-unique-id and version-id to URL, and the URL responds with 'current' or 'older' or 'newer', and


2) then the app can do a wget to suck down a replacement app to a tmpdir, and when complete, can move it over the existing one.


I would _not_ want to pollute filenames (and seems pointless); if you want it go to to one place, just make the store configurable and be done with it.. suer can pick appstore or repo.wahtever and good to go.


(Your only reason to pollute filenames is to put version info in there, and mmenu already knows that stuff.)


I'd say how would xfce users update then? But you'd say to make a menu item, that just invokes 'mmenu -updater' which would do its thing, and that'd work.)


jeff


BTW, pnd-system is one of the easiest systems ever devised for any platform, ever; really, I'm pretty pleased how it works out... I've had Windows and OSX users telling me they wished it was that easy on those platforms. And we're just a few blokes :) I like to shoot higher, but I think we did okay. I think you should be pretty happy with how we did in our spare time :)
 
Back
Top