www.mikrocontroller.net

Forum: Compiler & IDEs embedded Windowmanager Konzepte


Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Habe wieder eine Frage :)

Ich möchte gerne einen Windowmanger für embedded System aufsetzen, bzw 
besser gesagt einen "Render"-Manager. Bin mir aber nicht ganz sicher ob 
das Konzept so überaupt umsetzbar ist, oder es gnadenlos an Performance 
und Speicherverbrauch scheitert.

Als verfügbare Hardware schmeiss ich einfach mal STM32+8MB 
Ram+Zusatzflash in den Raum.

Das ganz soll sich in 2 "kleinere" Projekte aufteilen.
1. Der Rendermanager. Das eigentlich wichtig. Das braucht man um optisch 
schöne Programme zaubern zu können.
2. Der Eventmanager. Ist auf den meisten Embedded-System eher nutzlos, 
bzw zu verschieden um ihn fix zu implementieren. Deshalb sollte der 
erstmal in den Hintergrund geschoben werden, aber beim entgültigen 
Konzept auch noch seine Andockstellen bekommen.

Zum Rendermanager folgende Überlegungen:
Ideal für optisch anspruchsvolle Programme ist ein WYSIWYG-Editor. Die 
komplette Renderengine soll ähnlich einem Webbrowser funktionieren. Man 
übergibt den Programm drei Datein: 1. Screens 2. Objects 3. Sprites.

1. Screens entspricht dem HTML Code. Hier wird die Annordnung des 
Fenster definiert. Im Programm in eine Struktur geladen und kann dort 
verändert werden. Wird bei einer Änderung am Screen neu gelesen und 
verarbeitet(Idealerweiße nur "changed" Dinge).
2. Objects ist der variable Teil. Und die Stärke dieses Systems. Man 
kann den Renderer um beliebige Objekte erweitern. Ein Objekt enthält 
zwangsweiße die Größe, die zugrundeliegenden Sprite(s) und eine je nach 
Objekttype definierte Anzahl von Eigenschaften. Jedes Objekt wird 
mittels im einer eigenen Funktion gezeichnet und im System angelegt.
3. Sprites ist im Prinzip nur einer aneinander Reihung binärer Bilder 
(ev komprimiert)

Der Ablauf im Programm ist wäre dann ca. so

- Lese Objectsdatein. Lege entsprechende Objekte an und initialisiere 
die Pointer zu den Sprites.
- Erstelle Tabelle mit zugehörigen IDs und entsprechenden Pointern um 
schnell das entsprechende Objekt zu finden.
- Zeichne Objekt in Abhängigkeit der Priorität in den Framebuffer und 
lege entsprechende Abhängigkeiten im Projekt an. zB Buttons einem 
Eventmanager bekannt geben. Oder einen Speicherbereich im Framebuffer 
für Userdrawings bekanntgeben.
- Je nach System mit direkter oder indirekter Addressierung Bild 
anzeigen

