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
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?
Angehängte Dateien:
-
bsp.png
130 KB
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.
1 | struct TEXT |
2 | {
|
3 | UID
|
4 | X.Size |
5 | Y.Size |
6 | String
|
7 | Color
|
8 | }
|
9 | |
10 | struct Button |
11 | {
|
12 | UID
|
13 | X.Size |
14 | Y.Size |
15 | *Sprite1 |
16 | *Sprite2 |
17 | String
|
18 | Event
|
19 | }
|
20 | |
21 | struct Panel |
22 | {
|
23 | UID
|
24 | X.Size |
25 | Y.Size |
26 | Background
|
27 | *ObjectfromPanel |
28 | *ObjectfromPanel |
29 | ...
|
30 | }
|
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).
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?
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).
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.
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.
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.
Ja klar geht das. Ape hat dazu mal einen Fontgenerator geschrieben.
http://code.google.com/p/ehalos/source/browse/#svn/trunk/miscellaneous/eHalos_screenshots Hier siehst du zum Beispiel eine Arial, und ein paar Sprites.
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...
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.
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
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.
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 ;)
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 :-)
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/nucleus-graphics/ 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.
> 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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.