Universal launcher

[mkaluza]

Well, almost - I haven't figured out how to load xml ui on the fly yet, but having multiple apps installed becomes easier anyway.
It is not for everyone yet, since "installing" an application requires a little manipulation of the xml ui temlates, but eventually there'll be a gui for this - it is very easy to automate now.

I had two aims:
- make it work
- easy integration with existing "standalone" apps by creating a kind of framework that does most - if not all - the job

Install:
As usual - unzip to the root of sd card. It only has one option to choose since I don't have any more apps yet, but others are comming

Usage:
To "install" an app, there are a few things to do:
1) integrate xml - pretty straightforward
- you have to put everything from your <assets> into <assets> of autorun.xml. And of course the <group> tag containing your UI
- add to "Sony Reader/software/autorun.apps" line containing at least two fields
*description - that'll be diplayed to the user
*name - the NAME - it'll be used to find your <group> in the xml.
Other fields are ignored, but later will be either passed to the application and/or used to configure launcher;
format is: field_name:contents;field_name:field_value
order is unimportant
no semicolon at the end!
no spaces near separators - only in the contents
NAME must be a single word, in uppercase.
so this is ok:

name:DICTIONARY;description:Dictionary

this too is ok

description:Italian dictionary;name:DICTIONARY

this is wrong - space before "DICTIONARY":

description:Dictionary;name: DICTIONARY

2) copy files to "Sony Reader/software/NAME"

Requirements:
There are few assumptions made and few requirements.
1) NAME must be unique among all group tags and it can't be AUTORUN for obvious reasons
2) I tried to follow the naming convention by sony, so your outer group must have id="NAME_GROUP" and inner one id="NAME" - otherwise it'll either not work or crash
3) it expects autorun.js, containing application startup code, at "Sony Reader/software/NAME/autorun.js"
4) it expects autorun.js to define init() function, which takes no parameters. It is called every time the window gets focus, so you're responsible for checking if its the first time it's called if there are things, that should be done once and only once.
5) application (autorun.js) is loaded, when user chooses particular application and is loaded only once - as for now, the application is never destroyed as is not notified, when user quits the launcher.
6) It redefines your doMenu method, so don't depend on it - at later time, it'll be configurable.
7) Soon it'll expect leave() and quit() method, that will be called either when user exits the app and the launcher respectively (it'll be configurable per app) - quit() should bring the app to a initial state (particulary free all allocated memory...), and on leave() app should perform all the things like save configuration and whatever things that should not be lost, in case that user pulls out the card. The launcher will call leave() and then quit() for all launched applications when user quits it via menu button, so leave() should be stateless, because it can be called more than once. quit() doesn't have to.

What it provides:
variables:
this.parent - document root (I guess). below it are all the groups - so this.parent.AUTORUN_GROUP.AUTORUN is valid. (see loadScript in autorun.xml)
this.driveroot - root of the card the script is run from (b: for sd on prs-505)
this.scriptroot=this.driveroot+"/Sony Reader/software/NAME/" - to make managing files easier - to keep things clean, you should keep all your files there (maybe except cutouts)

current API:
this.trace(message) - writes the message (and a newline) to driveroot/autorun.log
this.parent.openWindow(name) - if your app has more windows (i.e CONFIG/OPTIONS/etc.) you just call this.parent.openWindow("OPTIONS"). All of above things except an entry in config file apply. If you open a window with this method, when user hits Menu, he'll return to your previous window. It's stack base, so can be run repeatedly - see source
this.parent.switchWindow(name) - same as above, but doesn't remember previous window (see source)
this.parent.closeWindow()same as hitting Menu

Near future:
- make it more foolproof - more checking, exceptions handling and logging.
- if it turns out to be useful, integrate with calibre with help of kovidgoyal (if he doesn't mind of course), so applications can be "installed" without any xml editing (
- clean up
- extend api
stdlib:
*extend Stream.File with fseek that works like C fseek()
*trim()
(...)

UIlib
*createForm,createEdit (...) - will create simple edit fields and whole forms based on simple UI objects (label and text for now) - I plan to encapsulate all the keys handling stuff and provide simple event interface (onChange,onQuit,getValue,etc...)

Comments,suggestions,critics are welcome I'm writing this stuff because I need it, but I'm willing to change it to make it more useful for other developers. If anybody wants, I can prepare a stripped framework (no launcher menu will show up, just start the required app) for developing an app as a standalone, but in a way that it then can be installed into the launcher framework without any modifications.

greets
Martin


PS
the dictionary isn't finished yet (and still only italian ) but it's more stable.

PS2
How about porting gnuchess?? ;]

WARNING!!
quit the application via menu button before connecting the reader to usb - for unknown reasons it hangs the UI if the app is still running and reset button needs to be used :/
Actually pulling out the card without quitting the application produces the same result :/ I'll work on it...

[Peto]

Cool!!

Now my usual stupid questions

This is, I understand, an auto-run from the sd card. Could it be modified to be installed directly in the Reader so it can be launched and exited without the card by, for example, holding the zoom button?

[mkaluza]

In short - yes, but we don't yet know how. Anyway - now you can have as much apps as you want on one card, not just one

It's the reader app that has to be modified. There are two ways:
- the easy (and dangerous) way: integrate the autorun.xml with reader's software the same way the apps are now integrated into the launcher. The drawback is that you'd have to reflash the reader to reconfigure installed apps, and making a mistake in some app can brick the device (Invalid autorun.xml file crashes the device - if that's integrated into main UI...well...you know...KIA .
- the hard (but potentialy safer) way: figure out the api to load UI from external xml file and integrate this feature into reader's software. This way we can start any app we want and it's safe - in a worst case scenario you'd need to reset the reader. The hard thing is that we don't know it, and knowing it probably requires reverse engineering some part of reader firmware...:/

Anyway, we keep hacking

[Peto]

ok I get it. Patient is my last name. Im my first though. At times