Wish List

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(→‎Software Related: Foreign Widget Set Bindings)
Line 79: Line 79:
 
=== wxWidgets Integration ===
 
=== wxWidgets Integration ===
 
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.
 
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.
 +
 +
=== SDL Integration ===
 +
SDL is _the_ game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

Revision as of 16:06, 14 November 2006

This article is a place to collect various thoughts about the future of the OpenMoko software platform.

Contents

Development Related

Painless SDK installation & Setup

Our goal should be a completely painless setup for somebody wanted to develop using OpenMoko

  • one command for installation (apt-get install openmoko)
  • one command to start Xnest (openmoko-xephyr?)
  • one command to start an i386 shell (openmoko-386-shell)
  • one command to start an armel shell (openmoko-armel-shell)

No extra configuration required (allowed ;)

IDE Plugins

People like to see plugins for

  • Anjuta
  • Eclipse
  • Kdevelop

Community Support Related

projects.openmoko.org

Infrastructure for developers w/

  • one bugzilla for all projects (makes moving bugs forth and backwards between projects _very_ easy)
  • one mailinglist for project

Platform Related

Community Images

In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

Software Related: Additional Features

Multiboot Support

I'd like to see U-Boot being enhanced to support a boot menu that allows to boot a complete image from the MMC. This way we have a simple way for part-time developers (aka people actually _using_ their phone or people not having a seperate phone for development) to experiment with new OpenMoko releases or custom images.

Printing Support

It would be really neat to be able to print over either bluetooth or USB. I could imagine wanted to print:

  • Notes
  • Maps
  • Email
  • Calendars
  • ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

  1. GTK+'s printing support
  2. Making cups run on a really small system
NOTE: GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.


There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:

PalmOS Emulator

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally millions of PalmOS apps.

Software Related: Language Bindings

Python Bindings

Python bindings seem to be a commonly requested feature.

User:Mickey says, "They are kind of usable on the Nokia 770, but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

C++ Bindings

There is a whole skilled C++ community coming from the Qtopia and Opie projects. If we would consider basing OpenMoko C++ Bindings on Gtkmm, then we could drag these guys in.

Software Related: Foreign Widget Set Bindings

Qt Integration

The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

Maemo Integration

The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

wxWidgets Integration

wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

SDL Integration

SDL is _the_ game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

Retrieved from "http://wiki.openmoko.org/index.php?title=Wish_List&oldid=2684"
Personal tools

This article is a place to collect various thoughts about the future of the OpenMoko software platform.

Development Related

Painless SDK installation & Setup

Our goal should be a completely painless setup for somebody wanted to develop using OpenMoko

  • one command for installation (apt-get install openmoko)
  • one command to start Xnest (openmoko-xephyr?)
  • one command to start an i386 shell (openmoko-386-shell)
  • one command to start an armel shell (openmoko-armel-shell)

No extra configuration required (allowed ;)

IDE Plugins

People like to see plugins for

  • Anjuta
  • Eclipse
  • Kdevelop

Community Support Related

projects.openmoko.org

Infrastructure for developers w/

  • one bugzilla for all projects (makes moving bugs forth and backwards between projects _very_ easy)
  • one mailinglist for project

Platform Related

Community Images

In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

Software Related: Additional Features

Multiboot Support

I'd like to see U-Boot being enhanced to support a boot menu that allows to boot a complete image from the MMC. This way we have a simple way for part-time developers (aka people actually _using_ their phone or people not having a seperate phone for development) to experiment with new OpenMoko releases or custom images.

Printing Support

It would be really neat to be able to print over either bluetooth or USB. I could imagine wanted to print:

  • Notes
  • Maps
  • Email
  • Calendars
  • ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

  1. GTK+'s printing support
  2. Making cups run on a really small system
NOTE: GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.


There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:

PalmOS Emulator

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally millions of PalmOS apps.

Software Related: Language Bindings

Python Bindings

Python bindings seem to be a commonly requested feature.

User:Mickey says, "They are kind of usable on the Nokia 770, but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

C++ Bindings

There is a whole skilled C++ community coming from the Qtopia and Opie projects. If we would consider basing OpenMoko C++ Bindings on Gtkmm, then we could drag these guys in.

Software Related: Foreign Widget Set Bindings

Qt Integration

The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

Maemo Integration

The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

wxWidgets Integration

wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.