Wish List

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(→‎Python Bindings)
(→‎Python Bindings)
Line 28: Line 28:
 
Python bindings seem to be a commonly requested feature.   
 
Python bindings seem to be a commonly requested feature.   
  
−
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.com 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."
+
[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org 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."

Revision as of 03:58, 11 September 2006

This article is a place to collect various thoughts about OpenMoko.

Software Related

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:

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."

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

This article is a place to collect various thoughts about OpenMoko.

Software Related

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:

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."