Nachteile die ich sehe sind enormer Speicherverbrauch was Flash 
betrifft. Kann man aber relativ günstig entgegenwirken. Sowie einen 
ziemlich hohen  Ramverbrauch. Animationen sind auch "eher" schwierig 
einzubauen.
Der große Vorteil ist aber, das man optisch sehr einfach etwas extrem 
Aufwändiges zaubern kann...mit herkömmlichen GUI Toolkits schauts meist 
eher Trüb aus... :(  Oder man verwendet Zeichenroutinen und macht sich 
extremst Arbeit, welche dann aber meist nur auf S/W Displays gut 
ausschaut.


Das Konzept liegt hier vor mir auf einem Blatt Papier aufgezeichnet und 
schaut insich recht schlüssig aus. Das System bzw die einzelnen Tabellen 
sind auf dem Papier auch schon um Zustände wie "IsChanged" oder "Locked" 
erweitert. Auch gibt es die Möglichkeit eine Taskbar zu verwenden.

Zum austesten habe ich mir noch ein Linux eingerichtet und spiele dort 
mit dem Framebuffer rum, bin hier auch schon gespannt wie weit ich da 
komme.

Meinung, Anregungen, Tipps oder Hilfe?
Gibts sowas schon? Wenn Ja Open-Source? Zahlt sich die Arbeit überhaupt 
aus?

LG
Michael

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
also du willst ein vollständiges GUI für Controller bauen? Oder wie?
Das würde mich jetzt aber interessieren, wie sowas aussehen könnte.
Hast du schon irgend einen Code oder gar ein laufendes Programm?

Autor: Michael B. (bubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich hab mal kurz ein Bild vom Iphone angehängt.
Die Idee dahinter ist folgende:

Es gibt wie im Bild eingezeichnet Objekte. Jedes Objekt hat eine 
Definition. zB.
struct TEXT
{
UID
X.Size
Y.Size
String
Color
}

struct Button
{
UID
X.Size
Y.Size
*Sprite1
*Sprite2
String
Event
}

struct Panel
{
UID
X.Size
Y.Size
Background
*ObjectfromPanel
*ObjectfromPanel
...
}

Diese Definition stehen in einer Datei. zB als XML um es lesbar und 
schnell modifizierbar zu machen.
Es gibt noch 2 weitere Datein.
1. Sprites: Die Datei enthält die Grafiken. Das heißt du kannst Buttons 
zeichnen und am ende konvertieren. Das UI wird unabhängig vom Programm 
gestaltet. Solange die Objekte ausgehandelt sind -> Theming ist einfach 
durch austausch der Sprite-Datei möglich
2. Screens: Die Datei enthält die Info wo welches Objekt anzuzeigen ist.
Man kann sich 2-3-4 Screens vordefinieren. Und dann einfach ohne 
nacharbeit im µC anzeigen oder man defniert sich nichts und füllt die 
Screen-Structur von Hand im µC und verändert sie dort auch laufend.

Im Prinzip erledigt der "Renderer" nur folgende Aufgabe:
Schau wo welches Objekt liegt, kopier Sprite in Speicher, erledige 
Aufgaben die Objektspezifisch sind (zB registriere Button-Event) und 
kopiere Ram in Display (oder direkt).

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du denn schon was konkretes programmiert, was läuft, oder hast du 
einfach mal diese Überlegungen angestellt?
Wo kommt das XML-File denn hin? Und ist das nicht sehr langsam, wenn der 
Renderer erst das XML lesen und interpretieren muss?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für ein Embedded-System ist doch der XML Overhead viel zu gross.
XML hat zwar seine Berechtigung aber muss es denn wirklich überall 
eingesetzt werden? Zum schluss erzeugt ein Gui-Desinger eine XML-Datei, 
die danach das nächste Programm wieder einliest. Ein Mensch muss diese 
datei nie Lesen( ausser bei der Fehlersuche).

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Moment noch Überlegungen. Bin aber bereits am Programm drann und 
versuche es zuerst im Linux-Framebuffer. Das XML-File wird ja zur 
Initalisierung geparst. Und die Objecte im Ram angelegt -> hoher 
Ram-Verbrauch. XML war auch nur als Beispiel zu sehen um lesbaren "Code" 
zu erzeugen... Im Endeffekt wirds wohl irgendwo Binär auf der SD-Karte 
liegen.

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls du was mit open source im sinn hast ich bin dabei. Hätte schon 
einiges dazu im Bereich Grafik, Sprites usw. auch mit Farbe.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich möchte auch bald sowas entwerfen. Halt ein richtiges GUI, eine 
Windoof-ähnliche Oberfläche mit Buttons und Fenstern und all dem Kram. 
Wenn das mit einem Touch auch noch funktioniert, umso besser. Da könnte 
man hübsche Sachen mit anstellen...
Allerdings würde ich auch nicht wirklich XML verwenden. Stattdessen 
würde ich irgendwie direkt im C-Code definieren, wie die Fenster und so 
weiter auszusehen haben, ähnlich wie das in Visual Studio gemacht wird. 
Wäre natürlich ganz cool sowas.

BTW, wenn wir schon beim Thema Grafik sind: es gibt ja für Grafik-LCDs 
diese Fonts. Meistens 5 x 7 oder 8 x 12 oder 8 x 16. Schön und Gut, aber 
die Fonts sind doch recht hässlich - gibt es irgend eine Möglichkeit, so 
eine Schrift wie Arial oder so zu implementieren? Das Problem dabei ist 
ja dann, dass die Zeichen unterschiedlich breit sind, was beim 
Bitmap-Font ja nicht der Fall ist.

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja klar geht das. Ape hat dazu mal einen Fontgenerator geschrieben.

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://code.google.com/p/ehalos/source/browse/#svn...

Hier siehst du zum Beispiel eine Arial, und ein paar Sprites.

Autor: clonePhone82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PICT2759.JPG die anderen sind leider nich sehr scharf.

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ganze soll mal Open-Source werden (wenn es sich auch auszahlt). Es 
gibt leider soviele tote Projekte hier und in den weiten des Inets... :(
Aber gute Designutilities für embedded Systeme lauffähig auf theoretisch 
jeder Hardware ob mit OS oder nicht gibts eig nicht :)
Ich werde jetzt erstmal anfangen...Scheinbar ist die Denkweise nicht 
grundlegend falsch. Fragen tauchen dann sowieso während dem 
programmieren auf ;) Wenn sich wer berufen fühlt einen GUI-Designer zu 
basteln der unter Linux und Windows läuft bitte melden :) Die ersten 
Zeilen für den Renderer selbst will ich aber noch selbst schreiben, 
wenns läuft kann man ja ein Projekt draus machen :) Ausserdem zuviele 
Köche verdereben den Brei und so...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, du fängst auf einer viel zu hohen Ebene an.

