My ideas for changes to the way apps work.

[NoeleyC]

Pandora Apps adds a key to the file names which are downloaded eg:


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

Could you not use a CRC or Hash of the file to identify versions? Otherwise you potentially have several "version 1"'s that came from different sites, but are the same app

would these added repo details be added no matter where you download the PND fto (eg. an ordinary PC), or only if you're downloading it to the Pandora directly?

 

[NoeleyC]

yeah, but even easier --


- Trigger is irrelevent; it could be automated or not for either approach, so no need to discuss for comparison


- Version isn't really relevent, since its already known -- we're mostly talking mmenu here anyway, which especially knows all details all the time its up (from the PXML); so marking up the filenames is totally unnecessary there.


-> ie: why put it in filename, when mmenu already knows it


-> linux distros do it because it can be handy, but in those distros, the user never sees the package; its just one of 50,000 files on his hdd; we're talking about files visible (now possibly at root of) SD; which might well have filename length limit on a FAT16 card even


mmenu calls update-tool and says 'tell me current versions of stuff on repo', then internally compares (instantly) and shows 'updatable' badge on updatable apps (think 'apt-get update', and mmenu then showing the badges, and then doing apt-get for the desired app(s))


For xfce, have a pop up come up listing updates.. a la pndstore now.


jeff


Not sure if a debate will go anywhere, thats my worry


We shoudl just build it, and go

