View source for GUI Style Guidelines/de
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to GUI Style Guidelines/de.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to GUI Style Guidelines/de.
Openmoko ist eine Platform für Geräte mit kleinen Bildschirmen. Somit werden viele gebräuchliche Desktop-Elemente wie Fenster und Menüs schlecht nutzbar. Für Unterschiede in der Display-Produktion (z.B. Aspect Ratio) versucht Openmoko ein Framework bereit zu stellen, so dass Applikationsentwickler sich nicht mit schlussendlichen Layout auseinander setzen müssen.
Openmoko-Applikationen werden als mehrere Seiten dargestellt, welche unterschiedliche Beziehungen untereinander haben. Jede Seite ist ein Task, wie das Auswählen eines Kontakts oder das durchsuchen des Kalenders.
Seiten welche von Änderungen anderer Seiten nicht betroffen sind werden Primary Pages genannt. Sie arbeiten Unabhängig von anderen Seiten. Seiten welche von Änderungen einer Primary Page betroffen sind werden als Secondary Pages bezeichnet. Z.B. in Contacts (Adressbuch), in der Primary Page ist die Liste aller Kontakte, in der Secondary Page werden Information zum in der Primary Page ausgewählten Kontakt angezeigt.
Jede Seite hat ein Label, Icon und Inhalt was mit der Seite assoziiert wird. So können Seiten identifiziert und wenn nötig angezeigt werden.
Die Beziehungen zwischen Seiten werden in einem Modell Beschrieben wenn die Applikation gestartet ist. Die Applikation instantiiert dann ein weiteres Objekt welches die Ansicht und Steuerung des Modells übernimmt. Das Objekt initiiert das Layout der Applikation.
On this form factor, the layout is portrait and constrained by a very small screen size. To accommodate this, all pages are full screen and the target area for buttons must be as large as possible. Borders and spacing between widgets is kept to a minimum to ensure best use of available screen estate.
Das Wechseln zwischen Seiten erfolgt über Tabs welche sich unten horizontal anordnen. Der einzelne Tab zeigt ein Icon welches an den Inhalt der Seite erinnert.
Toolbars werden am oberen Bildschirmrand angezeigt, mit möglichst grossen Tool-Button. Es sollten nicht mehr als vier Buttons in einer Toolbar sein.
Die Filter-Such-Bar ist eine optionale Komponente, erstellt aus drei Widgets. Ein 'Toggle'-Button wechselt zwischen Filter (Combo Box) und Suche (Entry Box). Wird in die Suchbox geschrieben werden die Ergebnisse fortlaufend aktualisiert.
Bei Geräten welche eine Bildschirm-Tastatur benötigen wird diese automatisch angezeigt wenn ein Widget den Fokus auf einem Eingabefeld hat.
The touch screen should be used for single click (tap) and drag options only. A tap and hold will activate button three on the mouse ("right" click). The "double click" action is strongly
All applications that manipulate data should aim to follow the "instant apply" model so that there is no need for the user to explicitly save any data entered.
Applications should save their state if possible between sessions. This might include current view details or "unsaved" data. [edit] Using GTK+ and libmokoui
GTK+ is a C library that uses GObject for pseudo object orientation. This allows it to be very portable and flexible.
Openmoko code mostly uses the c99 standard for C.
Spacing,widgets sizes and fonts must not be hard coded into Openmoko applications. Openmoko is a framework for small screen devices, which may include anything as small as QVGA (320x240) to 800x600. Therefore, for applications to work on these different resolutions, programs must not hard code anything to do with the specific appearance of widgets.
Most on screen elements such as buttons and entry boxes are sub classed from the GtkWidget base class. The normal practice is to cast up from this class. For this reason, all the creator functions return GtkWidget rather than the class of which they are creating.