Du Probleme bestehen ja nicht darin, eine Bitmap irgendwo hin zu 
klatschen.
Die Probleme kommen, wenn sich Rechtecke überlappen, neu gezeichnet 
werden müssen, festgestellt werden muss, wohin ein 'Mausklick' 
eigentlich weitergeleitet werden muss, etc.

Unterste Ebene könnte sein:

Es gibt Rechtecke (die sind erst mal unabhängig davon was in ihnen 
dargestellt werden soll). Denk dir einen Namen für diese Rechtecke aus. 
Window oder Widget ist kein unüblicher Name dafür.

Dann können solche Rechtecke ineinander geschachtelt werden. Wobei die 
Konvention gilt: Ein Rechteck kann sein umschliessendes Rechteck niemals 
verlassen. Wird ein umschliessendes Rechteck einer Operation unterzogen, 
so gilt diese Operation auch auf alle darunter liegenden Rechtecke 
(wobei die Operation bei der Durchwanderung des Baumes nach unten 
modifiziert werden kann)

Das ganze spannt also einen Baum auf. Ein Windows-Hi-Level-Fenster ist 
also nichts anderes als eine Sammlung von Rechtecken. Da gibt es ein 
Rechteck für die Titelzeile, eines für die Toolbar, eines für die 
Client-Area. Alle zusammen stecken in einem Rechteck, welchem ein 
Window-Manager die Eigenschaften eines Fensters verpasst und darauf 
achtet, dass diese Eigenschaften (bei Events) auch weiterhin eingehalten 
werden. So werden zwar alle Rechtecke bei einer Verschiebung 
berücksichtigt, wird das Fenster aber in der Größe verändert, schlägt 
diese Operation in erster Linie auf die Client-Area durch. ... Aber 
soweit sind wir noch lange nicht. Erst mal haben wir ja nur Rechtecke, 
die ineinander geschachtelt sind.

Trotzdem gibt es da noch einige Operationen, die erledigt werden müssen. 
Wenn ein Rechteck verschoben wird, müssen alle anderen Rechtecke 
rausgesucht werden, die neu gezeichnet werden müssen. Wobei es da dann 
durchaus auch zu einer Zerlegung der Neuzeichen-fläche kommen kann. Wenn 
Beispielsweise ein Rechteck geometrisch innerhalb eines anderen liegt, 
hierarchisch aber nichts mit ihm zu tun hat und geometrisch vor dem 
anderen liegt, dann darf das Hintergrundrechteck sich nicht vollständig 
neu pinseln, sondern es muss in 4 Teilrechtecke über/unter/links/rechts 
zerlegt werden, und man erteilt dem Hintergrundrechteck 4 Renderaufträge 
mit den jeweiligen Teilrechtecken. Das ganze kann sich dann noch 
beliebig verkomplizieren, wenn mehr als 2 Top-Level Rechtecke beteiligt 
sind.

Du musst dir auch eine Systematik einfallen lassen, nach der du 
Rechtecke am Schirm in einer Tiefenhierarchie anordnest, damit du 
erstens die Rechtecke in der richtigen Reihenfolge von hinten nach vorne 
malen kanst aber auch, damit du entscheiden kannst, wer denn einen 
Mausklick bekommt, wenn sich mehrere Rechtecke überlappen.