+1 for that from me anyway (for what it's worth). A simple menu selection to tell me what updates are available to what's on my cards already, and a PNDstore (or equivalent), for downloading new software directly sounds perfectly good to me!

 

[Caine]

Here's my take on the discussion.


Filenames are an absolutely horrible place to store your metadata. End-users should be able to modify these without breaking the application or update system.


I'm not sure that scanning only two levels deep for PNDs would be intuitive. If a user decides to add some structure to her application directory then it wouldn't work.


The update mechanism has been implemented nicely in the REPO spec. Implement support for this in all repositories and include the PND_Store application in the firmware (for XFCE, place it on the desktop for maximum visibility). If the PND_Store and/or repo spec are insufficient, then present and discuss use-cases such that we can improve them rather than building yet another way of doing things.


To address first-time install problems, perhaps some of the following approaches could be utilized:


@XFCE:


Add a small launcher applications for PND files to the firmware and associate PND files to this app by default.


The app presents a simple GUI, e.g.:

install to | SD1 SD2

-----------+--------

menu       | [ ] [ ]       <--- checkboxes or radio buttons

desktop    | [ ] [X]

-----------+--------

[Run App]  [Install]       <--- buttons

If you click install the application shows a simple dialog explaining the pandora/menu,app,appdata,desktop structure and copies/moves the PND to the flagged locations. If you hit [Run App] it passes the PND file to pnd_run.


[edit]Quick mockup image. It doesn't needs to be more complex than this.[/edit]


@Minimenu:


Add an option to perform a deep-scan for PND files (e.g. "scan for new PNDs") and update the PND search-path (i.e. add the topmost directories which contain at least one PND file to the PND search-path and remove the directories in the search-path which no longer contain PNDs in any of their subdirectories). Alternatively, present the user with a GUI to move the PND-files to the proper location instead (similar to the XFCE approach).

 

[dgame]

<bikeshedding>


Please make scanning of the SD cards' root directory optional.


Please make scanning of any tree other than the "pandora" directory optional.


If this 'lets-just-scan-everything-because-its-not-like-the-PND-system-isnt-one-of-the-coolest-sytems-already-and-the-pandora-folder-structure-is-clearly-outlined-in-the-wiki-and-evil-dragon's-earliest-videos-showed-how-it-works-but-now-we-want-to-be-like-adobeapplemicrosoftsonynintendo-instead-of-just-including-better-newbie-instructions-ON-the-Pandora' PND scanning system is implemented please provide an easy way to turn this new 'feature' off.


Thanks.


</bikeshedding>

 

[WizardStan]

It already is optional. Jeff just made it even more optional. "Easy" is relative though. Is a config file easy enough, or do you want a gui to go with it?

 

[bzar]

Any eager coders in the community without anything to do? Doing a config file editor (I mean with sensible controls for each setting) for customizing stuff in /etc/pandora/conf shouldn't be too demanding if you've done some GUI coding before

 

[Linopoly]

Here is what happens:


Casual gamer buys Pandora.


Casual gamer downloads various apps.


Casual gamer puts apps in root of SD card (or a folder they have made and named at random 'games' 'steves emulators' ect.


Pandora does nothing.

I'm beating a dead horse here, but I don't think additional scanning is needed to solve this. Instead, when no PNDs are detected, Steve the casual gamer should see an invitation to open a prompt where they can read about the system. While they're reading, the software would scan their SD card in the background. Any detected PND files on the SD card would be listed at the bottom as they are found, with an offer to move all of them to the right place. This extra scanning wouldn't affect normal users, and chances are it would be fast, since casual Steve probably has a less well populated SD card than Stevette the poweruser.


A second thing, just for polish, would be that if the user tries to open a PND file while browsing files on the SD, they are presented with basically the same thing, which would move the file(s) to the right place on the SD card. This is like this suggestion, but I don't think the options are needed, just a prompt to explain where they're supposed to go, and a button to move it to the menu folder. People who prefer desktop icons should be able to drag them to the desktop from the menu, even if this means some complication behind the scenes to fit with the existing PND design.


I think everyone else has already suggested a good solution to the other problem, which is for the official app repo to support the repo spec server-side so that we can ship an "app store" app in the default firmware that does one-click installation. I can't resist also mentioning that before this was called an app store, Linux users called it package management. Apple may have made it popular in a commercial/mobile context, but they didn't invent it.

 

[milkshake]

I think everyone else has already suggested a good solution to the other problem, which is for the official app repo to support the repo spec server-side so that we can ship an "app store" app in the default firmware that does one-click installation. I can't resist also mentioning that before this was called an app store, Linux users called it package management. Apple may have made it popular in a commercial/mobile context, but they didn't invent it.

We will still have an app-store program even if Craig does not update his "official" app store, it would just be better if there were more sources available for the "app store".


One other thing I can mention about the current "official" app store is that some of the apps on the store are so old that they may not conform to PXML specs, what would happen with those?

 

[Caine]

I just wrote a simple first version of an installer front-end which can be associated with PND-files and prompts the user to either run it or install it to SD-card.


Please find the script attached below. It should not require any additional dependencies.


One question though. Can I rely upon the paths /media/mmcblk0p1 and /media/mmcblk1p1 to always point to SD card 1 and 2 respectively?


[edit]Answered and solved.[/edit]


Naturally, remarks and/or feature requests are welcome.


[edit]Updated script. It should now determine the SD-card mountpoints properly.


pnd_install.py.tar.gz


[/edit]

 

[skeezix]

The name in /media/ is the detected volume name (ie: partition label)


If you name your SD "Fooby" it'll be /media/Fooby, unless it is unreadable for whatever reason.


You probably didn't name yours


Also, those generated names are not reliable, since it depends on order of insertion/detection of the SD, and if you yank out and back in at suboptimal times (while mounted say) then you'll get an ever increasing number in the mmc name. So no


jeff

 

[Caine]

Also, those generated names are not reliable, since it depends on order of insertion/detection of the SD, and if you yank out and back in at suboptimal times (while mounted say) then you'll get an ever increasing number in the mmc name. So no

Ah, I found a post from a while back which claimed something similar with the remark that ED was working on it. Apparently nothing has changed in the meantime.


So, ehh...is there any way to reliably and generically determine the SD-card mount points?

 

[milkshake]

maybe when the *root* search finds any pnds this script could auto run? thats would be cool.

 

[WizardStan]

So, ehh...is there any way to reliably and generically determine the SD-card mount points?

run mount and awk for /dev/mmcblk0p* and /dev/mmcblk1p*

 

[Caine]

Ah yes. Thank you sir.

 

[EvilDragon]

Okay... here is my view of the things.


Let's see what our goals are:


* For the user:


Installation of apps as easy as possible.


The easiest way is something like MacOS, Android, Ubuntu, iPhone, etc. does: Open your appstore, browse through games and click on them to install them.


Including screenshots, information, etc.


And tell him how to do it.


* For the developer:


Make it as quick and easy as possible to offer his stuff to users (either via a repo or on his own website).


* Other stuff:


The system should prevent errors as much as possible.


It should also be as flexible as possible.


How do we accomplish that?


* For the user:


There will probably be two types of users.


Some want to use an appstore that handles everything.


Some want to copy their stuff to the SD themselves.


We already got a first version of an appstore. It retrieves the list from the repo, install apps, remove them, check for updates and install them, etc.


It's missing some stuff like categories, a nicer GUI, the ability to pull preview pics, but that's about it.


PNDStore has just been created and the basic features are working, so this is the right step for me.


For the users who want to copy the PNDs to the SD Card themselves, skeezix added scanning the root folder (without subfolders) as well.


Together with a preinstalled quickstart instruction guide, this should be all the user could be dreaming of.


Either copy the PND manually on the card or use PNDStore to automatically update it or do a mixture of both.


* For the developer:


Thanks to the standard PXML and PND system, distributing files for the users is pretty easy already in a convenient way.


It's expandable without breaking old PNDs, so everything is possible.


Stuff like description, version number, screenshots, etc. is included, so uploading it to a repo that can parse PXMLs is extremely fast and easy.


* Other stuff:


Thanks to a repo parsing the PXMLs, the dev doesn't have to enter a description or the version number multiple times. This is convenient and also prevents any errors. It's easy to accidentally mistype the version number.


Also, a PND can be renamed and distributed on 3rd party sites with wrong descriptions, etc. - once the user copies the PND on the SD Card, the original information from the author can be readout.


* Current Issues:


Here are some issues I personally found:


1. Nobody knows where to copy the roms / bios / datafiles


Well, there is not much that can be changed here - that's up to the developers.


The PNDs I created check if the datafiles / bios are there and notices the user, if it's missing and where to put it. I also put an explanation into the manual.


There's not much more that can be done here, as those files ALWAYS have to be copied manually.


2. Users can't figure out where to copy the PNDs and how to install games


This has been taken care of already. We will include a manual and make an optional Tutorial at the end of the first boot wizard.


The root of the SD Card can also be used for PNDs in the near future.


The PNDStore is also great for installing games, with some improvements, it's perfect.


That's basically it... so here is what I think we have to do:


a) Improve milkshakes repo so it looks nicer (he is already working on that). Craigs appstore has a nice design IMHO.


B) Include a PXML parser into Craigs appstore for easy uploading as well as the API so PNDStore can use it.


