Owen Williams, the developer behind PenguinTV, has been working with the Nokia tablet lately, and gave some great suggestions on what he liked about the hildon library that makes it easy to develop apps for that platform.
Forwarded with permission - these are the things that were suggested that Sugar might emulate if we want to make it easier for volunteers to make things on our platform. --- I don't know if I can just cut and paste my hildon-specific code. The problem is that the specific code isn't all in one place. The best thing to do is checkout the svn of penguintv: svn co https://penguintv.svn.sourceforge.net/svnroot/penguintv/trunk penguintv and grep for hildon. The key files will be MainWindow.py and penguintv.py. A lot of the code just makes changes to the UI to make penguintv friendlier for the small screen. Some code is specific to making hildon work. For instance I might do something like this: if utils.RUNNING_HILDON: self._window.resize(650,300) self._window.show_all() just to make sure the window is a certain size if the user is running hildon. If the code is confusing (which it might be) I can be more specific about what I did to port it over. Generally, though, the nice thing about the Hildon framework is that it builds on things I already know about GNOME development, so there's not much new to learn. Porting to the platform involves a few basic steps: 1) Using hildon widgets in place of regular GTK widgets. So instead of a gtk.Window, use hildon.Window. Instead of the gtk.FileChooserDialog, use hildon.FileChooserDialog. The APIs are mostly the same, with a couple of small, simple additions. 2) Take advantage of maemo hardware, like hardware buttons and the tap-and-hold stylus action. (this produces a "right-click" type event when the user taps and holds the stylus on the screen). At the same time, change the UI to accomodate the small screen real-estate and lack of convenient right-click. In the case of hardware buttons, they are mapped to standard function keys that would be on a full keyboard. tap-and-hold is a simple gsignal. Some parts of the API, like network presence detection and power saving, are more difficult, but there's not a lot of pressure to get these things working perfectly. 3) Packaging. This is harder, and required more fiddling to get right. Packaging always seems to be difficult. In the end, it required a simple set of dbus configuration files so that the UI knows how to launch your program. But even if you have trouble getting that working, it's possible to use a simple script ("run-standalone.sh") that will correctly launch your application. The nice thing is, now that I have a packaging script that works, I know it's not likely to change in the future. I'm willing to mess around to get something right, but not more than a couple times. One thing that's nice is that my program will work even if I've only done a minimum of porting. I'm not punished for partial porting. I can take a regular desktop application and simply run it, and it will mostly work right out of the box. Then I can go further and make the UI use the correct widgets. Then I can go further and use the hardware buttons. Porting becomes a gradual process, where each step is rewarded with better functionality. There's no huge leap where tons of work has to be done just to get the thing to launch. owen -- Mel Chua QA/Support Engineer [EMAIL PROTECTED] _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