Und erst wenn dieses alles geklärt und implementiert ist, kannst du dich 
damit beschäftigen, was du den in den jeweiligen Rechtecken anzeigen 
lassen willst. Ich habe das Gefühl du überspringst im Moment 25 Schritte 
und fängst an das Pferd dort aufzuzäumen, wo man das erste mal etwas 
siehst, vergisst aber auf den ganzen notwendigen Unterbau.
In der Computergraphik (und ich rechne eine GUI durchaus dazu) ist es 
nicht ungewöhnlich, dass sich nicht mehr als 10 bis 20% des Codes mit 
den Dingen beschäftigt, die man tatsächlich auf der Oberfläche sieht und 
der Rest einfach nur stupide Verwaltungsaufgaben übernimmt. Du tüftelst 
jetzt an diesen 20% rum, hast aber keinen Unterbau auf dem du aufsetzen 
kannst.

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl,

Erstmal Danke für den langen Text ;) Das beschreibt sehr gut und 
verständlich das, was ich in meinen bisherigen Recherchen gefunden habe.
Das ist das was man geläufig unter "Window"-Manager versteht. Trifft 
auch zu 100% auf Desktopsystem zu.
Aber benötigen wir das auf "embedded-Devices"? Wer Fenstermanagment in 
dieser Art und Weiße braucht, hat und braucht die Leistung von Linux bzw 
WinCE Devices... Meine bisherigen Erfahrungen beruflich sowie privat 
haben gezeigt das mehrer "Fenster" für Gerätschaften wie Navis,Handys, 
MP3 Player usw nicht nötig sind. Im Prinzip gibt es überall auf diesen 
Geräten eine beschränkte Eingabemöglichkeit, wie Richtungstasten oder 
Touch und einen kleinen Bildschirm, was von vorneherein multible Fenster 
ausschließt.
Wie schaut ein herkömmlicher Bildschrim aus? Eine Taskleiste, ein 
Programmfenster mit verschiedenen Statusmeldungen,Buttons oder 
sonstigen. Der springende Punkt ist (meiner Meinung nach, wenn nicht 
bitte verbessern) es bleibt in einem überschaubaren und vorallem 
verwaltbaren Bereich. Ein Bildschirminhalt produziert automatisch ein 
"Array" aus Buttons auf die reagiert werden kann. Manche sind 
vordefiniert durchs Objekt, manche sind selbst Objekte.
Deshalb ist es im Prinzip auch falsch von einem Windowmanager zu 
sprechen (auch wenn das der geläufige Begriff ist). Das Programm soll 
einmal die Interna eines Renderes sein. Es stellt auf einfachsten Wegen 
mittel zur Verfügung um optisch was darzustellen unabhängig vom 
unterliegenden Hardwareteil. Wie was abläuft und wie was gehandelt wird 
ist jedem selbst überlassen. Es werden nur Schnittstellen 
bereitgestellt.
In deinen Worten tatsächlich die letzten 20%(...die "einfachen). Von den 
rstlichen 80% benötigt jeder was anderes, die meisten wahrscheinlich 
sogar nur 10% davon...

LG
Michael

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:

> Deshalb ist es im Prinzip auch falsch von einem Windowmanager zu
> sprechen (auch wenn das der geläufige Begriff ist).

Den Begriff Windowmanager kenne ich eigentlich nur von X. Fuer ein 
GUI-System halte ich ihn fuer voellig unpassend. Genauso wie Images 
aller Art als Sprite zu bezeichnen...

Die eigentlichen Probleme fangen an, wenn du automatisches Layouting 
machen willst. Da kannst du deine Naechte mit verbringen. Mit fixen 
Groessen ist das nicht so das Drama, aber du wirst langfristig kaum um 
ein hierarchisches System aehnlich dem, was Karl Heinz beschrieben hat, 
herum kommen. Da du die Naechte schon verplant hast, musst du die Tage 
fuer's Eventrouting einplanen...

Es sei denn, du willst nur so ein paar anklickbare Buttons haben wie auf 
der iPhone-Hauptseite.

P.S: Mein Bruder und ich haben in den 90ern ein auf Textkonfiguration 
basierendes, selbst layoutendes GUI-System fuer BeOS entwickelt - ein 
Fass ohne Boden.

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Begriff Windowmanager im Titel ist grundsätzlich falsch, bzw zu 
allgemein. Sprites trifft dafür aber schon gut zu ;)

Ohne das Konzept von mir mit allen Mitteln zu verteidigen, bin ja für 
jeden Beitrag hier dankbar, glaube ich trotzdem, das wir hier über 
Features reden die man auf so kleinen Geräten nie brauchen wird.