c) Include a small tutorial into the system so new users will know what to do


d) Improve PNDStore:


* nicer GUI


* Categories support


* Screenshots


* Allow multiple sources (so that any dev could create his own site with PNDs with the API support)


e) Include PNDStore into the OS as well.


Unless someone has a fully working easier solution, this would be the best we can do.


Easy to use for anyone, flexible, stable.

 

[skeezix]

Can you get craig to buy into this?

 

[EvilDragon]

Can you get craig to buy into this?

I have no problem if there are multiple solutions out there, but before we can implement anything anywhere, it needs to exist.


So if someone has a simple, working solutions (as I described above) already coded, I've no problem using that.


Right now, I think we did the right start, as the foundation we created has everything needed to make stuff even more user friendly.


The only thing missing is the polishing, like an optimized appstore and stuff like tutorials, etc.


Honestly, I can't think of ANYTHING more user friendly than selecting "Install software" in the menu and then select what software he wants to have on his SD Card.


We already HAVE a way to automatically update PNDs, so there's no need to reinvent that. It's there, it already works, I'm doing this for weeks.

 

[Tempel]

I fully support ED's proposal. Regarding improvements to PNDstore:


*nicer GUI


Totally. This is my first attempt at GUI design, so it's going slowly. I would love it if anyone is willing to help a bit with it; otherwise, I'll improve it gradually.


