UMAF Meeting

Am Sonntag dem 12.10.2008 fand um 18:00 MEZ wieder mal ein UMAF Meeting stand. Auf der Agenda standen dabei folgende Dinge:

1. Grundlegende Richtlinien für das Framework
2. Was gehört alles zu einem Interface-Design? Welche Elemente haben wir? Was müssen wir alles beachten?
3. Wollen wir verschiedene Vorschläge parallel ausarbeiten oder einen iterativ entwickeln?
4. Elementary und FSO als Grundlage?
5. Bindings für Elementary
6. Zusammenarbeit mit OpenUsability
7. Lizenz
8. Die nächsten Schritte

Grundlegende Richtlinien für das Framework
1. Einheitliches Look&Feel
2. Inuitive GUI
3. möglichst Entwicklerfreundliche API
4. Anwendungen sollten mit den Fingern bedienbar sein, allerdings sollte man auch Anwendungen für den Stylus schreiben können
5. Nur die wirklich notwendige Elemente sollen angezeigt werden
6. Performantes System

Interface-Design
Bei der Diskussion über das Interface-Design sind einige Dinge herausgekommen. Das ganze Framework soll Unicode fähig sein. Am oberen Rand des Bildschirmes soll immer das Illume Panel zu sehen sein. Eine Toolbar am unteren Rand dient zum Aufrufen von Programmfunktionalitäten. Jede Anwendung sollte immer den ganzen Bildschirm benutzen (keine Popups etc.).

Parallel oder Iterativ?
Bei der Frage wie die Ideen ausgearbeitet werden sollen ist eine Mischung aus beiden benutzt werden. Mehrere Konzepte und Mockups sollen gesammelt werden, aber möglichst schnell zusammengeführt werden, damit sich das ganze im Endeffekt auf eine große Idee konzentriert.

Elementary und FSO als Grundlage?
Das Framework soll auf FSO (frameworkd) basieren. Die Widgets sollen auf Elementary basieren. Zu diesem Zweck sollen Python Bindings für Elementary geschrieben werden.

OpenUsability?
Mit OpenUsability soll zusammengearbeitet werden soweit dies möglich ist.

Lizenz
Das Untitled Mobile Application Framework soll unter der GPL (GPLv2 or later) stehen. frameworkd benutzt die gleiche Lizenz. Elementary steht unter der BSD Lizenz.

Die nächsten Schritte
Im nächsten Schritt sollen die Elementary Python Bindings erstellt werden und Demo Applikationen entwickelt werden. Der Fortschritt und das weitere Vorgehen soll dann beim nächsten UMAF Meeting (Sonntag, 19.10.2008 -> 18:00 MEZ) diskutiert werden.

Weitere Informationen gibt es unter:
http://www.freesmartphone.org/index.php/Untitled_Mobile_Application_Framework

UMAF Diskusion auf #neo1973-germany

Gestern trafen sich um 12 Uhr (High Noon) mit Revolvern bewaffnete Open Source Anhänger um über das Untitled Mobile Application Framework (UMAF) zu diskutieren. Da glücklicherweise nicht geschossen, sondern diskutiert wurde sind auch einige Ergebnisse bzw. Ideen dabei herausgekommen :)

Illume
– Hauptbildschirm (ähnlich Qtopia)
– Iconmenü
– Umschalten zwischen verschiedenen Anwendungen
– Belegung der Tasten AUX und Power mit sinnvoller Funktionalität

UMAF
– auf Basis von EFL
– Widgets (EDJE / EVAS / Elementary?)
– Bindings für gängige Programmiersprachen (Python, C, etc.)

Weitere Ideen beziehen sich auf das Aussehen der Anwendungen im Allgemeinen. Ein schönes Mockup dazu ist unter http://media.cream-project.org/mockup.png zu finden.

Weitere Informationen gibt es unter:
http://www.freesmartphone.org/index.php/Untitled_Mobile_Application_Framework.

ETK in Python

Grade eben bin ich durch Zufall auf die Seite http://wiki.openmoko.org/wiki/Python gegangen und habe dabei doch gleich ein ETK Minimal Beispiel gefunden welches ich hier wiedergeben möchte.

Damit dieses Beispiel läufts sollte man neben den „normalen“ Python Paketen auch noch die Pakete python-etk und python-efl installieren.

Die Minimalanwendung sieht dann so aus:

import etk

#create a button (not yet on any window)
b = etk.Button(label=“Hello“)

#create a (nonvisible) window and put the button on the window
w = etk.Window(title=“Hello“, child=b)

