http://openmoko.org/api.php?action=feedcontributions&user=Charlie&feedformat=atomOpenmoko - User contributions [en]2024-03-29T13:35:55ZUser contributionsMediaWiki 1.19.24http://openmoko.org/wiki/TichyTichy2009-05-17T04:21:22Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
<br />
</pre><br />
<br />
[[Image:Tichy-main2.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== Warning ==<br />
Tichy currently diverged back from [[Paroli]].<br />
Tichy is a work in progress, for more information and to understand the goals of tichy, please read the README file included in the source repository.<br />
<br />
== Tichy webpage ==<br />
http://code.google.com/p/tichy/<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service)<br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy<br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
It is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click)<br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
Now Tichy hosted on code.google.com so use svn to fetch:<br />
svn checkout http://tichy.googlecode.com/svn/trunk/ tichy-read-only<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== packages ==<br />
From the google code page, debian and ipkg packages are available.</div>Charliehttp://openmoko.org/wiki/TichyTichy2009-01-13T02:55:54Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
<br />
</pre><br />
<br />
[[Image:Tichy-main2.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== Warning ==<br />
<br />
Tichy is currently unmaintained. People should use [[Paroli]] instead.<br />
The paroli project is mainly based on tichy and all changes to tichy are done in paroli repository.<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service)<br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy<br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click)<br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from git repository on git.openmoko.org :<br />
git clone git://git.openmoko.org/git/tichy<br />
Or, if you have access to the git machine and want to commit :<br />
git clone ssh://git@git.openmoko.org/var/cache/git/tichy.git<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
<br />
To run it on the desktop, make sure you have python-pygames installed<br />
sudo apt-get install python-pygame<br />
<br />
Then just download the sources, then go into test, and run<br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
A package is available for it in Openmoko Testing and unstable feed. Unfortunately tichy won't work yet, because of a bug in python-pygame in openmoko feeds.<br />
<br />
[[Category:Application Developer]]</div>Charliehttp://openmoko.org/wiki/File:Paroli-dialer.pngFile:Paroli-dialer.png2008-12-12T08:32:15Z<p>Charlie: First version of paroli dialer (tele)</p>
<hr />
<div>First version of paroli dialer (tele)</div>Charliehttp://openmoko.org/wiki/ParoliParoli2008-12-12T08:31:36Z<p>Charlie: New page: Paroli is an integrated phone application based on Tichy (and so also written in python). Paroli dialer == Getting the sources == paroli has been m...</p>
<hr />
<div>Paroli is an integrated phone application based on [[Tichy]] (and so also written in python).<br />
<br />
[[Image:Paroli-dialer.png|thumb|Paroli dialer]]<br />
<br />
== Getting the sources ==<br />
<br />
paroli has been merged into tichy, so the sources can be found on tichy git repository :<br />
<br />
git clone git://git.openmoko.org/git/tichy<br />
<br />
Or, if you have access to the git machine and want to commit :<br />
<br />
git clone ssh://git@git.openmoko.org/var/cache/git/tichy.git<br />
<br />
<br />
== Documentation ==<br />
<br />
Most documentation can be found in tichy/paroli repository, in the doc directory.<br />
To get started with paroli it is suggested to have a look at those files first :<br />
<br />
* [http://git.openmoko.org/?p=tichy.git;a=blob;f=README; Tichy README file]<br />
* [http://git.openmoko.org/?p=tichy.git;a=blob;f=doc/internal.txt Tichy internal doc]<br />
* [http://git.openmoko.org/?p=tichy.git;a=blob;f=doc/ClassDiagram.svg Tichy UML diagram]<br />
<br />
The full documentation for tichy library can be generated using epydoc (see the README file)</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-11-11T08:24:41Z<p>Charlie: /* Sources */</p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
<br />
</pre><br />
<br />
[[Image:Tichy-main2.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service)<br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy<br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click)<br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from git repository on git.openmoko.org :<br />
git clone git://git.openmoko.org/git/tichy<br />
Or, if you have access to the git machine and want to commit :<br />
git clone ssh://git@git.openmoko.org/var/cache/git/tichy.git<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
<br />
To run it on the desktop, make sure you have python-pygames installed<br />
sudo apt-get install python-pygame<br />
<br />
Then just download the sources, then go into test, and run<br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
A package is available for it in Openmoko Testing and unstable feed. Unfortunately tichy won't work yet, because of a bug in python-pygame in openmoko feeds.<br />
<br />
[[Category:Application Developer]]</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-11-05T05:46:02Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
<br />
</pre><br />
<br />
[[Image:Tichy-main2.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service)<br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy<br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click)<br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from git repository on git.openmoko.org :<br />
git clone git://git.openmoko.org/git/tichy<br />
Or, if you have access to the git machine and want to commit :<br />
git clone ssh://git@git.openmoko.org:/var/cache/git/tichy.git<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
<br />
To run it on the desktop, make sure you have python-pygames installed<br />
sudo apt-get install python-pygame<br />
<br />
Then just download the sources, then go into test, and run<br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
A package is available for it in Openmoko Testing and unstable feed. Unfortunately tichy won't work yet, because of a bug in python-pygame in openmoko feeds.<br />
<br />
[[Category:Application Developer]]</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-11-05T04:50:09Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _<br />
_ (_) | |<br />
_| |_ _ ____| |__ _ _<br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/<br />
</pre><br />
<br />
[[Image:Tichy-main2.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service)<br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy<br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click)<br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from git repository on git.openmoko.org :<br />
git clone git://git.openmoko.org/git/tichy<br />
Or, if you have access to the git machine and want to commit :<br />
git clone ssh://git@git.openmoko.org:/var/cache/git/tichy.git<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
<br />
To run it on the desktop, make sure you have python-pygames installed<br />
sudo apt-get install python-pygame<br />
<br />
Then just download the sources, then go into test, and run<br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
A package is available for it in Openmoko Testing and unstable feed. Unfortunately tichy won't work yet, because of a bug in python-pygame in openmoko feeds.<br />
<br />
[[Category:Application Developer]]</div>Charliehttp://openmoko.org/wiki/User:CharlieUser:Charlie2008-10-09T07:34:42Z<p>Charlie: </p>
<hr />
<div>Hello My name is Guillaume Chereau, But you can call me Charlie.<br />
<br />
I work principally on the framework project.<br />
<br />
* My email : charlie@openmoko.org<br />
* google talk : charlie137@gmail.com<br />
<br />
* My personal blog : http://charlie137.blogspot.com<br />
* More tech oriented : http://charlie137-2.blogspot.com</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-10-09T03:09:30Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
</pre><br />
<br />
[[Image:Tichy-main2.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy <br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click) <br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
<br />
To run it on the desktop, make sure you have python-pygames installed<br />
sudo apt-get install python-pygame<br />
<br />
Then just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
A package is available for it in Openmoko Testing and unstable feed. Unfortunately tichy won't work yet, because of a bug in python-pygame in openmoko feeds.<br />
<br />
[[Category:Application Developer]]</div>Charliehttp://openmoko.org/wiki/File:Tichy-main2.pngFile:Tichy-main2.png2008-10-09T03:08:36Z<p>Charlie: </p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/File:Tichy-main.pngFile:Tichy-main.png2008-10-09T03:07:28Z<p>Charlie: uploaded a new version of "Image:Tichy-main.png"</p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/TichyTichy2008-09-04T12:30:24Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
</pre><br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy <br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click) <br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
<br />
To run it on the desktop, make sure you have python-pygames installed<br />
sudo apt-get install python-pygame<br />
<br />
Then just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
A package is available for it in Openmoko Testing and unstable feed. Unfortunately tichy won't work yet, because of a bug in python-pygame in openmoko feeds.<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/Talk:TichyTalk:Tichy2008-09-04T12:28:37Z<p>Charlie: </p>
<hr />
<div>When I want to start Tichy from my desktop computer, I get this error:<br />
<pre><br />
root WARNING can't use guic, using guip<br />
Traceback (most recent call last):<br />
File "./tichy", line 38, in <module><br />
import tichy<br />
File "../tichy/__init__.py", line 24, in <module><br />
import gui<br />
File "../tichy/gui.py", line 26, in <module><br />
from guip import *<br />
File "../tichy/guip/__init__.py", line 23, in <module><br />
from edit import Edit<br />
File "../tichy/guip/edit.py", line 25, in <module><br />
import tichy.key<br />
File "../tichy/key.py", line 8, in <module><br />
import pygame<br />
ImportError: No module named pygame<br />
</pre><br />
[[User:Dolfje|Dolfje]] 17:30, 27 August 2008 (UTC)<br />
<br />
:You have to install python-pygame. If you are using a debian based OS, you can use apt-get :<br />
apt-get install python-pygame<br />
: --[[User:Charlie|Charlie]] 12:28, 4 September 2008 (UTC)</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-08-25T11:09:26Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For Openmoko<br />
(____/ <br />
</pre><br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy <br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click) <br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill"<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
To run it on the desktop, just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
We don't have a package for tichy yet...<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-08-13T03:43:55Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
<pre><br />
_ _ <br />
_ (_) | | <br />
_| |_ _ ____| |__ _ _ <br />
(_ _) |/ ___) _ \| | | | A Python Applets Manager<br />
| |_| ( (___| | | | |_| |<br />
\__)_|\____)_| |_|\__ | For OpenMoko<br />
(____/ <br />
</pre><br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that wants to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback waiting process as if they were threads)<br />
* Abstraction of Item / View<br />
* A plug in system that make it easy to add new functionalities / applets to tichy <br />
<br />
== How to write an applets / plug-ins for tichy ? ==<br />
Unfortunately There is currently no documentation.<br />
<br />
Fortunately it is very easy to do. If you want to write a new applet, you just need to create a new directory in tichy/test/plugins/apps/. You can have a look at the other plug-ins to get an idea of how to do it. A basic app look like this :<br />
<br />
<pre><br />
import tichy<br />
import tichy.gui as gui<br />
import tichy.item as item<br />
from tichy.application import Application<br />
<br />
class MyApp(Application):<br />
name = "My Application"<br />
icon = 'icon.png' # to be found in the app directory<br />
<br />
def run(self, parent):<br />
w = gui.Window(parent, modal = True) # We run into a new modal window<br />
# Create a new frame with a "back" button on top<br />
frame = gui.ApplicationFrame(w, self, back_button=True)<br />
<br />
# This box is used to store the widgets<br />
box = gui.Box(frame, axis=1)<br />
<br />
# Create a text item<br />
text = item.Text('click to edit', editable = True)<br />
# Put a view of the item on the screen<br />
text.view(box)<br />
<br />
# Add a button<br />
button = gui.Button(box)<br />
gui.Label(button, "click me")<br />
<br />
def on_click(b):<br />
# "yield" means "block until the tasklet returns"<br />
yield gui.Message(w, you just clicked the button)<br />
button.connect('clicked', on_click) <br />
<br />
yield Wait(frame, 'back') # Wait until the back button is clicked<br />
w.close() # Don't forget to close the window<br />
</pre><br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill" (Did the freedesktop app launcher plugin)<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allows to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo. When run on a desktop, tichy will simulate phone functionalities, when run on the neo, it will use the [[OpenmokoFramework | Framework]].<br />
<br />
To run it on the desktop, just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
== Dependencies ==<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
== ipkg package ==<br />
We don't have a package for tichy yet...<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/Template:AppTemplate:App2008-08-13T03:23:11Z<p>Charlie: </p>
<hr />
<div>__NOTOC__<br />
__NOEDITSECTION__ <br />
{| class="wikitable" cellspacing="10" cellpadding="10" width=100%<br />
! width=50% style="background:#ffffff;border-left:0px solid white;border-right:0px solid ffffff;border-top:0px solid ffffff; border:1px solid #ffffff;" |<br />
|-<br />
|valign="TOP" style="background:#ffffff;border-left:5px solid white;border-right:5px solid white;border-bottom:0px solid white; border:1px solid #eeeeee; " | <br />
<div align=left><br />
*[[Splinter]]<br />
*[[Lint-wifi]]<br />
*[[Mofi]]<br />
*[[Gutenflash]]<br />
*[[HP48 Series RPN Calculator]]<br />
*[[Calendar]]<br />
*[[Contacts]]<br />
*[[Guitar Tuning]]<br />
*[[Music Player]]<br />
*[[Epdfview]]<br />
*[[Feed Reader]]<br />
*[[Dialer/2007.2]]<br />
*[[Messages]]<br />
*[[GPS Navigation]]<br />
*[[IM]]<br />
*[[Tichy]]<br />
</div><br />
|valign="TOP" style="background:#ffffff;border-left:5px solid white;border-right:5px solid white;border-bottom:0px solid white; border:1px solid #eeeeee; " | <br />
<div align=left><br />
<br />
<br />
*[[Minimo]]<br />
*[[PyPenNotes]]<br />
*[[Search]]<br />
*[[Clock]]<br />
*[[Mokostat]]<br />
*[[Sample Native-Finger Application]]<br />
*[[Screen Grabber]]<br />
*[[Sketchbook]]<br />
*[[Frma71]]<br />
*[[Backup]]<br />
*[[Help Viewer]]<br />
*[[IM Presence]]<br />
*[[Media Player]]<br />
*[[MokoFEM]]<br />
*[[Mokopedia]]<br />
*[[Gutenflash]]<br />
*[[Orrery]]<br />
*[[Picture Viewer]]<br />
*[[Openmoko SMS Middleware]]<br />
*[[Zedlock]]<br />
</div><br />
|}<br />
<noinclude>[[Category:Templates]]</noinclude></div>Charliehttp://openmoko.org/wiki/File:Tichy-Keyboard.pngFile:Tichy-Keyboard.png2008-08-11T09:33:50Z<p>Charlie: </p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/File:Tichy-Media.pngFile:Tichy-Media.png2008-08-11T09:31:23Z<p>Charlie: </p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/File:Tichy-style.pngFile:Tichy-style.png2008-08-11T09:31:07Z<p>Charlie: </p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/TichyTichy2008-08-11T09:30:54Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy keyboard app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that want to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback blocking application as if they where multi-threads)<br />
* Abstraction of Item / View (Just explain what you want to show, tichy will generate the widgets)<br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill" (Did the freedesktop app launcher plugin)<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allow to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo.<br />
<br />
To run it on the desktop, just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-08-11T09:30:45Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy style app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
[[Image:Tichy-Keyboard.png|thumb|tichy freedesktop app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that want to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback blocking application as if they where multi-threads)<br />
* Abstraction of Item / View (Just explain what you want to show, tichy will generate the widgets)<br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill" (Did the freedesktop app launcher plugin)<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allow to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo.<br />
<br />
To run it on the desktop, just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/TichyTichy2008-08-11T09:30:23Z<p>Charlie: </p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-style.png|thumb|tichy message app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that want to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback blocking application as if they where multi-threads)<br />
* Abstraction of Item / View (Just explain what you want to show, tichy will generate the widgets)<br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill" (Did the freedesktop app launcher plugin)<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allow to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo.<br />
<br />
To run it on the desktop, just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/File:Tichy-drawing.pngFile:Tichy-drawing.png2008-08-11T09:29:57Z<p>Charlie: </p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/TichyTichy2008-08-11T09:29:32Z<p>Charlie: New page: {{Languages|Tichy}} tichy main window tichy drawing app tichy message app [[Image:Tichy...</p>
<hr />
<div>{{Languages|Tichy}}<br />
<br />
[[Image:Tichy-main.png|thumb|tichy main window]]<br />
[[Image:Tichy-drawing.png|thumb|tichy drawing app]]<br />
[[Image:Tichy-messages.png|thumb|tichy message app]]<br />
[[Image:Tichy-Media.png|thumb|tichy freedesktop app]]<br />
<br />
== About ==<br />
Tichy is a python applets manager for embedded devices.<br />
<br />
The goal of the project is to make it easy to write many kind of applications for openmoko using the python language.<br />
<br />
Tichy provides the following things :<br />
* Graphics User Interface widgets<br />
* Services registering and Requesting (for example an application that want to send a message will request for an application implementing the message sending service) <br />
* Tasklets system (This allow to write callback blocking application as if they where multi-threads)<br />
* Abstraction of Item / View (Just explain what you want to show, tichy will generate the widgets)<br />
<br />
== Authors ==<br />
* Guillaume "Charlie" Chereau, main developer<br />
* Michael "Goodwill" (Did the freedesktop app launcher plugin)<br />
<br />
== Sources ==<br />
The sources can be found from svn repository on project.openmoko :<br />
svn checkout svn://svn.projects.openmoko.org/svnroot/tichy<br />
<br />
== Running on the desktop ==<br />
Thanks to the service system, that allow to provide several version of the same service, Tichy can run as well on a desktop computer as on the neo.<br />
<br />
To run it on the desktop, just download the sources, then go into test, and run <br />
./tichy<br />
<br />
== Running on neo ==<br />
You will need to compile some files, see the README for more information on how to do it.<br />
<br />
You need python 2.5 and some libraries installed :<br />
* python-pygame<br />
* python-dbus<br />
* python-yaml<br />
* python-gst<br />
* python-gobject<br />
<br />
[[Category:Applications]]<br />
[[Category:Guides]]</div>Charliehttp://openmoko.org/wiki/File:Tichy-main.pngFile:Tichy-main.png2008-08-11T09:15:23Z<p>Charlie: </p>
<hr />
<div></div>Charliehttp://openmoko.org/wiki/OpenmokoFrameworkOpenmokoFramework2008-07-24T07:28:17Z<p>Charlie: /* High Level */</p>
<hr />
<div>{{Languages|OpenmokoFramework}}<br />
<br />
<br />
{{Introbox}}<br />
<br />
<br />
''Note: This is the (ongoing) description of the new framework architecture that is '''in development'''. See [[OpenmokoOldFramework]] for the framework architecture of 2007.1 and 2007.2 and [[NeoSoftwareStack]] for the current status (which has nothing to do yet with this framework)''<br />
<br />
<categorytree mode=pages style="float:right; clear:right; margin-left:1ex; border:1px solid gray; padding:0.7ex; background-color:white;">Framework</categorytree><br />
<br />
=Q/A=<br />
* ''Question'': Is this an Openmoko-only thing?<br />
* ''Answer'': No. It's going to be available for all kinds of mobile hardware running Linux, i.e. OpenEZX, XanaduX, HTC/iPAQ, ...<br />
* ''Question'': Is this a part of the current images yet? Is it perhaps the mystic ASU?<br />
* ''Answer'': No.<br />
* ''Question'': When can I see this as part of an image?<br />
* ''Answer'': Not before winter '08.<br />
* ''Question'': What's the current status?<br />
* ''Answer'': See right below or hop over to http://trac.freesmartphone.org<br />
** [[OpenmokoFramework/Status Update 1|Status Update 1]]<br />
** [[OpenmokoFramework/Status Update 2|Status Update 2]]<br />
* ''Question'': How do I work the Zhone (FSO demo app) UI?<br />
* ''Answer'': [[FSO UI Tutorial]]<br />
=Purposes=<br />
* '''Give people the infrastructure to create solid and exciting software products based on the Openmoko platform'''<br />
* '''Support competing UIs while collaborating on developing services'''<br />
* '''Encourage framework users (e.g. application developers) to also contribute to the framework'''<br />
<br />
=Requirements=<br />
* Make it simple<br />
* Concentrate on core services<br />
* Be programming language agnostic<br />
* Be UI toolkit agnostic<br />
* Try to reuse existing technologies as much as possible, but not at the cost of a bad API<br />
<br />
=How to achieve that technically=<br />
* Choose [[Dbus]] as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.<br />
* Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).<br />
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.<br />
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.<br />
<br />
=Mandatory Readings=<br />
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]<br />
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]<br />
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]<br />
<br />
=What this is NOT about=<br />
This initiative does not cover low level services such as<br />
* Bootloader, Kernel, or System Init.<br />
<br />
This initiative does not cover high level services such as<br />
* X-Window-System, Window Manager, UI Toolkits,<br />
* Application Launchers, Applications, or Fancy UIs.<br />
<br />
=Architectural Overview=<br />
[[Image:OpenmokoFramework08.png |823px|frontside]]<br />
<br />
=Software Components=<br />
<br />
We differenciate between low-level and high-level services -- dbus will be used to communicate horizontally and vertically.<br />
<br />
===Low-Level Services===<br />
<br />
====Device Control====<br />
The low level device control service manages peripheral control, i.e. controlling power for individual subsystems such as<br />
* GSM, WiFi, Bluetooth, GPS, as well as<br />
* Backlight brightness and power,<br />
* turning LEDs on and off, etc.<br />
It also deals with<br />
* charging, suspend/resume,<br />
* accellerometers, and buttons.<br />
Last but not least, it sends notifications about the user's activity so that listeners have a chance to<br />
* change to powersaving modes, or<br />
* lock the device.<br />
We implement the following software for that:<br />
* [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced]<br />
<br />
====Audio====<br />
The low level audio service relies on a working alsa device driver. On top of that, there are two components:<br />
# [http://gstreamer.freedesktop.org/ gstreamer]<br />
# [http://pulseaudio.org pulseaudio]<br />
<br />
'''Gstreamer''' is to be used for all kinds of event sounds where a) multiple audio formats need to be supported and b) a latency of about one second is acceptable. This goes for e.g. ring tones, welcome tones, plug indication.<br />
<br />
'''Pulseaudio''' is to be used for event sounds, where low-latency is necessary, e.g. touch click sounds and UI event acknowledge sounds. Pulseaudio is our general all-purpose mixer. Gstreamer will use the pulseaudio sink to feed audio through.<br />
<br />
====GSM====<br />
The low level GSM services expect a modem complying to GSM 07.07, GSM 07.05, and assorted GSM specifications, talking an AT-protocol over a serial line. If GSM 07.10 is supported, we use the multiplexing daemon<br />
* [http://www.freesmartphone.org/index.php/Implementations/gsm0710muxd gsm0710muxd]<br />
to export virtual serial lines over -- again -- AT-protocol can be spoken.<br />
<br />
====Bluetooth====<br />
The low level Bluetooth services rely on the official Linux Bluetooth subsystem:<br />
* [http://www.bluez.org BlueZ].<br />
<br />
====GPS====<br />
The low level GPS services assume a GPS device that talks NMEA over a device node. We rely on the following software:<br />
* [http://gypsy.freedesktop.org Gypsy]<br />
<br />
====Network====<br />
The low level networking service assumes network interfaces, such as USB, Ethernet, Wifi, etc. We rely on the following software here:<br />
* Network Manager or Intel Connection Manager (undecided yet)<br />
* ppp<br />
<br />
===High Level===<br />
<br />
====Usage====<br />
The Usage subsystem is coordinating application I/O requirements preventing. Applications are not supposed to turn on or off devices, since they do not have any knowledge about concurrent applications that may be also using the device -- think ''reference counting'' for I/O requirements.<br />
<br />
With this added layer, we could later think about monitoring subsystems, subsystem usage statistics, or accounting.<br />
<br />
See discussion page about PolicyKit.<br />
<br />
====Events====<br />
* signaling events via I/O (ringing, blinking, vibrating)<br />
* might use fd.o notification API<br />
<br />
====PIM====<br />
An intelligent storage database server. This is being carried out as a Google Summer of Code project. See complete description [http://www.neo1973-germany.de/wiki/pyPimd here]<br />
<br />
====Context====<br />
* Intelligent context API, integrating location as one -- among other -- sources<br />
TBD<br />
Reference Geoclue<br />
<br />
====[http://www.freesmartphone.org/index.php/Standards/PhoneAPI Phone]====<br />
The phone subsystem can be used to create and manage voices communications. It makes abstraction of the protocol used.<br />
<br />
=== [http://www.freesmartphone.org/index.php/Implementations/OpenPreferencesDaemon Preferences] ===<br />
* settings database<br />
<br />
====Network====<br />
* high level networking queries<br />
<br />
=Implementation=<br />
<br />
===Completion Status===<br />
<br />
====Low Level====<br />
* device control: 50%<br />
* audio: 80%<br />
* GSM: 90%<br />
* GPRS: 90%<br />
* Bluetooth: 80%<br />
* GPS: 80%<br />
* Network: 50%<br />
<br />
====High Level====<br />
* Usage: 30%<br />
* Event: 30%<br />
* [http://www.freesmartphone.org/index.php/Implementations/OpenPreferencesDaemon Preferences]: 50%<br />
* Context: 0%<br />
* Telephony: 80%<br />
* Networking: 0%<br />
* PIM: 0%<br />
<br />
=The role of Python=<br />
<br />
Where we write new code, we will use Python to implement the dbus services. The reason for that being the rapid prototyping nature of Python and the emphasis on the Dbus APIs. Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++.<br />
<br />
Once the APIs have been used by application programmers, we can start profiling and possibly reimplement some of the services with daemons written in Vala, ''if'' necessary. We might as well succeed in improving performance by using Pyrex/Cython/Ctypes to keep the benefits of Python.<br />
<br />
=Team & Roadmap=<br />
<br />
==Team==<br />
<br />
* [[User:Mickey|Michael 'Mickey' Lauer]] (team leader) -- Openmoko freelancer, working in Frankfurt/Main, Germany.<br />
* [[User:Charlie| Guillaume 'Charlie' Chereau]] -- Openmoko employee, working fulltime in the Openmoko office, Taipei, Taiwan.<br />
* [[User:Shoragan|Jan 'Shoragan' Luebbe]] -- Openmoko student, working part-time in Brunswick, Germany.<br />
* [[User:DanielWillmann|Daniel 'Alphaone' Willmann]] -- Openmoko student, working part-time in Brunswick, Germany.<br />
* (Holger 'Zecke' Freyther -- hopefully joining the team after releasing ASU, working in Berlin, Germany.)<br />
<br />
'''Subsystem Ownership'''<br />
<br />
''Phase 1 subsystems''<br />
<br />
* odeviced (mickey)<br />
* ogsmd (mickey)<br />
* ousaged (jan)<br />
* oeventd (jan)<br />
* ophoned (guillaume)<br />
* opreferencesd (guillaume)<br />
* ocontextd (guillaume)<br />
* ogpsd (daniel)<br />
<br />
''Phase 2 subsystems''<br />
<br />
* network (to be defined)<br />
* pim (to be defined)<br />
<br />
==Roadmap==<br />
<br />
The milestone releases are combined Openmoko Framework and [[Zhone]] releases. Remember: A feature that isn't visible, working, and tested in our framework testing application (Zhone) does ''not'' exist. Until Framework 1.0.0 (later this year), we will not use any versioning in components. Afterwards, individual components may see individual releases.<br />
<br />
'''Note: The milestones and tasks moved over to our [http://trac.freesmartphone.org issue tracker].'''<br />
<br />
----<br />
<br />
[[Category:Framework| ]]</div>Charliehttp://openmoko.org/wiki/Talk:SHRTalk:SHR2008-07-21T08:47:53Z<p>Charlie: /* some thoughts */</p>
<hr />
<div>The freesmartphone framework daemons (ophoned, opreferencesd, odevicesd, etc...) have all been merged into a single daemon (frameworkd) So you will only need one package for all the freesmartphone functionalities. I am not sure yet of the stability of this daemon though.<br />
<br />
Also, if you are looking for a set of applications using the framework, maybe you want to have a look at tichy (disclamer : this is my project) : http://charlie137-2.blogspot.com/2008/07/introducing-tichy.html<br />
<br />
If you base your softwares on tichy, all you need to provide in you image is the freesmartphone framework, python, and a few standard python libraries.<br />
<br />
--[[User:Charlie|Charlie]] 11:43, 5 July 2008 (UTC)<br />
<br />
A conversation between roh, wurp, paulproteus about how to get started on the project:<br />
<pre><br />
Jul 04 02:37:30 <paulproteus> wurp2|away, Cool, but I'd rather talk about the old-apps-on-FSO project. (-:<br />
Jul 04 02:37:53 <paulproteus> I wonder if we can easily package this for opkg.<br />
Jul 04 02:38:04 <wurp2|away> paulproteus: Sounds good. Sorry, I wsa reading the backlog.<br />
Jul 04 02:38:10 <paulproteus> No prob!<br />
Jul 04 02:39:06 <wurp2|away> I kept asking mickey why someone wasn't doing this (SHR)<br />
Jul 04 02:39:37 <paulproteus> His answer was, everyone else is too busy?<br />
Jul 04 02:39:44 <wurp2|away> And he said someone should, and pointed out that you could just build a phonekit-to-ophoned adapter, so finally today I got off my duff and started it<br />
Jul 04 02:40:02 <wurp2|away> Yeah, I knew he & his little group was too busy<br />
Jul 04 02:40:28 <wurp2|away> But I thought someone from OM could take the relatively small amount of time it *seems* like it should take<br />
Jul 04 02:40:29 * paulproteus nods and listens<br />
Jul 04 02:40:43 <wurp2|away> But, hey, if you want something done...<br />
Jul 04 02:41:17 <wurp2|away> So I'm not sure I have much more to say that isn't on the wiki<br />
Jul 04 02:41:30 <wurp2|away> IMO the first step is to get a good FSO image running from our repo<br />
Jul 04 02:41:33 <roh> hey guys<br />
Jul 04 02:41:39 <paulproteus> Hey now roh.<br />
Jul 04 02:41:42 * mwester hides<br />
Jul 04 02:42:01 <nezza-_-> hey roh<br />
Jul 04 02:42:05 <wurp2|away> Then build a phonekit stub that openmoko2-dialer (or whatever the name is) can pretend to connect to<br />
Jul 04 02:42:06 <paulproteus> wurp2|away, I agree - the first thing to do is just cone the current branch and have a repeatable build system.<br />
Jul 04 02:42:08 <wurp2|away> Hi roh<br />
Jul 04 02:42:11 <roh> about your project... i think youre overshooting the goal by soundling like 'we need to fork'<br />
Jul 04 02:42:29 <paulproteus> I see it more as a branch than a fork. But can you explain what you mean?<br />
Jul 04 02:42:32 <roh> but i see your goal and like it.<br />
Jul 04 02:42:45 <wurp2> roh: If we can get away without it, that would be great. I want to minimize what we're doing<br />
Jul 04 02:42:51 <paulproteus> Hopefully, as FSO people get interested in this, our branch would get rebased and disappears into FSO.<br />
Jul 04 02:42:59 <roh> eventually you should just do it where the main fun happens. in the repos we have. here is what i suggest:<br />
Jul 04 02:42:59 * mwester thinks the community needs commit rights, whatever you call it (fork or whatever)<br />
Jul 04 02:43:09 <wurp2> I fished around for suggestions of how we could go about just labelling, or just branching specific files, but got no feel-good answers<br />
Jul 04 02:43:18 * wurp2 listens.<br />
Jul 04 02:43:31 <roh> you start hacking and coding, and i will see that there is a milestone in trac, where you can organize tickets in<br />
Jul 04 02:43:48 <paulproteus> roh, in the fso trac? I'm sold.<br />
Jul 04 02:43:56 <roh> also about commit-rights.. thats quite easy. currently 2007.2 is basically unmaintained<br />
Jul 04 02:44:22 <paulproteus> So any development would really be the only branch, anyway? (-:<br />
Jul 04 02:44:23 <roh> paulproteus i dunno for sure.<br />
Jul 04 02:44:28 <paulproteus> Sure, but basically.<br />
Jul 04 02:45:41 <roh> the point is: we are currently thinking about reorganizing the buildprocess anyways.. so i would say we should a) see to get less distro-trees b) have a branch where the man with the hat for the branch commits stuff to.<br />
Jul 04 02:46:04 <wurp2> roh: Just to make sure I understand: are you suggesting we commit to the 2007.2 tree?<br />
Jul 04 02:46:14 <paulproteus> That's in svn, right?<br />
Jul 04 02:46:22 <wurp2> or I can just keep listening until you're done with your point :-)<br />
Jul 04 02:46:28 <roh> but the main point is: 2007.2 apps are in the main svn, but unmaintained. if somebody steps up and basically claims maintainership by doing real work i see not why we should hinder that.<br />
Jul 04 02:47:01 <roh> my only concern about that all is: i do not see reason for 'forking' or cluttering stuff even more than it currently is.<br />
Jul 04 02:47:17 <paulproteus> Okay, I can agree with that.<br />
Jul 04 02:47:25 * jeffszusz tries to make sense of the convo<br />
Jul 04 02:47:25 <roh> on the contrary, we need to get better oversight. and thats not what happens by using more different repos<br />
Jul 04 02:47:26 <wurp2> roh: Sounds great!<br />
Jul 04 02:47:42 <paulproteus> Now as far as build process, we'd still use the git OE repos and improve the bitbake files there?<br />
Jul 04 02:47:44 * mwester notes that he currently has a rather poor attitude about OM branches and commits, and steps out of the conversation. :(<br />
Jul 04 02:47:48 <nullpuppy> ok. finally home, now to try and put together a build environment ;)<br />
Jul 04 02:47:57 <paulproteus> We'd just make our own branch in that central OM git repo?<br />
Jul 04 02:47:57 <roh> i dunno for sure, but atm i think we do a daily build of gta01 and gta02 org.openmoko.dev<br />
Jul 04 02:48:06 <roh> the asu branch as well..<br />
Jul 04 02:48:11 * jeffszusz didn't know there were forks/branches in OM<br />
Jul 04 02:48:13 <wurp2> So what do we do to get permission to check stuff into 2007.2?<br />
Jul 04 02:48:21 <roh> but i dunno who even uses these image (non-asu, old gtk based) or if they work at all.<br />
Jul 04 02:48:28 <paulproteus> Right.<br />
Jul 04 02:48:44 <alphabeat> dvarnes: http://wiki.openmoko.org/wiki/Group_Sales_Australia<br />
Jul 04 02:48:54 <wurp2> roh: They didn't work 3 weeks ago, then about 2 weeks ago someone said they (mostly) worked, but I dunno that they're maintained at all, as you say<br />
Jul 04 02:49:03 <roh> wurp2 submit patches. i mean.. the recipe for the 2007.11 stuff should have a fixed svnrev, so even if you would break it it should even have the old states.<br />
Jul 04 02:49:08 <wurp2> s/They/2007.2/<br />
Jul 04 02:49:09 <apt> wurp2 meant: roh: 2007.2 didn't work 3 weeks ago, then about 2 weeks ago someone said they (mostly) worked, but I dunno that they're maintained at all, as you say<br />
Jul 04 02:50:04 <roh> so i suggest: start hacking, start mailing patches.. i see that we clear up the repo as well as buildhost-situation.<br />
Jul 04 02:50:06 <dvarnes> alphabeat, yep .. already sent message to simon mathews with inquiry<br />
Jul 04 02:50:28 <wurp2> roh: OK, I'm very familiar with svn, and I have some experience with darcs and a knowledge of arch (RCSs like git)<br />
Jul 04 02:50:37 <wurp2> But I dunno how we would work off an svn tree<br />
Jul 04 02:50:41 <paulproteus> wurp2, IMHO we should use a git-svn repository to work on our patches then.<br />
Jul 04 02:50:42 <wurp2> and easily share changes with one another<br />
Jul 04 02:50:49 <paulproteus> That is quite feasible.<br />
Jul 04 02:50:56 <roh> its a 2-part story.. one part is basic distribution-building work (means should happen in a branch or head on git)<br />
Jul 04 02:50:59 <paulproteus> Another thing is to try quilt.<br />
Jul 04 02:51:00 <wurp2> then submit patches once we're happy to whoever to merge into main tree<br />
Jul 04 02:51:12 <paulproteus> I have to run in a minute, I'm very sorry to say!<br />
Jul 04 02:51:13 <roh> the other part is porting and changing applications, which should happen where the app lives.<br />
Jul 04 02:51:16 <wurp2> roh: Ah, I'm familiar with how to do it (basically) in git<br />
Jul 04 02:51:29 <paulproteus> roh, Yes, re: distribution work: would we get a branch in the main OM git then?<br />
Jul 04 02:51:35 <paulproteus> That would be fantastic.<br />
Jul 04 02:51:51 <paulproteus> And I *really* appreciate you stepping in here.<br />
Jul 04 02:51:56 <roh> i think that it would be the best way to do this.<br />
Jul 04 02:52:12 <alphabeat> dvarnes: might be a little late. i think he bought a few as overhead so you might be lucky :) we bought 60 but only needed 53 or something<br />
Jul 04 02:52:27 <wurp2> OK, I saw svn sneak in there for a bit, now we're talking about git again... which parts are git and which are svn?<br />
Jul 04 02:52:34 <paulproteus> svn for apps; git for OE work<br />
Jul 04 02:53:15 <wurp2> paulproteus: And you said quilt is a tool to help us share changes in our group, then create patches to submit to the main svn?<br />
Jul 04 02:53:15 <paulproteus> Email patches for apps, and get them in a state to use the FSO backend that way, sharing work between us before they're ready for submission using git-svn.<br />
Jul 04 02:53:16 <paulproteus> git for OE work - we'd get a branch in the OM git.<br />
Jul 04 02:53:16 <paulproteus> That's what I understand.<br />
Jul 04 02:53:26 <paulproteus> wurp2, Yes, quilt is an alternative to git-svn in this workflow.<br />
Jul 04 02:53:27 <Dave> We meet again, Mr. Wurp.<br />
Jul 04 02:53:38 <wurp2> wurp2: Ah, I think I prefer git-svn<br />
Jul 04 02:53:41 <paulproteus> I think so too.<br />
Jul 04 02:53:41 <wurp2> Dave: howdy<br />
Jul 04 02:53:52 <Dave> Howdy ya'll<br />
Jul 04 02:54:06 <wurp2> So we work in git, get it how we like it, then we create a patch<br />
Jul 04 02:54:14 <wurp2> keeping our git in sync w/ svn via git-svn<br />
Jul 04 02:54:25 <roh> wurp2 ?<br />
Jul 04 02:54:29 <wurp2> (er, and we submit the patch back to the svn owner, of course)<br />
Jul 04 02:54:29 <Dave> yep yep :)<br />
Jul 04 02:54:45 <wurp2> roh: Did I drift into crazy talk?<br />
Jul 04 02:55:04 <roh> i do not care how you branch/merge on your machine, but my point is that the app itself currently resides in svn.. and the distro which is 'one layer above' is in git<br />
Jul 04 02:55:10 * jeffszusz pulls out his cardboard Freerunner and pretends to talk on it<br />
Jul 04 02:55:26 <wurp2> roh: I think I understood that<br />
Jul 04 02:55:31 <Dave> Is this not self-evident enough from the repositories themselves?<br />
Jul 04 02:55:44 <Dave> jeffszusz: whoa, cool man, where can I get one? :D<br />
Jul 04 02:55:46 <roh> Dave since we have loads of them, sadly not all the time.<br />
Jul 04 02:55:53 <wurp2> roh: And dealing with the distro seems straightforward; we create a git repo that is a "child"(branch) of the main repo<br />
Jul 04 02:55:57 <Dave> Yeah, I noticed that too, roh :)<br />
Jul 04 02:56:04 <paulproteus> I have to run in 30-60s (-:<br />
Jul 04 02:56:04 <wurp2> and can submit changes back<br />
Jul 04 02:56:11 <wurp2> paulproteus: bye :-(<br />
Jul 04 02:56:15 <SpeedEvil> How long are confirmation emails taking to get sent out?<br />
Jul 04 02:56:19 <Dave> Even occasionally, and if it weren't for tagging, I'd mistake one for another frequently :)<br />
Jul 04 02:56:24 <jeffszusz> Dave: print, cut, paste!<br />
Jul 04 02:56:30 <paulproteus> wurp2, Right - we'll commit to a branch in OM git, and then we can ask the other branches to merge or cherry-pick our changes.<br />
Jul 04 02:56:33 <roh> also most projects are just about apps and not about 'lets build a device.. and while were at it write drivers for it.. ah.. and bootloaders.. and apps.-. and then package it in a linux-distri<br />
Jul 04 02:56:35 <SpeedEvil> Someone not had one after 3.5 hours. Is that overly delayed?<br />
Jul 04 02:56:47 <Dave> heh, true enough :)<br />
Jul 04 02:56:59 <wurp2> roh: But for apps, it seems that we need some way to share changes amongst ourselves w/o waiting for the patch to get accepted into the mainline, or even in some cases when we have things that aren't quite complete, that need another team member to finish<br />
Jul 04 02:56:59 <alphabeat> jeffzusz: did you print out the CAD file and make your own phone out of cardboard too?<br />
Jul 04 02:57:31 <roh> wurp2 for testing they could be applied in the distro dev branch.<br />
Jul 04 02:57:32 <jeffszusz> alphabeat: nope, but i'm tempted<br />
Jul 04 02:57:33 <dvarnes> alphabeat, yep .. understood .. I had looked a couple of times at the Group page, but the Aus one is not linked, so missed it. Not urgent since I already have a Neo :-) Still, am plannig to order a FR .. <br />
Jul 04 02:57:54 <Dave> Oh, I should write that report to the ml now.<br />
Jul 04 02:58:00 <wurp2> roh: So we were suggesting a SHR specific git repo, that would drift a bit from the app's svn until we get small changesets complete, then we would create patches<br />
Jul 04 02:58:05 <paulproteus> You guys, please store the results of this discussion on that wiki page.<br />
Jul 04 02:58:05 <paulproteus> Bye!<br />
Jul 04 02:58:13 <roh> i guess it would start with a -dev only branch.. if that then takes 'form' make it a stable one and branch the new --dev<br />
Jul 04 02:58:15 <wurp2> and keep our git repo in sync w/ the app repo via svn-git<br />
Jul 04 02:58:21 <roh> (the distro)<br />
Jul 04 02:58:43 <digitalslave> <would be happy just to get the emulator to compile blac<br />
Jul 04 02:58:44 * jeffszusz is realizing how little he knows about the progress of OpenMoko<br />
Jul 04 02:58:46 <wurp2> OK<br />
Jul 04 02:58:56 <roh> testing patches is in -dev as patch in oe.. then merge it into the repo (work with minrev and maxrev in the recipes)<br />
Jul 04 02:59:04 <wurp2> I'm hoping that our actual changes are fairly minimal<br />
Jul 04 02:59:48 <roh> i guess so. even then.. really.. nobody would want to hinder future maintainers of apps to evolve ;)<br />
Jul 04 02:59:57 <wurp2> A replacement for phonekit that delegates to ophoned, and a recipe to pull in compatible versions of all the basic apps<br />
Jul 04 02:59:59 <digitalslave> cd ..<br />
Jul 04 02:59:59 <digitalslave> ls<br />
Jul 04 03:00:06 <alphabeat> dvarnes: it looks like he ordered 60 with 52 phones confirmed and payed for and 6 phones unconfirmed which leaves 2 spare. might be lucky hey? ps jealous of buying a neo1973. should have got one :P<br />
Jul 04 03:00:13 <wurp2> digitalslave: Wrong window?<br />
Jul 04 03:00:27 <digitalslave> haha yep damn track pad heh<br />
Jul 04 03:00:48 <wurp2> digitalslave: At least it wasn't your root password<br />
Jul 04 03:01:06 <jeffszusz> wurp2: i did that before<br />
Jul 04 03:01:11 <digitalslave> hahaha<br />
Jul 04 03:01:21 <alphabeat> wurp2|jeffszusz: yah me too xD<br />
Jul 04 03:01:31 <wurp2> roh: I'll have to learn some more more before your -dev and --dev and minrev/maxrev stuff make sense to me :-)<br />
Jul 04 03:01:34 <digitalslave> i like reading all the logs at work from everyone putting there password in for their username :)<br />
Jul 04 03:01:38 <jeffszusz> i was due for a new password anyway... but i was lucky nobody used it before i had a chance to change it<br />
Jul 04 03:01:38 <jeffszusz> heh<br />
Jul 04 03:01:45 <wurp2> alphabeat, jeffszusz: :-(<br />
Jul 04 03:01:50 <alphabeat> digitalslave: you're evil! i like that<br />
Jul 04 03:02:11 <wurp2> It's also amazing what you'll see on a nic in promiscuous mode<br />
Jul 04 03:02:21 <digitalslave> haha true that!<br />
Jul 04 03:02:28 <roh> wurp2 in oe recipes one can define max, min or ranges thus of revisions which patches get applied.<br />
Jul 04 03:02:30 <wurp2> Like people's pwds on all the sites that didn't know enough to use https for login form submission<br />
Jul 04 03:03:04 <roh> wurp2 so if the patch which gets applied is merged, one sets the maxrev to one version below or so (atleast thats how i got it)<br />
Jul 04 03:03:14 <wurp2> roh: I see<br />
Jul 04 03:04:45 <wurp2> roh: How do we submit patches? openmoko-devel? Or is there a list of private email addys?<br />
Jul 04 03:05:08 <roh> yeah.. just the list<br />
Jul 04 03:05:16 <roh> or if you think it makes sense we <br />
Jul 04 03:05:31 <roh> eh we can add a milestone and you add them as attachment to tickets<br />
Jul 04 03:06:06 <wurp2> roh: That could work too... it seems like it would feel more reliable<br />
Jul 04 03:06:22 <wurp2> roh: As in, we can see a comment on the ticket that says submitted, and don't have to search email logs for it<br />
Jul 04 03:06:34 <roh> well.. its only how the 'group' of developers plans its workflow<br />
Jul 04 03:07:01 <wurp2> roh: Is there any material I can read to get some clues about this?<br />
Jul 04 03:07:19 <roh> eh.. which part<br />
Jul 04 03:07:31 <wurp2> Whichever parts have docs :-)<br />
Jul 04 03:07:43 <roh> ehehe<br />
Jul 04 03:08:01 <roh> well.. trac is easy.. it has documentation<br />
Jul 04 03:08:03 <wurp2> bitbake, how you're using milestones, what the procedure has been to submit patches in the past<br />
Jul 04 03:08:12 <wurp2> OK<br />
Jul 04 03:08:20 <wurp2> I've had "read up on trac" in my todo for a long time<br />
Jul 04 03:08:26 <wurp2> Now I guess I'll actually do it<br />
Jul 04 03:08:37 <roh> submitting patches... eh.. well..the opensource-default.. send by mail, do not mangle long lines ;)<br />
Jul 04 03:08:45 <roh> use diff -u eh svn diff -u<br />
Jul 04 03:09:09 <wurp2> Yeah, for that I was more concerned with internal procedures<br />
Jul 04 03:09:33 <wurp2> But I'm not even sure what the questoins are right now, so I'll just try it the way that seems obvious the first time<br />
Jul 04 03:09:34 <Dave> i.e. how the cabal performs its rituals ;)<br />
Jul 04 03:09:37 <wurp2> And get corrected<br />
Jul 04 03:09:44 <wurp2> Dave: exactly<br />
Jul 04 03:09:48 <wurp2> tribal knowledge<br />
Jul 04 03:09:52 <Dave> :)<br />
Jul 04 03:10:11 <Dave> Every tribe is different ;)<br />
Jul 04 03:10:23 <roh> wurp2 i think currently we are happy if people can code and submit good patches.. one easily looks over process minors then<br />
Jul 04 03:10:45 <Dave> That sounds encouraging.<br />
Jul 04 03:10:48 <wurp2> Well, I can code & submit patches<br />
Jul 04 03:10:58 <wurp2> We'll see if you conclude they are good or not ;-)<br />
Jul 04 03:11:27 <Dave> We'll see if you get voted off the island or not. ;)<br />
Jul 04 03:12:12 <wurp2> OK, 2007.2 is OM distro, right? Not apps, mostly?<br />
Jul 04 03:12:30 <wurp2> and 2007.2 is a git branch, yes?<br />
Jul 04 03:17:46 <roh> 2007.2 is a set of apps om did<br />
Jul 04 03:18:59 <wurp2> roh: OK<br />
</pre><br />
<br />
== some thoughts ==<br />
<br />
I was wondering what's the difference between this planned SHR and future release of FSO ? I mean, FSO is really great but lacks apps for the moment ; you're planning to port these apps from the GTK or the QT apps.<br />
<br />
Why not contribute these ported applications to the FSO milestone 2 ?<br />
<br />
I believe you should explain that in the page (or maybe I'm just confused by the description)<br />
<br />
[[user:jeremy-list|Jeremy List]]: Presuming this titchy thing is fairly lightweight in requirements it could be ideal for the main UI. However it needs a way of handling more items than will fit on the screen (for example, a scrollbar). and I would prefer using something with a different colour scheme.<br />
<br />
: Jeremy : tichy already supports scrolling (I need to make it looks better and faster though), there is also a style system, that allow to dynamically modify not only the color scheme, but also the widgets sizes and look. Beside I modified the default look so that it is better by default. Check out the svn repository for a demonstration. It works fine even on desktop computer, without compiling. --[[User:Charlie|Charlie]] 08:47, 21 July 2008 (UTC)</div>Charliehttp://openmoko.org/wiki/Talk:SHRTalk:SHR2008-07-05T11:43:16Z<p>Charlie: </p>
<hr />
<div>The freesmartphone framework daemons (ophoned, opreferencesd, odevicesd, etc...) have all been merged into a single daemon (frameworkd) So you will only need one package for all the freesmartphone functionalities. I am not sure yet of the stability of this daemon though.<br />
<br />
Also, if you are looking for a set of applications using the framework, maybe you want to have a look at tichy (disclamer : this is my project) : http://charlie137-2.blogspot.com/2008/07/introducing-tichy.html<br />
<br />
If you base your softwares on tichy, all you need to provide in you image is the freesmartphone framework, python, and a few standard python libraries.<br />
<br />
--[[User:Charlie|Charlie]] 11:43, 5 July 2008 (UTC)<br />
<br />
A conversation between roh, wurp, paulproteus about how to get started on the project:<br />
<pre><br />
Jul 04 02:37:30 <paulproteus> wurp2|away, Cool, but I'd rather talk about the old-apps-on-FSO project. (-:<br />
Jul 04 02:37:53 <paulproteus> I wonder if we can easily package this for opkg.<br />
Jul 04 02:38:04 <wurp2|away> paulproteus: Sounds good. Sorry, I wsa reading the backlog.<br />
Jul 04 02:38:10 <paulproteus> No prob!<br />
Jul 04 02:39:06 <wurp2|away> I kept asking mickey why someone wasn't doing this (SHR)<br />
Jul 04 02:39:37 <paulproteus> His answer was, everyone else is too busy?<br />
Jul 04 02:39:44 <wurp2|away> And he said someone should, and pointed out that you could just build a phonekit-to-ophoned adapter, so finally today I got off my duff and started it<br />
Jul 04 02:40:02 <wurp2|away> Yeah, I knew he & his little group was too busy<br />
Jul 04 02:40:28 <wurp2|away> But I thought someone from OM could take the relatively small amount of time it *seems* like it should take<br />
Jul 04 02:40:29 * paulproteus nods and listens<br />
Jul 04 02:40:43 <wurp2|away> But, hey, if you want something done...<br />
Jul 04 02:41:17 <wurp2|away> So I'm not sure I have much more to say that isn't on the wiki<br />
Jul 04 02:41:30 <wurp2|away> IMO the first step is to get a good FSO image running from our repo<br />
Jul 04 02:41:33 <roh> hey guys<br />
Jul 04 02:41:39 <paulproteus> Hey now roh.<br />
Jul 04 02:41:42 * mwester hides<br />
Jul 04 02:42:01 <nezza-_-> hey roh<br />
Jul 04 02:42:05 <wurp2|away> Then build a phonekit stub that openmoko2-dialer (or whatever the name is) can pretend to connect to<br />
Jul 04 02:42:06 <paulproteus> wurp2|away, I agree - the first thing to do is just cone the current branch and have a repeatable build system.<br />
Jul 04 02:42:08 <wurp2|away> Hi roh<br />
Jul 04 02:42:11 <roh> about your project... i think youre overshooting the goal by soundling like 'we need to fork'<br />
Jul 04 02:42:29 <paulproteus> I see it more as a branch than a fork. But can you explain what you mean?<br />
Jul 04 02:42:32 <roh> but i see your goal and like it.<br />
Jul 04 02:42:45 <wurp2> roh: If we can get away without it, that would be great. I want to minimize what we're doing<br />
Jul 04 02:42:51 <paulproteus> Hopefully, as FSO people get interested in this, our branch would get rebased and disappears into FSO.<br />
Jul 04 02:42:59 <roh> eventually you should just do it where the main fun happens. in the repos we have. here is what i suggest:<br />
Jul 04 02:42:59 * mwester thinks the community needs commit rights, whatever you call it (fork or whatever)<br />
Jul 04 02:43:09 <wurp2> I fished around for suggestions of how we could go about just labelling, or just branching specific files, but got no feel-good answers<br />
Jul 04 02:43:18 * wurp2 listens.<br />
Jul 04 02:43:31 <roh> you start hacking and coding, and i will see that there is a milestone in trac, where you can organize tickets in<br />
Jul 04 02:43:48 <paulproteus> roh, in the fso trac? I'm sold.<br />
Jul 04 02:43:56 <roh> also about commit-rights.. thats quite easy. currently 2007.2 is basically unmaintained<br />
Jul 04 02:44:22 <paulproteus> So any development would really be the only branch, anyway? (-:<br />
Jul 04 02:44:23 <roh> paulproteus i dunno for sure.<br />
Jul 04 02:44:28 <paulproteus> Sure, but basically.<br />
Jul 04 02:45:41 <roh> the point is: we are currently thinking about reorganizing the buildprocess anyways.. so i would say we should a) see to get less distro-trees b) have a branch where the man with the hat for the branch commits stuff to.<br />
Jul 04 02:46:04 <wurp2> roh: Just to make sure I understand: are you suggesting we commit to the 2007.2 tree?<br />
Jul 04 02:46:14 <paulproteus> That's in svn, right?<br />
Jul 04 02:46:22 <wurp2> or I can just keep listening until you're done with your point :-)<br />
Jul 04 02:46:28 <roh> but the main point is: 2007.2 apps are in the main svn, but unmaintained. if somebody steps up and basically claims maintainership by doing real work i see not why we should hinder that.<br />
Jul 04 02:47:01 <roh> my only concern about that all is: i do not see reason for 'forking' or cluttering stuff even more than it currently is.<br />
Jul 04 02:47:17 <paulproteus> Okay, I can agree with that.<br />
Jul 04 02:47:25 * jeffszusz tries to make sense of the convo<br />
Jul 04 02:47:25 <roh> on the contrary, we need to get better oversight. and thats not what happens by using more different repos<br />
Jul 04 02:47:26 <wurp2> roh: Sounds great!<br />
Jul 04 02:47:42 <paulproteus> Now as far as build process, we'd still use the git OE repos and improve the bitbake files there?<br />
Jul 04 02:47:44 * mwester notes that he currently has a rather poor attitude about OM branches and commits, and steps out of the conversation. :(<br />
Jul 04 02:47:48 <nullpuppy> ok. finally home, now to try and put together a build environment ;)<br />
Jul 04 02:47:57 <paulproteus> We'd just make our own branch in that central OM git repo?<br />
Jul 04 02:47:57 <roh> i dunno for sure, but atm i think we do a daily build of gta01 and gta02 org.openmoko.dev<br />
Jul 04 02:48:06 <roh> the asu branch as well..<br />
Jul 04 02:48:11 * jeffszusz didn't know there were forks/branches in OM<br />
Jul 04 02:48:13 <wurp2> So what do we do to get permission to check stuff into 2007.2?<br />
Jul 04 02:48:21 <roh> but i dunno who even uses these image (non-asu, old gtk based) or if they work at all.<br />
Jul 04 02:48:28 <paulproteus> Right.<br />
Jul 04 02:48:44 <alphabeat> dvarnes: http://wiki.openmoko.org/wiki/Group_Sales_Australia<br />
Jul 04 02:48:54 <wurp2> roh: They didn't work 3 weeks ago, then about 2 weeks ago someone said they (mostly) worked, but I dunno that they're maintained at all, as you say<br />
Jul 04 02:49:03 <roh> wurp2 submit patches. i mean.. the recipe for the 2007.11 stuff should have a fixed svnrev, so even if you would break it it should even have the old states.<br />
Jul 04 02:49:08 <wurp2> s/They/2007.2/<br />
Jul 04 02:49:09 <apt> wurp2 meant: roh: 2007.2 didn't work 3 weeks ago, then about 2 weeks ago someone said they (mostly) worked, but I dunno that they're maintained at all, as you say<br />
Jul 04 02:50:04 <roh> so i suggest: start hacking, start mailing patches.. i see that we clear up the repo as well as buildhost-situation.<br />
Jul 04 02:50:06 <dvarnes> alphabeat, yep .. already sent message to simon mathews with inquiry<br />
Jul 04 02:50:28 <wurp2> roh: OK, I'm very familiar with svn, and I have some experience with darcs and a knowledge of arch (RCSs like git)<br />
Jul 04 02:50:37 <wurp2> But I dunno how we would work off an svn tree<br />
Jul 04 02:50:41 <paulproteus> wurp2, IMHO we should use a git-svn repository to work on our patches then.<br />
Jul 04 02:50:42 <wurp2> and easily share changes with one another<br />
Jul 04 02:50:49 <paulproteus> That is quite feasible.<br />
Jul 04 02:50:56 <roh> its a 2-part story.. one part is basic distribution-building work (means should happen in a branch or head on git)<br />
Jul 04 02:50:59 <paulproteus> Another thing is to try quilt.<br />
Jul 04 02:51:00 <wurp2> then submit patches once we're happy to whoever to merge into main tree<br />
Jul 04 02:51:12 <paulproteus> I have to run in a minute, I'm very sorry to say!<br />
Jul 04 02:51:13 <roh> the other part is porting and changing applications, which should happen where the app lives.<br />
Jul 04 02:51:16 <wurp2> roh: Ah, I'm familiar with how to do it (basically) in git<br />
Jul 04 02:51:29 <paulproteus> roh, Yes, re: distribution work: would we get a branch in the main OM git then?<br />
Jul 04 02:51:35 <paulproteus> That would be fantastic.<br />
Jul 04 02:51:51 <paulproteus> And I *really* appreciate you stepping in here.<br />
Jul 04 02:51:56 <roh> i think that it would be the best way to do this.<br />
Jul 04 02:52:12 <alphabeat> dvarnes: might be a little late. i think he bought a few as overhead so you might be lucky :) we bought 60 but only needed 53 or something<br />
Jul 04 02:52:27 <wurp2> OK, I saw svn sneak in there for a bit, now we're talking about git again... which parts are git and which are svn?<br />
Jul 04 02:52:34 <paulproteus> svn for apps; git for OE work<br />
Jul 04 02:53:15 <wurp2> paulproteus: And you said quilt is a tool to help us share changes in our group, then create patches to submit to the main svn?<br />
Jul 04 02:53:15 <paulproteus> Email patches for apps, and get them in a state to use the FSO backend that way, sharing work between us before they're ready for submission using git-svn.<br />
Jul 04 02:53:16 <paulproteus> git for OE work - we'd get a branch in the OM git.<br />
Jul 04 02:53:16 <paulproteus> That's what I understand.<br />
Jul 04 02:53:26 <paulproteus> wurp2, Yes, quilt is an alternative to git-svn in this workflow.<br />
Jul 04 02:53:27 <Dave> We meet again, Mr. Wurp.<br />
Jul 04 02:53:38 <wurp2> wurp2: Ah, I think I prefer git-svn<br />
Jul 04 02:53:41 <paulproteus> I think so too.<br />
Jul 04 02:53:41 <wurp2> Dave: howdy<br />
Jul 04 02:53:52 <Dave> Howdy ya'll<br />
Jul 04 02:54:06 <wurp2> So we work in git, get it how we like it, then we create a patch<br />
Jul 04 02:54:14 <wurp2> keeping our git in sync w/ svn via git-svn<br />
Jul 04 02:54:25 <roh> wurp2 ?<br />
Jul 04 02:54:29 <wurp2> (er, and we submit the patch back to the svn owner, of course)<br />
Jul 04 02:54:29 <Dave> yep yep :)<br />
Jul 04 02:54:45 <wurp2> roh: Did I drift into crazy talk?<br />
Jul 04 02:55:04 <roh> i do not care how you branch/merge on your machine, but my point is that the app itself currently resides in svn.. and the distro which is 'one layer above' is in git<br />
Jul 04 02:55:10 * jeffszusz pulls out his cardboard Freerunner and pretends to talk on it<br />
Jul 04 02:55:26 <wurp2> roh: I think I understood that<br />
Jul 04 02:55:31 <Dave> Is this not self-evident enough from the repositories themselves?<br />
Jul 04 02:55:44 <Dave> jeffszusz: whoa, cool man, where can I get one? :D<br />
Jul 04 02:55:46 <roh> Dave since we have loads of them, sadly not all the time.<br />
Jul 04 02:55:53 <wurp2> roh: And dealing with the distro seems straightforward; we create a git repo that is a "child"(branch) of the main repo<br />
Jul 04 02:55:57 <Dave> Yeah, I noticed that too, roh :)<br />
Jul 04 02:56:04 <paulproteus> I have to run in 30-60s (-:<br />
Jul 04 02:56:04 <wurp2> and can submit changes back<br />
Jul 04 02:56:11 <wurp2> paulproteus: bye :-(<br />
Jul 04 02:56:15 <SpeedEvil> How long are confirmation emails taking to get sent out?<br />
Jul 04 02:56:19 <Dave> Even occasionally, and if it weren't for tagging, I'd mistake one for another frequently :)<br />
Jul 04 02:56:24 <jeffszusz> Dave: print, cut, paste!<br />
Jul 04 02:56:30 <paulproteus> wurp2, Right - we'll commit to a branch in OM git, and then we can ask the other branches to merge or cherry-pick our changes.<br />
Jul 04 02:56:33 <roh> also most projects are just about apps and not about 'lets build a device.. and while were at it write drivers for it.. ah.. and bootloaders.. and apps.-. and then package it in a linux-distri<br />
Jul 04 02:56:35 <SpeedEvil> Someone not had one after 3.5 hours. Is that overly delayed?<br />
Jul 04 02:56:47 <Dave> heh, true enough :)<br />
Jul 04 02:56:59 <wurp2> roh: But for apps, it seems that we need some way to share changes amongst ourselves w/o waiting for the patch to get accepted into the mainline, or even in some cases when we have things that aren't quite complete, that need another team member to finish<br />
Jul 04 02:56:59 <alphabeat> jeffzusz: did you print out the CAD file and make your own phone out of cardboard too?<br />
Jul 04 02:57:31 <roh> wurp2 for testing they could be applied in the distro dev branch.<br />
Jul 04 02:57:32 <jeffszusz> alphabeat: nope, but i'm tempted<br />
Jul 04 02:57:33 <dvarnes> alphabeat, yep .. understood .. I had looked a couple of times at the Group page, but the Aus one is not linked, so missed it. Not urgent since I already have a Neo :-) Still, am plannig to order a FR .. <br />
Jul 04 02:57:54 <Dave> Oh, I should write that report to the ml now.<br />
Jul 04 02:58:00 <wurp2> roh: So we were suggesting a SHR specific git repo, that would drift a bit from the app's svn until we get small changesets complete, then we would create patches<br />
Jul 04 02:58:05 <paulproteus> You guys, please store the results of this discussion on that wiki page.<br />
Jul 04 02:58:05 <paulproteus> Bye!<br />
Jul 04 02:58:13 <roh> i guess it would start with a -dev only branch.. if that then takes 'form' make it a stable one and branch the new --dev<br />
Jul 04 02:58:15 <wurp2> and keep our git repo in sync w/ the app repo via svn-git<br />
Jul 04 02:58:21 <roh> (the distro)<br />
Jul 04 02:58:43 <digitalslave> <would be happy just to get the emulator to compile blac<br />
Jul 04 02:58:44 * jeffszusz is realizing how little he knows about the progress of OpenMoko<br />
Jul 04 02:58:46 <wurp2> OK<br />
Jul 04 02:58:56 <roh> testing patches is in -dev as patch in oe.. then merge it into the repo (work with minrev and maxrev in the recipes)<br />
Jul 04 02:59:04 <wurp2> I'm hoping that our actual changes are fairly minimal<br />
Jul 04 02:59:48 <roh> i guess so. even then.. really.. nobody would want to hinder future maintainers of apps to evolve ;)<br />
Jul 04 02:59:57 <wurp2> A replacement for phonekit that delegates to ophoned, and a recipe to pull in compatible versions of all the basic apps<br />
Jul 04 02:59:59 <digitalslave> cd ..<br />
Jul 04 02:59:59 <digitalslave> ls<br />
Jul 04 03:00:06 <alphabeat> dvarnes: it looks like he ordered 60 with 52 phones confirmed and payed for and 6 phones unconfirmed which leaves 2 spare. might be lucky hey? ps jealous of buying a neo1973. should have got one :P<br />
Jul 04 03:00:13 <wurp2> digitalslave: Wrong window?<br />
Jul 04 03:00:27 <digitalslave> haha yep damn track pad heh<br />
Jul 04 03:00:48 <wurp2> digitalslave: At least it wasn't your root password<br />
Jul 04 03:01:06 <jeffszusz> wurp2: i did that before<br />
Jul 04 03:01:11 <digitalslave> hahaha<br />
Jul 04 03:01:21 <alphabeat> wurp2|jeffszusz: yah me too xD<br />
Jul 04 03:01:31 <wurp2> roh: I'll have to learn some more more before your -dev and --dev and minrev/maxrev stuff make sense to me :-)<br />
Jul 04 03:01:34 <digitalslave> i like reading all the logs at work from everyone putting there password in for their username :)<br />
Jul 04 03:01:38 <jeffszusz> i was due for a new password anyway... but i was lucky nobody used it before i had a chance to change it<br />
Jul 04 03:01:38 <jeffszusz> heh<br />
Jul 04 03:01:45 <wurp2> alphabeat, jeffszusz: :-(<br />
Jul 04 03:01:50 <alphabeat> digitalslave: you're evil! i like that<br />
Jul 04 03:02:11 <wurp2> It's also amazing what you'll see on a nic in promiscuous mode<br />
Jul 04 03:02:21 <digitalslave> haha true that!<br />
Jul 04 03:02:28 <roh> wurp2 in oe recipes one can define max, min or ranges thus of revisions which patches get applied.<br />
Jul 04 03:02:30 <wurp2> Like people's pwds on all the sites that didn't know enough to use https for login form submission<br />
Jul 04 03:03:04 <roh> wurp2 so if the patch which gets applied is merged, one sets the maxrev to one version below or so (atleast thats how i got it)<br />
Jul 04 03:03:14 <wurp2> roh: I see<br />
Jul 04 03:04:45 <wurp2> roh: How do we submit patches? openmoko-devel? Or is there a list of private email addys?<br />
Jul 04 03:05:08 <roh> yeah.. just the list<br />
Jul 04 03:05:16 <roh> or if you think it makes sense we <br />
Jul 04 03:05:31 <roh> eh we can add a milestone and you add them as attachment to tickets<br />
Jul 04 03:06:06 <wurp2> roh: That could work too... it seems like it would feel more reliable<br />
Jul 04 03:06:22 <wurp2> roh: As in, we can see a comment on the ticket that says submitted, and don't have to search email logs for it<br />
Jul 04 03:06:34 <roh> well.. its only how the 'group' of developers plans its workflow<br />
Jul 04 03:07:01 <wurp2> roh: Is there any material I can read to get some clues about this?<br />
Jul 04 03:07:19 <roh> eh.. which part<br />
Jul 04 03:07:31 <wurp2> Whichever parts have docs :-)<br />
Jul 04 03:07:43 <roh> ehehe<br />
Jul 04 03:08:01 <roh> well.. trac is easy.. it has documentation<br />
Jul 04 03:08:03 <wurp2> bitbake, how you're using milestones, what the procedure has been to submit patches in the past<br />
Jul 04 03:08:12 <wurp2> OK<br />
Jul 04 03:08:20 <wurp2> I've had "read up on trac" in my todo for a long time<br />
Jul 04 03:08:26 <wurp2> Now I guess I'll actually do it<br />
Jul 04 03:08:37 <roh> submitting patches... eh.. well..the opensource-default.. send by mail, do not mangle long lines ;)<br />
Jul 04 03:08:45 <roh> use diff -u eh svn diff -u<br />
Jul 04 03:09:09 <wurp2> Yeah, for that I was more concerned with internal procedures<br />
Jul 04 03:09:33 <wurp2> But I'm not even sure what the questoins are right now, so I'll just try it the way that seems obvious the first time<br />
Jul 04 03:09:34 <Dave> i.e. how the cabal performs its rituals ;)<br />
Jul 04 03:09:37 <wurp2> And get corrected<br />
Jul 04 03:09:44 <wurp2> Dave: exactly<br />
Jul 04 03:09:48 <wurp2> tribal knowledge<br />
Jul 04 03:09:52 <Dave> :)<br />
Jul 04 03:10:11 <Dave> Every tribe is different ;)<br />
Jul 04 03:10:23 <roh> wurp2 i think currently we are happy if people can code and submit good patches.. one easily looks over process minors then<br />
Jul 04 03:10:45 <Dave> That sounds encouraging.<br />
Jul 04 03:10:48 <wurp2> Well, I can code & submit patches<br />
Jul 04 03:10:58 <wurp2> We'll see if you conclude they are good or not ;-)<br />
Jul 04 03:11:27 <Dave> We'll see if you get voted off the island or not. ;)<br />
Jul 04 03:12:12 <wurp2> OK, 2007.2 is OM distro, right? Not apps, mostly?<br />
Jul 04 03:12:30 <wurp2> and 2007.2 is a git branch, yes?<br />
Jul 04 03:17:46 <roh> 2007.2 is a set of apps om did<br />
Jul 04 03:18:59 <wurp2> roh: OK<br />
</pre></div>Charliehttp://openmoko.org/wiki/OpenmokoFrameworkOpenmokoFramework2008-06-17T06:31:34Z<p>Charlie: /* Preferences */</p>
<hr />
<div>{{Languages|OpenmokoFramework}}<br />
{{Introbox}}<br />
''Note: This is the (ongoing) description of the new framework architecture that is '''in development'''. See [[OpenmokoOldFramework]] for the framework architecture of 2007.1 and 2007.2 and [[NeoSoftwareStack]] for the current status (which has nothing to do yet with this framework)''<br />
<br />
=Answering the TOP x questions=<br />
* ''Question 1'': Is this a part of the current images yet?<br />
* ''Answer'': No.<br />
* ''Question 2'': Is this the mystic ASU?<br />
* ''Answer'': No.<br />
* ''Question 3'': When can I see this as part of an image?<br />
* ''Answer'': See roadmap at the bottom of this document. It's going to be an interesting autumn and winter '08 ;)<br />
* ''Question 4'': What's the current status?<br />
* ''Answer'': See right below:<br />
** [[OpenmokoFramework/Status Update 1|Status Update 1]]<br />
<br />
=Purposes=<br />
* '''Give people the infrastructure to create solid and exciting software products based on the Openmoko platform'''<br />
* '''Support competing UIs while collaborating on developing services'''<br />
* '''Encourage framework users (e.g. application developers) to also contribute to the framework'''<br />
<br />
=Requirements=<br />
* Make it simple<br />
* Concentrate on core services<br />
* Be programming language agnostic<br />
* Be UI toolkit agnostic<br />
* Try to reuse existing technologies as much as possible, but not at the cost of a bad API<br />
<br />
=How to achieve that technically=<br />
* Chose [[Dbus]] as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.<br />
* Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).<br />
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.<br />
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.<br />
<br />
=Mandatory Readings=<br />
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]<br />
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]<br />
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]<br />
<br />
=What this is NOT about=<br />
This initiative does not cover low level services such as<br />
* Bootloader, Kernel, or System Init.<br />
<br />
This initiative does not cover high level services such as<br />
* X-Window-System, Window Manager, UI Toolkits,<br />
* Application Launchers, Applications, or Fancy UIs.<br />
<br />
=Architectural Overview=<br />
[[Image:OpenmokoFramework08.png |823px|frontside]]<br />
<br />
=Software Components=<br />
<br />
We differenciate between low-level and high-level services -- dbus will be used to communicate horizontally and vertically.<br />
<br />
===Low-Level Services===<br />
<br />
====Device Control====<br />
The low level device control service manages peripheral control, i.e. controlling power for individual subsystems such as<br />
* GSM, WiFi, Bluetooth, GPS, as well as<br />
* Backlight brightness and power,<br />
* turning LEDs on and off, etc.<br />
It also deals with<br />
* charging, suspend/resume,<br />
* accellerometers, and buttons.<br />
Last but not least, it sends notifications about the user's activity so that listeners have a chance to<br />
* change to powersaving modes, or<br />
* lock the device.<br />
We implement the following software for that:<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/OpenDeviceDaemon odeviced]<br />
<br />
====Audio====<br />
The low level audio service relies on a working alsa device driver. On top of that, there are two components:<br />
# [http://gstreamer.freedesktop.org/ gstreamer]<br />
# [http://pulseaudio.org pulseaudio]<br />
<br />
'''Gstreamer''' is to be used for all kinds of event sounds where a) multiple audio formats need to be supported and b) a latency of about one second is acceptable. This goes for e.g. ring tones, welcome tones, plug indication.<br />
<br />
'''Pulseaudio''' is to be used for event sounds, where low-latency is necessary, e.g. touch click sounds and UI event acknowledge sounds. Pulseaudio is our general all-purpose mixer. Gstreamer will use the pulseaudio sink to feed audio through.<br />
<br />
====GSM====<br />
The low level GSM services expect a modem complying to GSM 07.07, GSM 07.05, and assorted GSM specifications, talking an AT-protocol over a serial line. If GSM 07.10 is supported, we use the multiplexing daemon<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/gsm0710muxd gsm0710muxd]<br />
to export virtual serial lines over -- again -- AT-protocol can be spoken.<br />
<br />
====Bluetooth====<br />
The low level Bluetooth services rely on the official Linux Bluetooth subsystem:<br />
* [http://www.bluez.org BlueZ].<br />
<br />
====GPS====<br />
The low level GPS services assume a GPS device that talks NMEA over a device node. We rely on the following software:<br />
* [http://gypsy.freedesktop.org Gypsy]<br />
<br />
====Network====<br />
The low level networking service assumes network interfaces, such as USB, Ethernet, Wifi, etc. We rely on the following software here:<br />
* Network Manager or Intel Connection Manager (undecided yet)<br />
* ppp<br />
<br />
===High Level===<br />
<br />
====Usage====<br />
The Usage subsystem is coordinating application I/O requirements preventing. Applications are not supposed to turn on or off devices, since they do not have any knowledge about concurrent applications that may be also using the device -- think ''reference counting'' for I/O requirements.<br />
<br />
With this added layer, we could later think about monitoring subsystems, subsystem usage statistics, or accounting.<br />
<br />
See discussion page about PolicyKit.<br />
<br />
====Events====<br />
* signaling events via I/O (ringing, blinking, vibrating)<br />
* might use fd.o notification API<br />
<br />
====PIM====<br />
An intelligent storage database server. This is being carried out as a Google Summer of Code project. See complete description [http://www.neo1973-germany.de/wiki/pyPimd here]<br />
<br />
====Context====<br />
* Intelligent context API, integrating location as one -- among other -- sources<br />
TBD<br />
Reference Geoclue<br />
<br />
====Telephony====<br />
* Voice<br />
* Data<br />
<br />
=== [http://www.freesmartphone.org/mediawiki/index.php/Implementations/OpenPreferencesDaemon Preferences] ===<br />
* settings database<br />
<br />
====Network====<br />
* high level networking queries<br />
<br />
=Implementation=<br />
<br />
===Completion Status===<br />
<br />
====Low Level====<br />
* device control: 50%<br />
* audio: 80%<br />
* GSM: 80%<br />
* Bluetooth: 80%<br />
* GPS: 80%<br />
* Network: 50%<br />
<br />
====High Level====<br />
* Usage: 0%<br />
* Event: 0%<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/OpenPreferencesDaemon Preferences]: 50%<br />
* Context: 0%<br />
* Telephony: 50%<br />
* Networking: 0%<br />
* PIM: 0%<br />
<br />
=The role of Python=<br />
<br />
Where we write new code, we will use Python to implement the dbus services. The reason for that being the rapid prototyping nature of Python and the emphasis on the Dbus APIs. Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++.<br />
<br />
Once the APIs have been used by application programmers, we can start profiling and possibly reimplement some of the services with daemons written in Vala, ''if'' necessary. We might as well succeed in improving performance by using Pyrex/Cython/Ctypes to keep the benefits of Python.<br />
<br />
=Team & Roadmap=<br />
<br />
==Team==<br />
<br />
* [[User:Mickey|Michael 'Mickey' Lauer]] (team leader) -- Openmoko freelancer, working in Frankfurt/Main, Germany.<br />
* [[User:Charlie| Guillaume 'Charlie' Chereau]] -- Openmoko employee, working fulltime in the Openmoko office, Taipei, Taiwan.<br />
* [[User:Shoragan|Jan 'Shoragan' Luebbe]] -- Openmoko student, working part-time in Brunswick, Germany.<br />
* [[User:DanielWillmann|Daniel 'Alphaone' Willmann]] -- Openmoko student, working part-time in Brunswick, Germany.<br />
* (Holger 'Zecke' Freyther -- hopefully joining the team after releasing ASU, working in Berlin, Germany.)<br />
<br />
'''Subsystem Ownership'''<br />
<br />
''Phase 1 subsystems''<br />
<br />
* odeviced (mickey)<br />
* ophoned (mickey)<br />
* ousaged (jan)<br />
* oeventd (jan)<br />
* opreferencesd (guillaume)<br />
* ocontextd (guillaume)<br />
<br />
''Phase 2 subsystems''<br />
<br />
* network (to be defined)<br />
* pim (to be defined)<br />
<br />
==Roadmap==<br />
<br />
The milestone releases are combined Openmoko Framework and [[Zhone]] releases. Remember: A feature that isn't visible, working, and tested in our framework testing application (Zhone) does ''not'' exist. Until Framework 1.0.0 (later this year), we will not use any versioning in components. Afterwards, individual components may see individual releases.<br />
<br />
Note: If you have implemented a task, please edit this page and add a '[done]' behind. In the very unlikely event that you can't finish a task for a milestone, then add <s>strike it through</s> and add it to the next milestone. Don't leave it sitting untouched -- poor little feature does not deserve this!<br />
<br />
''P h a s e O n e''<br />
----<br />
<br />
===Milestone Release 1 (2008/06/15):===<br />
<br />
'''Features'''<br />
<br />
* Telephony I<br />
** Initiate outgoing call [done]<br />
** Accept incoming call [done]<br />
** Reject incoming call [done]<br />
* Zhone specific<br />
** Show operator name (or EMERGENCY ONLY) and signal strength [done]<br />
** Show battery status [done, with known hardware limitations on 01]<br />
** Dim screen when idle [done]<br />
** Suspend/Resume on Power Button [done, not fully tested]<br />
<br />
'''Tasks'''<br />
<br />
* odeviced (mickey)<br />
** power control for GSM<br />
** LED control [done]<br />
** idle control [done]<br />
* ophoned (mickey)<br />
** sim pin handling [done]<br />
** network registration handling [done]<br />
** call handling [done]<br />
* ousaged (jan)<br />
** allocate / deallocate resources [done]<br />
* oeventd (jan)<br />
** change audio scenario [done]<br />
** ring [done]<br />
* opreferencesd (guillaume)<br />
** research and discuss required API [done]<br />
** evaluate gconf-dbus API<br />
** since gnome people just start to deprecate gconf, check whether there is anything better for us to reuse<br />
* ocontextd (guillaume)<br />
** research and discuss what we need for profile/context API<br />
** evaluate possible libraries for reuse<br />
<br />
===Milestone Release 2 (2008/07/01):===<br />
<br />
'''Features'''<br />
<br />
* Telephony II<br />
** Hold call<br />
** Accept incoming call while another call being held<br />
** Accept incoming call to conference<br />
** Switch between active calls<br />
** Reject incoming call while another call being held<br />
** Drop held call<br />
** Drop all calls<br />
** Drop one call while being in conversation<br />
<br />
* Phonebook<br />
** Entry handling (add, remove, copy)<br />
** Offer storing entry after call ends<br />
** Select entry to call<br />
<br />
* Notification<br />
** Light Power:Orange LED when charging<br />
** Light Power:Blue LED when fully charged<br />
<br />
<br />
'''Tasks'''<br />
<br />
* ophoned (mickey)<br />
** advanced call handling<br />
** SIM phonebook handling<br />
* oeventd (jan)<br />
** communicate with opreferencesd<br />
** notify according to preferences<br />
* opreferencesd (guillaume)<br />
** read/write preferences<br />
** watch for preference changes and signalize<br />
* ocontextd (guillaume)<br />
** gather basic context from location<br />
** signalize context changes<br />
<br />
===Milestone Release 3 (2008/08/01):===<br />
<br />
'''Features'''<br />
<br />
* SMS<br />
** Write and send<br />
** Show incoming SMS<br />
** Show when message is actually sent<br />
<br />
* Message Book<br />
** Handle entries (add, remove, copy)<br />
<br />
'''Tasks'''<br />
<br />
* ophoned:<br />
** sms pdu mode handling<br />
** sms messagebook<br />
<br />
===Milestone Release 4 (2008/08/15):===<br />
<br />
'''Integration Features'''<br />
<br />
* ...<br />
* ...<br />
* ...<br />
<br />
'''Tasks'''<br />
<br />
* ... to be defined ...<br />
<br />
===Milestone Release 5 (2008/09/01):===<br />
<br />
'''Features'''<br />
<br />
* Calender<br />
* Alarm Clock<br />
<br />
'''Tasks'''<br />
<br />
* ... to be defined ...<br />
<br />
===Evaluation and Hackathon in Taipei -- Milestone Release 6 (2008/10/15):===<br />
<br />
'''Participants'''<br />
<br />
* Hopefully all the framework guys.<br />
<br />
'''Evaluation Criteria'''<br />
<br />
* ... to be defined ...<br />
<br />
'''Features'''<br />
<br />
* ... to be defined ...<br />
<br />
'''Tasks'''<br />
<br />
* ... to be defined ...<br />
<br />
----<br />
''P h a s e T w o''<br />
----<br />
<br />
===Milestone Release 5 (2008/09/01):===<br />
<br />
* ...<br />
<br />
===Milestone Release 6 (2008/09/15):===<br />
<br />
* ...<br />
<br />
===Milestone Release 7 (2008/10/01):===<br />
<br />
* ...<br />
<br />
[[Category:Openmoko ]]<br />
[[Category:Categories| ]]</div>Charliehttp://openmoko.org/wiki/OpenmokoFrameworkOpenmokoFramework2008-06-17T06:30:49Z<p>Charlie: /* High Level */</p>
<hr />
<div>{{Languages|OpenmokoFramework}}<br />
{{Introbox}}<br />
''Note: This is the (ongoing) description of the new framework architecture that is '''in development'''. See [[OpenmokoOldFramework]] for the framework architecture of 2007.1 and 2007.2 and [[NeoSoftwareStack]] for the current status (which has nothing to do yet with this framework)''<br />
<br />
=Answering the TOP x questions=<br />
* ''Question 1'': Is this a part of the current images yet?<br />
* ''Answer'': No.<br />
* ''Question 2'': Is this the mystic ASU?<br />
* ''Answer'': No.<br />
* ''Question 3'': When can I see this as part of an image?<br />
* ''Answer'': See roadmap at the bottom of this document. It's going to be an interesting autumn and winter '08 ;)<br />
* ''Question 4'': What's the current status?<br />
* ''Answer'': See right below:<br />
** [[OpenmokoFramework/Status Update 1|Status Update 1]]<br />
<br />
=Purposes=<br />
* '''Give people the infrastructure to create solid and exciting software products based on the Openmoko platform'''<br />
* '''Support competing UIs while collaborating on developing services'''<br />
* '''Encourage framework users (e.g. application developers) to also contribute to the framework'''<br />
<br />
=Requirements=<br />
* Make it simple<br />
* Concentrate on core services<br />
* Be programming language agnostic<br />
* Be UI toolkit agnostic<br />
* Try to reuse existing technologies as much as possible, but not at the cost of a bad API<br />
<br />
=How to achieve that technically=<br />
* Chose [[Dbus]] as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.<br />
* Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).<br />
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.<br />
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.<br />
<br />
=Mandatory Readings=<br />
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]<br />
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]<br />
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]<br />
<br />
=What this is NOT about=<br />
This initiative does not cover low level services such as<br />
* Bootloader, Kernel, or System Init.<br />
<br />
This initiative does not cover high level services such as<br />
* X-Window-System, Window Manager, UI Toolkits,<br />
* Application Launchers, Applications, or Fancy UIs.<br />
<br />
=Architectural Overview=<br />
[[Image:OpenmokoFramework08.png |823px|frontside]]<br />
<br />
=Software Components=<br />
<br />
We differenciate between low-level and high-level services -- dbus will be used to communicate horizontally and vertically.<br />
<br />
===Low-Level Services===<br />
<br />
====Device Control====<br />
The low level device control service manages peripheral control, i.e. controlling power for individual subsystems such as<br />
* GSM, WiFi, Bluetooth, GPS, as well as<br />
* Backlight brightness and power,<br />
* turning LEDs on and off, etc.<br />
It also deals with<br />
* charging, suspend/resume,<br />
* accellerometers, and buttons.<br />
Last but not least, it sends notifications about the user's activity so that listeners have a chance to<br />
* change to powersaving modes, or<br />
* lock the device.<br />
We implement the following software for that:<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/OpenDeviceDaemon odeviced]<br />
<br />
====Audio====<br />
The low level audio service relies on a working alsa device driver. On top of that, there are two components:<br />
# [http://gstreamer.freedesktop.org/ gstreamer]<br />
# [http://pulseaudio.org pulseaudio]<br />
<br />
'''Gstreamer''' is to be used for all kinds of event sounds where a) multiple audio formats need to be supported and b) a latency of about one second is acceptable. This goes for e.g. ring tones, welcome tones, plug indication.<br />
<br />
'''Pulseaudio''' is to be used for event sounds, where low-latency is necessary, e.g. touch click sounds and UI event acknowledge sounds. Pulseaudio is our general all-purpose mixer. Gstreamer will use the pulseaudio sink to feed audio through.<br />
<br />
====GSM====<br />
The low level GSM services expect a modem complying to GSM 07.07, GSM 07.05, and assorted GSM specifications, talking an AT-protocol over a serial line. If GSM 07.10 is supported, we use the multiplexing daemon<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/gsm0710muxd gsm0710muxd]<br />
to export virtual serial lines over -- again -- AT-protocol can be spoken.<br />
<br />
====Bluetooth====<br />
The low level Bluetooth services rely on the official Linux Bluetooth subsystem:<br />
* [http://www.bluez.org BlueZ].<br />
<br />
====GPS====<br />
The low level GPS services assume a GPS device that talks NMEA over a device node. We rely on the following software:<br />
* [http://gypsy.freedesktop.org Gypsy]<br />
<br />
====Network====<br />
The low level networking service assumes network interfaces, such as USB, Ethernet, Wifi, etc. We rely on the following software here:<br />
* Network Manager or Intel Connection Manager (undecided yet)<br />
* ppp<br />
<br />
===High Level===<br />
<br />
====Usage====<br />
The Usage subsystem is coordinating application I/O requirements preventing. Applications are not supposed to turn on or off devices, since they do not have any knowledge about concurrent applications that may be also using the device -- think ''reference counting'' for I/O requirements.<br />
<br />
With this added layer, we could later think about monitoring subsystems, subsystem usage statistics, or accounting.<br />
<br />
See discussion page about PolicyKit.<br />
<br />
====Events====<br />
* signaling events via I/O (ringing, blinking, vibrating)<br />
* might use fd.o notification API<br />
<br />
====PIM====<br />
An intelligent storage database server. This is being carried out as a Google Summer of Code project. See complete description [http://www.neo1973-germany.de/wiki/pyPimd here]<br />
<br />
====Context====<br />
* Intelligent context API, integrating location as one -- among other -- sources<br />
TBD<br />
Reference Geoclue<br />
<br />
====Telephony====<br />
* Voice<br />
* Data<br />
<br />
===Preferences===<br />
* settings database<br />
<br />
====Network====<br />
* high level networking queries<br />
<br />
=Implementation=<br />
<br />
===Completion Status===<br />
<br />
====Low Level====<br />
* device control: 50%<br />
* audio: 80%<br />
* GSM: 80%<br />
* Bluetooth: 80%<br />
* GPS: 80%<br />
* Network: 50%<br />
<br />
====High Level====<br />
* Usage: 0%<br />
* Event: 0%<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/OpenPreferencesDaemon Preferences]: 50%<br />
* Context: 0%<br />
* Telephony: 50%<br />
* Networking: 0%<br />
* PIM: 0%<br />
<br />
=The role of Python=<br />
<br />
Where we write new code, we will use Python to implement the dbus services. The reason for that being the rapid prototyping nature of Python and the emphasis on the Dbus APIs. Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++.<br />
<br />
Once the APIs have been used by application programmers, we can start profiling and possibly reimplement some of the services with daemons written in Vala, ''if'' necessary. We might as well succeed in improving performance by using Pyrex/Cython/Ctypes to keep the benefits of Python.<br />
<br />
=Team & Roadmap=<br />
<br />
==Team==<br />
<br />
* [[User:Mickey|Michael 'Mickey' Lauer]] (team leader) -- Openmoko freelancer, working in Frankfurt/Main, Germany.<br />
* [[User:Charlie| Guillaume 'Charlie' Chereau]] -- Openmoko employee, working fulltime in the Openmoko office, Taipei, Taiwan.<br />
* [[User:Shoragan|Jan 'Shoragan' Luebbe]] -- Openmoko student, working part-time in Brunswick, Germany.<br />
* [[User:DanielWillmann|Daniel 'Alphaone' Willmann]] -- Openmoko student, working part-time in Brunswick, Germany.<br />
* (Holger 'Zecke' Freyther -- hopefully joining the team after releasing ASU, working in Berlin, Germany.)<br />
<br />
'''Subsystem Ownership'''<br />
<br />
''Phase 1 subsystems''<br />
<br />
* odeviced (mickey)<br />
* ophoned (mickey)<br />
* ousaged (jan)<br />
* oeventd (jan)<br />
* opreferencesd (guillaume)<br />
* ocontextd (guillaume)<br />
<br />
''Phase 2 subsystems''<br />
<br />
* network (to be defined)<br />
* pim (to be defined)<br />
<br />
==Roadmap==<br />
<br />
The milestone releases are combined Openmoko Framework and [[Zhone]] releases. Remember: A feature that isn't visible, working, and tested in our framework testing application (Zhone) does ''not'' exist. Until Framework 1.0.0 (later this year), we will not use any versioning in components. Afterwards, individual components may see individual releases.<br />
<br />
Note: If you have implemented a task, please edit this page and add a '[done]' behind. In the very unlikely event that you can't finish a task for a milestone, then add <s>strike it through</s> and add it to the next milestone. Don't leave it sitting untouched -- poor little feature does not deserve this!<br />
<br />
''P h a s e O n e''<br />
----<br />
<br />
===Milestone Release 1 (2008/06/15):===<br />
<br />
'''Features'''<br />
<br />
* Telephony I<br />
** Initiate outgoing call [done]<br />
** Accept incoming call [done]<br />
** Reject incoming call [done]<br />
* Zhone specific<br />
** Show operator name (or EMERGENCY ONLY) and signal strength [done]<br />
** Show battery status [done, with known hardware limitations on 01]<br />
** Dim screen when idle [done]<br />
** Suspend/Resume on Power Button [done, not fully tested]<br />
<br />
'''Tasks'''<br />
<br />
* odeviced (mickey)<br />
** power control for GSM<br />
** LED control [done]<br />
** idle control [done]<br />
* ophoned (mickey)<br />
** sim pin handling [done]<br />
** network registration handling [done]<br />
** call handling [done]<br />
* ousaged (jan)<br />
** allocate / deallocate resources [done]<br />
* oeventd (jan)<br />
** change audio scenario [done]<br />
** ring [done]<br />
* opreferencesd (guillaume)<br />
** research and discuss required API [done]<br />
** evaluate gconf-dbus API<br />
** since gnome people just start to deprecate gconf, check whether there is anything better for us to reuse<br />
* ocontextd (guillaume)<br />
** research and discuss what we need for profile/context API<br />
** evaluate possible libraries for reuse<br />
<br />
===Milestone Release 2 (2008/07/01):===<br />
<br />
'''Features'''<br />
<br />
* Telephony II<br />
** Hold call<br />
** Accept incoming call while another call being held<br />
** Accept incoming call to conference<br />
** Switch between active calls<br />
** Reject incoming call while another call being held<br />
** Drop held call<br />
** Drop all calls<br />
** Drop one call while being in conversation<br />
<br />
* Phonebook<br />
** Entry handling (add, remove, copy)<br />
** Offer storing entry after call ends<br />
** Select entry to call<br />
<br />
* Notification<br />
** Light Power:Orange LED when charging<br />
** Light Power:Blue LED when fully charged<br />
<br />
<br />
'''Tasks'''<br />
<br />
* ophoned (mickey)<br />
** advanced call handling<br />
** SIM phonebook handling<br />
* oeventd (jan)<br />
** communicate with opreferencesd<br />
** notify according to preferences<br />
* opreferencesd (guillaume)<br />
** read/write preferences<br />
** watch for preference changes and signalize<br />
* ocontextd (guillaume)<br />
** gather basic context from location<br />
** signalize context changes<br />
<br />
===Milestone Release 3 (2008/08/01):===<br />
<br />
'''Features'''<br />
<br />
* SMS<br />
** Write and send<br />
** Show incoming SMS<br />
** Show when message is actually sent<br />
<br />
* Message Book<br />
** Handle entries (add, remove, copy)<br />
<br />
'''Tasks'''<br />
<br />
* ophoned:<br />
** sms pdu mode handling<br />
** sms messagebook<br />
<br />
===Milestone Release 4 (2008/08/15):===<br />
<br />
'''Integration Features'''<br />
<br />
* ...<br />
* ...<br />
* ...<br />
<br />
'''Tasks'''<br />
<br />
* ... to be defined ...<br />
<br />
===Milestone Release 5 (2008/09/01):===<br />
<br />
'''Features'''<br />
<br />
* Calender<br />
* Alarm Clock<br />
<br />
'''Tasks'''<br />
<br />
* ... to be defined ...<br />
<br />
===Evaluation and Hackathon in Taipei -- Milestone Release 6 (2008/10/15):===<br />
<br />
'''Participants'''<br />
<br />
* Hopefully all the framework guys.<br />
<br />
'''Evaluation Criteria'''<br />
<br />
* ... to be defined ...<br />
<br />
'''Features'''<br />
<br />
* ... to be defined ...<br />
<br />
'''Tasks'''<br />
<br />
* ... to be defined ...<br />
<br />
----<br />
''P h a s e T w o''<br />
----<br />
<br />
===Milestone Release 5 (2008/09/01):===<br />
<br />
* ...<br />
<br />
===Milestone Release 6 (2008/09/15):===<br />
<br />
* ...<br />
<br />
===Milestone Release 7 (2008/10/01):===<br />
<br />
* ...<br />
<br />
[[Category:Openmoko ]]<br />
[[Category:Categories| ]]</div>Charliehttp://openmoko.org/wiki/User:CharlieUser:Charlie2008-05-16T04:10:00Z<p>Charlie: </p>
<hr />
<div>Hello My name is Guillaume Chereau, But you can call me Charlie.<br />
<br />
* My email : charlie@openmoko.org<br />
* google talk : charlie137@gmail.com<br />
<br />
* My personal blog : http://charlie137.blogspot.com<br />
* More tech oriented : http://charlie137-2.blogspot.com<br />
<br />
<br />
More to come...</div>Charliehttp://openmoko.org/wiki/User:CharlieUser:Charlie2008-05-16T04:09:46Z<p>Charlie: New page: Hello My name is Guillaume Chereau, But you can call me Charlie. * My email : charlie@openmoko.org * google talk : charlie137@gmail.com * My personal blog : charlie137.blogspot.com * Mor...</p>
<hr />
<div>Hello My name is Guillaume Chereau, But you can call me Charlie.<br />
<br />
* My email : charlie@openmoko.org<br />
* google talk : charlie137@gmail.com<br />
<br />
* My personal blog : charlie137.blogspot.com<br />
* More tech oriented : charlie137-2.blogspot.com<br />
<br />
<br />
More to come...</div>Charliehttp://openmoko.org/wiki/OpenmokoFrameworkOpenmokoFramework2008-05-16T04:07:48Z<p>Charlie: /* Team */</p>
<hr />
<div>''Note: This is the (ongoing) description of the new framework architecture that is '''in development'''. See [[OpenmokoOldFramework]] for the framework architecture of 2007.1 and 2007.2 and [[NeoSoftwareStack]] for the current status (which has nothing to do yet with this framework)''<br />
<br />
=Answering the #1 and #2 questions=<br />
* ''Question'': Is this a part of the current images yet?<br />
* ''Answer'': No.<br />
* ''Question'': When can I see this as part of an image?<br />
* ''Answer'': We expect a zhone-image (including all framework goodies) to turn up as alpha versions around June'08, beta in August'08, with a public stable release in September'08.<br />
<br />
=Purposes=<br />
* '''Give people the infrastructure to create solid and exciting software products based on the Openmoko platform'''<br />
* '''Support competing UIs while collaborating on developing services'''<br />
* '''Encourage framework users (e.g. application developers) to also contribute to the framework'''<br />
<br />
=Requirements=<br />
* Make it simple<br />
* Concentrate on core services<br />
* Be programming language agnostic<br />
* Be UI toolkit agnostic<br />
* Try to reuse existing technologies as much as possible, but not at the cost of a bad API<br />
<br />
=How to achieve that technically=<br />
* Chose [[Dbus]] as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate.<br />
* Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons).<br />
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.<br />
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.<br />
<br />
=Mandatory Readings=<br />
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]<br />
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]<br />
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]<br />
<br />
=What this is NOT about=<br />
This initiative does not cover low level services such as<br />
* Bootloader, Kernel, or System Init.<br />
<br />
This initiative does not cover high level services such as<br />
* X-Window-System, Window Manager, UI Toolkits,<br />
* Application Launchers, Applications, or Fancy UIs.<br />
<br />
=Architectural Overview=<br />
[[Image:OpenmokoFramework08.png |823px|left|frontside]]<br />
<br />
=Software Components=<br />
<br />
We differenciate between low-level and high-level services -- dbus will be used to communicate horizontally and vertically.<br />
<br />
===Low-Level Services===<br />
<br />
====Device Control====<br />
The low level device control service manages peripheral control, i.e. controlling power for individual subsystems such as<br />
* GSM, WiFi, Bluetooth, GPS, as well as<br />
* Backlight brightness and power,<br />
* turning LEDs on and off, etc.<br />
It also deals with<br />
* charging, suspend/resume,<br />
* accellerometers, and buttons.<br />
Last but not least, it sends notifications about the user's activity so that listeners have a chance to<br />
* change to powersaving modes, or<br />
* lock the device.<br />
We implement the following software for that:<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/OpenDeviceDaemon odeviced]<br />
<br />
====Audio====<br />
The low level audio service relies on a working alsa device driver. On top of that, there are two components:<br />
# [http://gstreamer.freedesktop.org/ gstreamer]<br />
# [http://pulseaudio.org pulseaudio]<br />
<br />
'''Gstreamer''' is to be used for all kinds of event sounds where a) multiple audio formats need to be supported and b) a latency of about one second is acceptable. This goes for e.g. ring tones, welcome tones, plug indication.<br />
<br />
'''Pulseaudio''' is to be used for event sounds, where low-latency is necessary, e.g. touch click sounds and UI event acknowledge sounds. Pulseaudio is our general all-purpose mixer. Gstreamer will use the pulseaudio sink to feed audio through.<br />
<br />
====GSM====<br />
The low level GSM services expect a modem complying to GSM 07.07, GSM 07.05, and assorted GSM specifications, talking an AT-protocol over a serial line. If GSM 07.10 is supported, we use the multiplexing daemon<br />
* [http://www.freesmartphone.org/mediawiki/index.php/Implementations/gsm0710muxd gsm0710muxd]<br />
to export virtual serial lines over -- again -- AT-protocol can be spoken.<br />
<br />
====Bluetooth====<br />
The low level Bluetooth services rely on the official Linux Bluetooth subsystem:<br />
* [http://www.bluez.org BlueZ].<br />
<br />
====GPS====<br />
The low level GPS services assume a GPS device that talks NMEA over a device node. We rely on the following software:<br />
* [http://gypsy.freedesktop.org Gypsy]<br />
<br />
====Network====<br />
The low level networking service assumes network interfaces, such as USB, Ethernet, Wifi, etc. We rely on the following software here:<br />
* Network Manager or Intel Connection Manager (undecided yet)<br />
* ppp<br />
<br />
===High Level===<br />
<br />
====Usage====<br />
The Usage subsystem is coordinating application I/O requirements preventing. Applications are not supposed to turn on or off devices, since they do not have any knowledge about concurrent applications that may be also using the device -- think ''reference counting'' for I/O requirements.<br />
<br />
With this added layer, we could later think about monitoring subsystems, subsystem usage statistics, or accounting.<br />
<br />
See discussion page about PolicyKit.<br />
<br />
====Events====<br />
* signaling events via I/O (ringing, blinking, vibrating)<br />
* might use fd.o notification API<br />
<br />
====PIM====<br />
An intelligent storage database server. This is being carried out as a Google Summer of Code project. See complete description [http://www.neo1973-germany.de/wiki/pyPimd here]<br />
<br />
====Context====<br />
* Intelligent context API, integrating location as one -- among other -- sources<br />
TBD<br />
Reference Geoclue<br />
<br />
====Telephony====<br />
* Voice<br />
* Data<br />
<br />
===Preferences===<br />
* settings database<br />
<br />
====Network====<br />
* high level networking queries<br />
<br />
=Implementation=<br />
<br />
===Completion Status===<br />
<br />
====Low Level====<br />
* device control: 50%<br />
* audio: 80%<br />
* GSM: 80%<br />
* Bluetooth: 80%<br />
* GPS: 80%<br />
* Network: 50%<br />
<br />
====High Level====<br />
* Usage: 0%<br />
* Event: 0%<br />
* Preferences: 0%<br />
* Context: 0%<br />
* Telephony: 50%<br />
* Networking: 0%<br />
* PIM: 0%<br />
<br />
=The role of Python=<br />
<br />
Where we write new code, we will use Python to implement the dbus services. The reason for that being the rapid prototyping nature of Python and the emphasis on the Dbus APIs. Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++.<br />
<br />
Once the APIs have been used by application programmers, we can start profiling and possibly reimplement some of the services with daemons written in Vala, ''if'' necessary. We might as well succeed in improving performance by using Pyrex/Cython/Ctypes to keep the benefits of Python.<br />
<br />
=Team & Roadmap=<br />
<br />
==Team==<br />
<br />
* [[User:Mickey|Michael 'Mickey' Lauer]]<br />
* [[User:Charlie| Guillaume 'Charlie' Chereau]]<br />
* [[User:Shoragan|Jan 'Shoragan' Luebbe]]<br />
* Holger 'Zecke' Freyther<br />
<br />
==Roadmap==<br />
<br />
Milestone 1:<br />
<br />
Milestone 2:<br />
<br />
Milestone 3:<br />
<br />
<br />
[[Category:Openmoko ]]<br />
[[Category:Categories| ]]</div>Charlie