Der große Unterschied auf so kleinen Geräten ist, das ich weiß welches 
Programm läuft und wo was angeordnet ist. Ein "Betriebssystem" weiß das 
nicht, X weiß das nicht, und KDE/GNOME bzw die "Windowmanager" wissen 
das nicht.

Das Ziel sollte sein, mit möglichst einfachen Mitteln 
(=GIMP,PAINT,Photoshop) grafisch was darzustellen.

Der ganze Ansatz wird von hintenaufgerollt. Das einfachste was man 
machen köntne ist einen x-beliebigen MP3-Player zu nehmen, das Display 
abzufotographieren und dann auf seinem Gerät darstellen. Man weiß wo was 
steht und kann auf die Verschiedenes reagieren und ein 2tes Bild 
darstellen.
Jetzt erweitert man das ganze von 1nem Bild für den kompletten 
Bildschirm in 4-5 kleinere Objekte, die ich nach belieben darstellen 
kann + kombiniert mit einem WYSISWYG Editor. Das ist doch eine Basis, 
auf den jeder "einfach" mit entsprechenden Schnittstellen aufsetzen 
kann.

Nochmal: der Unterschied zu einem herkömmlichen WM wie bei X ist, das 
ich weiß WAS passiert und WO etwas ist und sein muss. Überlappende 
Fenster oder automatische Layout sind nicht nötig bzw vermeidbar!

Sollte ich einen grundsätzlichen Denkfehler drinnenhaben bitte darauf 
hinweisen :D Vl stell ich mir das auch zu einfach vor ;)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Der Begriff Windowmanager im Titel ist grundsätzlich falsch, bzw zu
> allgemein. Sprites trifft dafür aber schon gut zu ;)
>
> Ohne das Konzept von mir mit allen Mitteln zu verteidigen, bin ja für
> jeden Beitrag hier dankbar, glaube ich trotzdem, das wir hier über
> Features reden die man auf so kleinen Geräten nie brauchen wird.

Ich denke du solltest daher erst mal damit anfangen zu definieren, was 
du 'brauchen' wirst, bzw. was du unterstützen willst.

Wenn dir die Systematik
  Auf dem Bildschirm wird nur eine Eingabemaske angezeigt und diese hat
  die alleinige Kontrolle über den Schirm.
  Es gibt keine überlappenden Elemente
  Auch kann zur Laufzeit nichts dynamisch umherbewegt werden

wenn dir das reicht, dann ist dein Ansatz schon ok und du sparst dir 
viel Unterbau.

Nur hat man sowas früher ganz einfach eine Eingabemaske genannt und kein 
Fenster oder Window. Selbst dann nicht, wenn du diese Maske jetzt mit 
graphischen Elementen aufpäppeln willst :-)

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wollte mich mal wieder melden...
Nachdem leider mein kompletter Source durch eigene Dummheit gelöscht 
wurde, habe ich neu angefangen (daher die Verzögerung ;) )
Das Projekt lebt und die Definitionen wie was wo wie sein soll habe ich 
auch schon sehr detailliert vor mir liegen. Ich plane bis Ende nächste 
Woche ein Previewvideo zu erstellen die die Grundlegenden Fähigkeiten 
präsentiert. Wie oben schon geschrieben geht "Windowmanager" weit an dem 
vorbei was es sein wird. Es ist mehr ein GUI Renderengine.
Bei der Suche nach ähnlichen Ansätzen im Internet bin ich auf 2 sehr 
professionelle Produkte gestoßen:

http://www.mentor.com/products/embedded_software/n...
http://www.windriver.com/products/graphics/

Natürlich weiß ich nicht wie da was implementiert ist, das Ziel ist aber 
das selbe. Entscheiden ist aber das es sowas im Open-Source Bereich 
(noch) nicht gibt. Ich suche auf diesem Weg jemanden der sich JETZT 
einklinken will um die Definitionen für den WYSIWYG Editor festzulegen. 
Erst nachdem die Grundsteine gelegt sind (~ 1 Monat) wird alles 
offengelegt. Wie oben schon erwähnt zuviele Köche verderben den Brei ;) 
Ab da weg ist dann jeder herzlichst eingeladen mitzuarbeiten wenn es was 
wird :D.

Also meldet euch mal...
Dann kann man via E-Mail oder Skype mal Kontakt aufnehmen.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich suche auf diesem Weg jemanden der sich JETZT
> einklinken will um die Definitionen für den WYSIWYG Editor festzulegen.

