Re: [Shr-Devel] FSO application management
Simon Busch wrote: Heyho, as we talked already with some people about application management in FSO we should now start discussing this in the public and define some spec with all features we want in the end. I will start here with explaining my ideas. First of all we need a daemon doing all the application management. I think we should call it simply fsoappd. The daemon manages all things we have in mind with applications (btw. we should define what an application exactly is!). There is the lifecycle management of applications. An application has always a state which identifies the application as running, inactive or whatever. To come from one state into another one there are possible events (pause, hide, destroy, ...) which let the application change its state (for example, the wm choose another app to become visible, so the current app will get paused). We should define some rules an common agreements all application should share so we can keep our application management simple. Furthermore we need a way applications can communicate between each other. My idea here is to define common interfaces an application can implement. For example the org.freesmartphone.Dialer interface. The interface describes which DBus methods/signals should be implemented by the app. If one app needs the dialer, it requests the dialer via the fsoappd by a method called Request(org.freesmartphone.Dialer). Each application has a file appinfo.config file where it defines which interfaces it implements. The fsoappd now searches through all appinfo.config files (they should be stored by each application in one common place) and tries to get one which implements the requested interface. If there is more than one fsoappd looks in a priority list which defines priorities for each interfaces (e.g. there are two dialers, one provided by SHR and one by a independent developer. The priority file now defines that the SHR dialer should be choose with higher priority than the other one ...). Finaly fsoappd starts the app for the requested interface in a not visible state. The app which requested the other app to start can now chose what it wants to do with the recent started app. Maybe it calles org.freesmartphone.Dialer.Show() to show the dialer application so the user can enter a number and call somebody. The application interface should be defined as xml spec somewhere. If an app does not implement any interface it should define at lest its name in the format like org.mycompany.mygreatapplicationname. The Request(...) method now looks even for an app called like the interface name is set. As the application interface implementation is available as xml we should even provide a lib called libfso-app which implements all the interface in vala or your favourite language so you can easily use it. So far from my side. I have some more ideas, but will need some time to write them down. regards, morphis Btw. there is already a brainstorming page in the FSO wiki about application lifecycle management: http://wiki.freesmartphone.org/index.php/Brainstorm/LifeCycle and http://wiki.freesmartphone.org/index.php/Brainstorm/Launcher Seems to me that some of the functionality you mention of searching for apps which implement a certain interface is already built into DBus itself. All that remains is to define the minimum interfaces that a certain application type must implement. An app is free to augment that list if if requires but there is a minimum set that a Dialer app must implement. I'll try to go through those links but I would also say that the android method of displaying information on the screen is a very good idea. At present my shr-u phone just displays the apps I have installed, by default. I don't really consider that to be useful information. HTC's overlay stuff for android which lets an app display facebook updates or weather updates or share price updates is a good mechanism of displaying actual info. Maybe that's already in the links like I say I'll have a look at them later today. ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Shr-Devel] FSO application management
Al Johnson wrote: On Monday 18 October 2010, Arigead wrote: Simon Busch wrote: Heyho, as we talked already with some people about application management in FSO we should now start discussing this in the public and define some spec with all features we want in the end. I will start here with explaining my ideas. First of all we need a daemon doing all the application management. I think we should call it simply fsoappd. The daemon manages all things we have in mind with applications (btw. we should define what an application exactly is!). There is the lifecycle management of applications. An application has always a state which identifies the application as running, inactive or whatever. To come from one state into another one there are possible events (pause, hide, destroy, ...) which let the application change its state (for example, the wm choose another app to become visible, so the current app will get paused). We should define some rules an common agreements all application should share so we can keep our application management simple. Furthermore we need a way applications can communicate between each other. My idea here is to define common interfaces an application can implement. For example the org.freesmartphone.Dialer interface. The interface describes which DBus methods/signals should be implemented by the app. If one app needs the dialer, it requests the dialer via the fsoappd by a method called Request(org.freesmartphone.Dialer). Each application has a file appinfo.config file where it defines which interfaces it implements. The fsoappd now searches through all appinfo.config files (they should be stored by each application in one common place) and tries to get one which implements the requested interface. If there is more than one fsoappd looks in a priority list which defines priorities for each interfaces (e.g. there are two dialers, one provided by SHR and one by a independent developer. The priority file now defines that the SHR dialer should be choose with higher priority than the other one ...). Finaly fsoappd starts the app for the requested interface in a not visible state. The app which requested the other app to start can now chose what it wants to do with the recent started app. Maybe it calles org.freesmartphone.Dialer.Show() to show the dialer application so the user can enter a number and call somebody. The application interface should be defined as xml spec somewhere. If an app does not implement any interface it should define at lest its name in the format like org.mycompany.mygreatapplicationname. The Request(...) method now looks even for an app called like the interface name is set. As the application interface implementation is available as xml we should even provide a lib called libfso-app which implements all the interface in vala or your favourite language so you can easily use it. So far from my side. I have some more ideas, but will need some time to write them down. regards, morphis Btw. there is already a brainstorming page in the FSO wiki about application lifecycle management: http://wiki.freesmartphone.org/index.php/Brainstorm/LifeCycle and http://wiki.freesmartphone.org/index.php/Brainstorm/Launcher Seems to me that some of the functionality you mention of searching for apps which implement a certain interface is already built into DBus itself. That's what I was thinking, though IIRC tiy have to walk the tree looking for the method rather than simply asking what implements X? All that remains is to define the minimum interfaces that a certain application type must implement. An app is free to augment that list if if requires but there is a minimum set that a Dialer app must implement. There is also the matter of preference when multiple apps implement the method/profile. On my desktop Ubuntu, and when I had a HTC Hero Android phone, that was dealt with by asking the user which of the options should be used to complete the action, and giving a toggle button to make the chosen option the default. You'll then need a gui to edit the defaults, of course. Just out of interest how many apps are we talking about? There is a core of framework DBus interfaces already spec'd more or less. I say more or less as I'm sure that they will be changing. (I'd have thought that maybe opimd would be augmented with calendar entries, but I maybe wrong) This core framework interface definitions need to be added to with a number of *Interesting apps* and then there are a million apps which we're probably not interested in at all. I'm thinking about games and the like. Maybe when the framework receives a call a game could handle the DBus signal and pause the game but that's down to the app handling a broadcast signal. Apps we're interest in I would think are the: Calendar app email client music player Having said that if I received an SMS with an email address in it I'd like to be able to click
Re: [Shr-Devel] FSO application management
Al Johnson wrote: On Monday 18 October 2010, Arigead wrote: Simon Busch wrote: Heyho, as we talked already with some people about application management in FSO we should now start discussing this in the public and define some spec with all features we want in the end. I will start here with explaining my ideas. First of all we need a daemon doing all the application management. I think we should call it simply fsoappd. The daemon manages all things we have in mind with applications (btw. we should define what an application exactly is!). There is the lifecycle management of applications. An application has always a state which identifies the application as running, inactive or whatever. To come from one state into another one there are possible events (pause, hide, destroy, ...) which let the application change its state (for example, the wm choose another app to become visible, so the current app will get paused). We should define some rules an common agreements all application should share so we can keep our application management simple. Furthermore we need a way applications can communicate between each other. My idea here is to define common interfaces an application can implement. For example the org.freesmartphone.Dialer interface. The interface describes which DBus methods/signals should be implemented by the app. If one app needs the dialer, it requests the dialer via the fsoappd by a method called Request(org.freesmartphone.Dialer). Each application has a file appinfo.config file where it defines which interfaces it implements. The fsoappd now searches through all appinfo.config files (they should be stored by each application in one common place) and tries to get one which implements the requested interface. If there is more than one fsoappd looks in a priority list which defines priorities for each interfaces (e.g. there are two dialers, one provided by SHR and one by a independent developer. The priority file now defines that the SHR dialer should be choose with higher priority than the other one ...). Finaly fsoappd starts the app for the requested interface in a not visible state. The app which requested the other app to start can now chose what it wants to do with the recent started app. Maybe it calles org.freesmartphone.Dialer.Show() to show the dialer application so the user can enter a number and call somebody. The application interface should be defined as xml spec somewhere. If an app does not implement any interface it should define at lest its name in the format like org.mycompany.mygreatapplicationname. The Request(...) method now looks even for an app called like the interface name is set. As the application interface implementation is available as xml we should even provide a lib called libfso-app which implements all the interface in vala or your favourite language so you can easily use it. So far from my side. I have some more ideas, but will need some time to write them down. regards, morphis Btw. there is already a brainstorming page in the FSO wiki about application lifecycle management: http://wiki.freesmartphone.org/index.php/Brainstorm/LifeCycle and http://wiki.freesmartphone.org/index.php/Brainstorm/Launcher Seems to me that some of the functionality you mention of searching for apps which implement a certain interface is already built into DBus itself. That's what I was thinking, though IIRC tiy have to walk the tree looking for the method rather than simply asking what implements X? All that remains is to define the minimum interfaces that a certain application type must implement. An app is free to augment that list if if requires but there is a minimum set that a Dialer app must implement. There is also the matter of preference when multiple apps implement the method/profile. I'll try to go through those links but I would also say that the android method of displaying information on the screen is a very good idea. At present my shr-u phone just displays the apps I have installed, by default. I don't really consider that to be useful information. HTC's overlay stuff for android which lets an app display facebook updates or weather updates or share price updates is a good mechanism of displaying actual info. Maybe that's already in the links like I say I'll have a look at them later today. Just looking through the links provided in the original email and not sure I like or agree with the use case on the bottom of the lifecycle page: Trucker Joe is on the road and gets a phone call, but he's lost in $(TOWN) without navit, and navit supports answering calls. instead of bringing navit to background, it show OSD buttons to answer the call. That's expecting navit to start implementing functionality which it really should have no interest in. Navit should do what it does well and leave phone calls to apps that do that well. Given that there is a window manager in the phone could
Get Contact details?
Sorry it's a newbie question I'm afraid. I've been looking at org.freesmartphone.PIM.Contact with a view to getting contact details for a phone number. I'm really trying to get my hands on the contact's name given a number so that went a call or sms or something arrives you can quickly query opimd for a name, if it's got one. The GetContent() method takes no parameters so I'm not sure I understand it's intended use, obviously I'm missing the point. Anyhow if somebody could advise me I'd be very grateful. Pulling back all the contacts and searching through don't seem the ideal way of doing this. Thanks for any help and sorry if this is a bit on the basic side ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Running the Framework on Ubuntu laptop?
Hello all, Hope this question ain't too stupid. I'd like to try and run the FSO Framework on my ubuntu laptop. More specifically I'd like to play with the PIM part of the framework. I'm hoping to play with it and write code to interface with the PIM Engine with DBus calls. I've done the basic sudo python setup.py install which seems to have run fine but executing frameworkd tells me that there is no frameworkd.conf Could somebody point me in the right direction here. Can I simply copy the conf file from a freerunner across to the ubuntu laptop. That sounds a bit too simple. Any help or advice would be gratefully appreciated. John ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: Running the Framework on Ubuntu laptop?
Sebastian Reichel wrote: On Fri, Sep 25, 2009 at 09:05:53AM +0100, Arigead wrote: Hello all, Hope this question ain't too stupid. I'd like to try and run the FSO Framework on my ubuntu laptop. More specifically I'd like to play with the PIM part of the framework. I'm hoping to play with it and write code to interface with the PIM Engine with DBus calls. I've done the basic sudo python setup.py install which seems to have run fine but executing frameworkd tells me that there is no frameworkd.conf Could somebody point me in the right direction here. Can I simply copy the conf file from a freerunner across to the ubuntu laptop. That sounds a bit too simple. Any help or advice would be gratefully appreciated. John Hi, Just copy the default frameworkd.conf to /etc/frameworkd.conf and disable all subsystems except of opimd. Btw. you may want to install the Debian packages in Ubuntu instead of installing FSO without any packaging control system. If so you can find the package here: http://pkg-fso.nomeata.de/sid/fso-frameworkd You will also need some dependencies, which are linked on the page. Dependencies, which are not linked can be found in the Debian repository and most likley in the Ubuntu repository, too. -- Sebastian Thanks a million for that response Sebastian. It makes sense to install everything from deb packages so I started that but unfortunatley encountered an error with an install of python-phoneutils it's complaining that /usr/share/python-support/python-phoneutils.public is not a directory which is fair comment as it's not a directory. I'm a bit suspicious of a package that's installing python-phoneutils having a problem with python-phoneutils ;-) John ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: Building FSO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rod Whitby wrote: Arigead wrote: To quote the Building FSO wiki page again: - Once you've finished setting up the build environment, - you can build the FSO image with the command: - - cd /stuff/build bitbake fso-image I have set up the build environment as per the instructions and have used openembedded before for building for gumstix boards but the instructions bitbake fso-image do not work. I have used my openembedded environment to build some individual packages which does work. Don't forget to source the setup-env file first. If the wiki page doesn't say that, please add it. -- Rod There is not mention of setup-env either in the openembedded web page or the Building FSO web page. In addition there is no setup-env file anywhere in the directory structure I have set up. I have set my BBPATH and PATH variables to point at the correct locations but if there are additional settings in setup-env I don't know what they are. I'll just use the makefile it'll obviously be the simpler option, but perhaps somebody in the know should look at the manual build instructions, and perhaps remove them from the wiki page as they do not appear to work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmOs8MACgkQXlbjSJ5n4BAkpACgoBDEG0s3fNQMX+qPqgEv8P8e tfUAn2i5w0e9mRELQEbXpNgw4g280NrK =EcsC -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: Building FSO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rod Whitby wrote: Thanks a million for getting back to me Alastair but from what you're saying openembedded is not what I should be building with, or the upstream is not maintained as such. I'm a bit confused by all this perhaps the wiki page should be changed a little to remove the building FSO Manually section I have no idea on what basis you are making statements like the one above. The FSO Makefile is simply a thin wrapper around OpenEmbedded, which sets up the environment in a sane manner and calls bitbake with the right arguments. I'll try with the make file :-( That's the way the official FSO package feeds are built, so you can be pretty sure it's going to work ... -- Rod (FSO Makefile maintainer) Hello Rod, thanks for taking the time to reply and I'm sorry to say I have no basis at all for what I'm saying but I'm just trying to figure it out. I was looking at the Building FSO Wiki page [1] and read that: - - While convenient, building with FsoMakefile does not - - tell you much about what is going on under the hood. - - FsoMakefile automatically downloads an OpenEmbedded - - build tree, configures it to build FSO and then builds - - the image. I'd like to get a better idea of what's going on under the hood and to be able to build my own packages and add them to the image as OpenEmbedded allows. Sort of like outlined in [2]. That way I could take the MS5 bitbake recipe and overload it and add say OpenMooCow to my image with an OpenMooCow.bb file. Include the latest and greatest kernel from Andy Tracking. That way when MS6 comes out I can change one line in my image file and do my build of MS6 with OpenMooCow and anything else to my taste. To quote the Building FSO wiki page again: - - Once you've finished setting up the build environment, - - you can build the FSO image with the command: - - - - cd /stuff/build bitbake fso-image I have set up the build environment as per the instructions and have used openembedded before for building for gumstix boards but the instructions bitbake fso-image do not work. I have used my openembedded environment to build some individual packages which does work. Don't panic about this it might just be my machine. Trying my first full build on an eee PC might not have been the wisest idea I've ever had. I'll maybe set this up on a Desktop but in the mean time I'll use the make file. Thanks for all your work, much appreciated. Love the FreeRunner and hope to be able to contribute some time soon. ;-) [1] http://wiki.openmoko.org/wiki/Building_FSO [2] http://bec-systems.com/site/177/the-correct-way-to-add-packages-to-an-openembedded-image -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmNeycACgkQXlbjSJ5n4BAYYACdHOxekj42jaFoZx9imAzP6jSE oBUAn0STfP8GSSRjn92QSIrT3xfj3y9b =D9Dw -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Building FSO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I was just trying to build the FSO from openembedded as per the instructions on the wiki. If you're trying to do that on an eeePC it tends to take some time! I only have to build it all once and then all I have to build changes. Anyhow the build has failed at connman, a few days in ;-) I can't see what depends on connman and why I'm even building it. I'm not entirely confident here that what I'm building in openembedded will match the MS5 build that I have in my phone at present. As far as I know the official FSO is built from openembedded upstream but I don't think that this can be the case. I've said before that the openmoko should have there own small repository for bitbake recipes that can overload the official upstream openembedded recipes. Those should be kept in a directory at the same level as openembedded and BBPATH used to set priority. Then om_openembedded can overload any upstream recipes as it sees fit and produce recipes that build the latest kernel etc. I imagine my build of fso-image would not have had the andy tracking kernel but an old one. I'm thinking of a structure like the gumstix structure [1] Anyhow those are just suggestions, in the mean time can anybody tell me how I can build fso-image as per the wiki instructions? Thanks for any help [1] http://www.gumstix.net/Software/view/Build-system-overview/Directory-layout/111.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmL9bEACgkQXlbjSJ5n4BD3cgCgo+v0V7LJ6LV2v57ubo2Q9swH rUsAoJ0CpPvABz1WF6aJRWGCp+lUKE5j =hKMg -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: Building FSO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alastair Johnson wrote: Arigead wrote: Hello all, I was just trying to build the FSO from openembedded as per the instructions on the wiki. If you're trying to do that on an eeePC it tends to take some time! I only have to build it all once and then all I have to build changes. Anyhow the build has failed at connman, a few days in ;-) I can't see what depends on connman and why I'm even building it. connman is (meant to be) a lightweight equivalent to NetworkManager, and is going to be used to handle networking. I'm not entirely confident here that what I'm building in openembedded will match the MS5 build that I have in my phone at present. As far as I know the official FSO is built from openembedded upstream but I don't think that this can be the case. I've said before that the openmoko should have there own small repository for bitbake recipes that can overload the official upstream openembedded recipes. Those should be kept in a directory at the same level as openembedded and BBPATH used to set priority. Then om_openembedded can overload any upstream recipes as it sees fit and produce recipes that build the latest kernel etc. I imagine my build of fso-image would not have had the andy tracking kernel but an old one. I'm thinking of a structure like the gumstix structure [1] Anyhow those are just suggestions, in the mean time can anybody tell me how I can build fso-image as per the wiki instructions? wget http://downloads.freesmartphone.org/Makefile make setup You could now enable parallel builds in common/conf/local.conf but this can cause problems with some packages, and probably isn't a good idea on the Eee anyway. make fso-gta02-milestone5-image I had to rerun this a couple of times as a couple of packages failed due to parallel build issues and lack of memory. When you rerun it only builds the bits that haven't successfully completed yet. Thanks a million for getting back to me Alastair but from what you're saying openembedded is not what I should be building with, or the upstream is not maintained as such. I'm a bit confused by all this perhaps the wiki page should be changed a little to remove the building FSO Manually section I'll try with the make file :-( JW -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmMsOUACgkQXlbjSJ5n4BCB/ACg04S6AhFm1AjYKw2ZEEZufnQI wJgAnjFuLam88ZnNOIzyivkD0Ywc7HyN =/+FC -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Debugging PPP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I've been having a few issues with establishing GPRS data connections to a service provider (Not all providers) and as a result would like to look at debugging ppp, get more detail as to what the provider is not happy with. Can anybody give me some pointers on this. I have OE installed and have a recipe for ppp in there. That recipe will download the code from the a server and build it. I assume I'll have to copy that recipe and change it so that I can have the code in a directory that I'm working on. I know OE works in a tmp directory for downloading and building. Any pointers or advice will be very gratefully received. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmBmRoACgkQXlbjSJ5n4BCefACg1RCNbLAD7JQObb6JhlnQDcgg 1SAAoNF86IMEq7h5N3rFZyAzgfSf7B5V =zaTt -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 arne anka wrote: using ms4 and if I was a granny and hit a power button I'd think I just switched off the phone, not suspend. If I hit it again I'd think that I'd powered it on again, not resume. a grannie would be able to kill herself with a spoon ... everything above a kitchen knive requires understanding how the device works, which means reading soem kind of documentation before use -- if the device does not work as expected, it's usually a matter of pebkac. especially for a device with so limited a number of physical input elements it should be perfectly clear to any user that the two buttons have more than a simple on/off function but a broad number depending upon the situation. it might be an option (as usual) to make the behaviour of the pwr button configurable: a) do only on/off b) do suspend/resume and on/off c) expose a menu to select the desired action a) would be for what you call grannies b) for those preferring fast and minmal inavise action c) for the rest focusing solely on the (imho hardly likely) group of grannies would ostracize the number of users willing to use and looking for a more advanced device not tied up in the conventional paradigms of user interaction. building smartphones for grannies is a task a lot of companies aspire -- and i doupt openmoko would be able to survive! have a look at palm: they basically abandoned palmos in favour of wince -- and their phones a re to expansive and too bad to cope with stuff from htc or so, they left their niche and found no other ... Cheers for that you made me laugh with the grannies with spoons comment ;-) I sort of disagree with you. People do not read the manual when they get a device. They try to use it and if they have to resort to the manual the designer has failed. I can't remember the last time I read the manual for a phone, camera, DVD player. Devices performing everyday things like a mobile phone in the 21t century should be as close to intuitive as makes no difference. No offence to anybody on this list but like a lot of you I'm happy enough with the command line for a lot of stuff and that's maybe why we're not that good at usability. I'm not suggesting that we get tied up the conventional paradigms of user interactions but just a bit of usability. I think even a granny given an iPod for the first time would have a fairly good stab at playing some music. Obviously getting music into it would be a stretch. I also don't think that OpenMoko should even attempt to give use smart phones for grannies. They should give us a hardware platform and let us, the community, do the rest. Look at the xBox media centre for the original xBox built by a community, as far as I know, and a really good usable piece of Software IMHO. At the end of the day I'm still amazed that I've got an open platform. When my capable laptop for programming arrives and I get some time I'm going to have a menu on the power button ;-) Thanks again for the laugh. Grannies with spoons -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJLb++XlbjSJ5n4BARAnw3AJ9+4rcX4UZPK4e9CoMaGCnUhkS/zgCdFqEZ na7pfezQmbfeQ1Up2yKrIFg= =bW5x -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
