[sugar] What Activity development can learn from Nokia tablets

[Mel Chua]

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
mel at laptop.org