Wenn du klug bist dann benutzt du einen vorhandenen Editor. Ein 
Beispiel dafuer waere wohl der QT-Designer von Trolltech. Eine andere 
Moeglichkeit waere ein Editor der vielleicht mal fuer einen Palmpiloten 
gedacht war.

ABER, das grosse Problem im Embedded Bereich sind die unterschiedlichen 
Bedienphilosophien. Es ist ein grosser Unterschied ob du eine Maus hast, 
ein Touchpad, ein Pen, Tasten neben der LCD, oder vielleicht ein 
Drehknopf.
Du musst dich da sehr frueh auf etwas festlegen und alles andere wuerde 
dann suboptimal werden.

Ein weiteres Problem, wenn so eine Oberflaeche sehr Leistungsfaehig sein 
soll, und keine deutlichen Beschraenkungen aufweisst, dann wird sie 
einen nur schwer vorhersagbaren dynamischen Speicherbedarf aufweisen. 
Wieviele Fenster legen jetzt gerade mit wievielen Pixeln ueber einander?
Es ist vermutlich sinnvoll sich da von vornerein stark zu beschraenken 
damit das handhabbar wird. Sonst hast du hinterher ein tolles System das 
fast nirgendwo laeuft.

Manche LCD-Controller bieten eine gewisses Hardwaremaessige 
Unterstuetzung, zum Beipiel in Form von Planes die getrennt zugeschaltet 
oder abgeschaltet werden koennen, oder miteinander verodert. Damit kann 
man sehr elegant und schnell Fenster einblenden ohne viele Byte 
verschieben zu muessen. Unterstuetzt du soetwas nicht wird dein System 
fuer manche Dinge zu langsam, fuer andere aber okay. Setzt du es vorraus 
wird es nur noch mit einigen bestimmten Panels funktionieren.

Insgesamt sehe ich eine grosse Gefahr das du mit einem grossen Aufwand 
einen fettes Monsterprogramm/libary produzierst das hinterher keiner 
mehr benutzen kann weil es zu langsam ist oder zuviele Resourcen 
braucht.

In meinem Kopf schwirrt auch schon seit Jahren die Idee rum irgendwann 
mal Openlook auf einen Microcontroller anzupassen. Openlook deshalb weil 
es so schoen alt ist und daher aus heutiger Sicht schnell sein duerfte. 
Aber auch hier leider das PRoblem, es ist fuer Maeuseschubser gedacht 
und damit fuer viele Anwendungen nicht so toll.

Olaf

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
QT ist anders, der Designer erfüllt nicht die Anforderungen. Schau dir 
mal die Werbevideos von oben genannten Toolkits ab. Der Vorteil an der 
Sache ist das die aus dem entstehenden Packet kein Programm beschreibt 
sondern nur die Visualisierung. Das Backend übernimmst jeder selbst.
Das System ist im Moment so aufgebaut das ein jedes Objekt (Grundgerüst) 
eine eigene Zeichenfunktion hat. Diese Funktion kann an die 
entsprechende Hardware angepasst werden. Das muss,kann und soll jeder 
selbst tun. Das ist nicht die Aufgabe dieser Engine. Sie stellt 
Funktionen für das Zeichnen eines Objektes zur Verfügung, wie das 
abläuft kannst du selbst bestimmen.
Du wirst im Alltag(im OS-Bereich) normalerweise nie die volle Power 
brauchen. Du wirst dir das Objekt was optimiert werden soll einfach mit 
einer neuen Zeichenroutine koppeln. Das ist aber dem Renderer egal. 
Natürlich ist es ein (mein) Wunsch das viele eigens implementierte 
Objekte möglichst für alle verwendbar in das Projekt einfließen. Und das 
ist durchaus möglich wenn man sich an die Richtlinien hält.
Es ist aber wie bei jedem anderen Opensourceprojekt auch. Du wirst nie 
alle gemeinsam glücklich machen können. Deshalb ist es nötig unter 
gewissen Abstrichen den größten gemeinsamen Nenner zu finden. Und der 
heißt unter fast jeder Platform Framebuffer. Trotzdem und das ist auch 
ein großer wichtiger Punkt: Es soll leicht und verständlich für 
jedermann erweiterbar sein. Aus diesem Grund habe ich mich auch GEGEN 
eine implementierung von einem Eventsystem für Buttons entschieden. Es 
wird nur ein rudimentäres System zur änderung von Grafiken eingeführt. 
Zb Knopf gedrück und nicht gedrückt.

Michael

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.