*Categories support


Categories are already parsed and stored, they're just not yet presented to the user. All this needs is that improved GUI.


*Screenshots


This'll take a little more effort, but it's already on my (ever-growing) list.


* Allow multiple sources


Already supported. Additional repositories can be added to the config file; upgrades are pulled from whichever repository has the highest available version of a particular PND. Of course, a GUI method to add repos would be good; this, again, comes with the improved GUI.


I'll also add that it's trivial for me to add a scriptable command-line interface to PNDstore, which could allow it to be integrated with minimenu. skeezix has brought it up before, but I can make it a priority if we want it included in HF6.

 

[sebt3]

The most common problem I deal with in customer support is people not knowing how to use the Pandora.

May be try adding a little post-it with just this url : http://pandorawiki.org/User_manual#Where_Can_I_Get_More_Apps.3F in every package you send.

 

[Esn]

I fully support ED's proposal. It seems very sensible. Thank you so much, ED, for bringing order to chaos yet again. And for being so patient; I don't know how you do it.


Just a few notes:


I'm not sure if this was already answered, but if I decide to NOT keep files in the root, can I still keep them in the same paths as before? (so files in desktop folder will show up on the desktop, files in menu only in menu, etc.) Maybe there could be an option somewhere to disable root-scanning, just in case I want startup to be a bit quicker?

1. Nobody knows where to copy the roms / bios / datafiles


Well, there is not much that can be changed here - that's up to the developers.


The PNDs I created check if the datafiles / bios are there and notices the user, if it's missing and where to put it. I also put an explanation into the manual.


There's not much more that can be done here, as those files ALWAYS have to be copied manually.

I think there is one thing that could be done here to help a little. Make "documentation" from the PNDs easier and faster to open. Arora is horrible for this purpose; it takes ages to load. In minimenu, a PND documentation viewer should be built-in.


As of right now, a user is discouraged from reading documentation because it's so inconvenient to open it.


Also, a comment on Craig's vision from this post:

The way the Pandora functions needs a radical overhaul and some people don't like the idea even though it would likely not even effect them (the system is open, You can run what you want how you want).


I'm preparing a txt file presenting some surprising alterations on how things should work.


Of course the purpose of them is just to make the system more simple, more i-like.


My vision is essentially a front end (be it minimenu or be it written from scratch) which does EVERYTHING related to organising, running, updating, downloading files (etc.).


Let me explain an example:


You install UAE4ALL and then you click it to run.


The front end will do some magic here behind the scenes, it will look for the kickstart rom, if it isn't there it will tell you you're going to need it, what it is, and where you might find it, and a link to buy it (Aamiga inc. licence it). It will of course have a 'run anyway' button.

I think this is likely to be a waste of resources; when you have an open system, you can NEVER have a complex front-end that keeps compatibility with every single software update for every emulator and app. It would be a nightmare, and would be outdated within days or weeks. Sure, it could work in theory, if you have the resources and manpower of Apple to devote to it. I think Craig's resources would be better devoted to building Pandoras.


The only way to create a standard is for devs to agree to one and self-police. And this will happen naturally if enough Pandoras are sent out.


I'm just saying that you can't take shortcuts here. If Craig makes a complex, all-inclusive front-end for every program but devs don't like the hoops they need to jump through to use it, then they won't make their programs compatible with it, and most users will be complaining about why program X doesn't work, and you're back where you started.