#create a silly callback function
def hello(target):
print ‚Hello World‘
etk.main_quit()

#make the button call the callback when pressed
b.on_clicked(hello)

#make the window display
w.show_all()

#start processing screen events
etk.main()

Im ersten Schritt wird das Python Modul python-etk eingebunden. Danach wird ein Button definiert und mit der Beschriftung „Hello“ versehen. In der nächsten Zeile wird dann ein Fenster erzeugt (welches unsichtbar ist) und diesem Fenster wird der Button zugewiesen. Danach wird die Callbackfunktion hello definiert und diese dem Button zugewiesen. In den letzten zwei Zeilen wird das ganze sichtbar gemacht und der Event Loop aktiviert. Und schon haben wir eine Anwendung :)

PyGame

Gestern bin ich auf PyGame gestoßen. PyGame ist eine Sammlung von Python-Modulen welche Dinge wie das Ansteuern der Grafik und des Sounds abstrahiert. Dabei greifen die Module auf die SDL Bibliothek zurück. Entwickelt wurde das ganze von Pete Shinners. Da das ganze unter Python läuft ist es sicherlich auch interessant für die OpenMoko Plattform. Die offizielle Seite ist unter http://www.pygame.org/.

Wie geht es weiter?

Gestern saß ich am Rechner und vor mir lag mein Neo. Ich habe es dann mal angeschaut und war mal wieder total begeistert welche ungeahnten Möglichkeiten in diesem Gerät stecken. Das führte dazu das ich erst einmal für Minuten nichts anderes getan habe, als begeistert zu sein :) Ich wollte eigentlich schon vor längerer Zeit meine erste Openmoko-Anwendung schreiben. Leider ist das nicht so einfach wie zuerst gedacht.

Da ich diese Anwendung auf Enlightment Basis realisieren wollte und plötzlich merkte das es neben Evas und Edje auch ein UI Toolkit benötigt. Da gibt es ja wie ich beim letzten Mal schon schrieb die Toolkits EWL und Etk. Ich habe mich dann für EWL entschieden und musste dann mal wieder feststellen das es dafür kein Pythonbinding gibt.

Als Entwickler ist man nun doch etwas enttäuscht. Was wir brauchen ist ein leichter Einstieg in für Entwickler, denn nicht jeder Entwickler hat Lust erst Tage und Wochen damit zu verbringen überhaupt mal eine Anwendung hervorzuzaubern. Ich hätte gerne einen „Standard“ welche Widgets benutzt werden sollen etc.

Im Endeffekt musste ein integriertes System entstehen. Was das bedeutet kann man sich an Systemen wie Windows, GNOME, und KDE sehen. Jede Anwendung benutzt die gleichen Widgets und für Benutzer sieht das ganze immer irgendwie bekannt aus. Nachdem FSO die Middleware liefert sollten wir uns um die Benutzeroberfläche kümmern.

Da viele Leute (zu mindestens die mit denen ich zu tun hatte) eine Umgebung auf Enlightment (und Illumne) Basis bevorzugen (ich auch), sollten wir anfangen genau dort anzufangen. Konkret bedeutet das folgendes: Zur Zeit ist Zhone (das Testimage für FSO), eine nicht grade modular aufgebaute Anwendung. Was uns fehlt ist ein Äquivalent zu den GNOME Libs (und anderen ähnlichen Dingen).

Wir sollten nun Anfangen uns an das Reißbrett zu setzen und ein System zu designen welches modular ist und vor allem auch in der Zukunft ausbaufähig ist. Damit wir die Bibliotheken z.B. die für die Widgets nicht an den Bedürfnissen vorbei entwickeln sollten wir unserer Brot und Butter Anwendungen entwickeln und parallel dazu die passenden Bibliotheken. Ich denke am Anfang sollten es folgende Anwendungen sein:

– einen Dailer
– ein SMS Programm
– ein Adressbuch
– einen Kalender
– einen Mediaplayer
– ein Notiz Programm
– ein Memo Programm
– eine Uhr bzw. Weltzeit Uhr (mit Wecker)

Bei der Entwicklung dieser Programme sollte dann parallel dazu die passenden Bibliotheken entwickelt werden, damit der Entwickler auf einem Framework aufsetzen kann bei dem er nicht befürchten muss das nächste Woche schon wieder alles anders macht und der Benutzer eine einheitliche Oberfläche mit einheitlichen Anwendungen bekommt.

Jetzt stellt sich eigentlich nur noch Frage. Wer macht mit?