ein neues gui toolkit (nur ideen)

[ness]

[Auch wenn das ganze in einer betriebssysthemunabh. sektion steht, beziehe ich mich mitunter auf linux/unix]
Diese idee ist in den letzten paar tagen meines urlaubs gereift, daher... Jetzt bin ich zu hause und versuche das ganze mal zu papier zu bringen.
Hm, wie fang ich jetzt an...
In letzter zeit ist die, für einen heimanwender vorhandene rechenleistung derart angestiegen, das eyecandy immer mehr in den vordergrund gerückt ist. Wir haben alle möglichen netten farbverläufe, schatten, transparenz, ansätze der hardwarebeschleunigten oberfläche,... Am ende ist das meiste meines wissens nach in 2 kategorien aufzuteilen:
a)hacks
b)ausnutzung dessen, was schon seit jahren verfügbar aber durch rechenleistung begrenzt war

Einen neuen weg hat das enlightenment team eingeschlagen. Edje erlaubt es, darstellung und logik auf eine völlig neue weise zu trennen. z.b. hier sieht man, was das an eyecandy hergibt. Die sache hat nur einen haken: so schön das ganze aussieht, so wenig glaube ich, dass das ganze am ende gut aussieht. Die sache ist nämlich die, dass die themes _programmbezogen_ sind! Es gibt zwar auch eine widget library, aber die bietet nicht viel neues. Ich habe noch nicht mit einem entwickler darüber gesprochen, aber ich weiß nicht, wie die sich das vorstellen. Jetzt in der enticklungsphase ist alles schön und gut, denn für jedes Programm gibt es ein theme das farblich zum default theme des wm passt. Aber wie soll das weitergehen, der wm fertig ist und sich themes ansammeln? Das zu jedem theme für die ewl (enlightenment widget library) auch ein theme für den wm gehört mag sich ja durchsetzen, aber was ist mit den anderen programmen, wie z.B. eclair? Entweder man begnügt sich damit, es in farblich unpassenden defaults oder einem der wenigen themes dafür erstrahlen zu lassen oder steigt auf einen konventionellen player um, nur aus dem grund, dass einem ein selten benutztes theme zusagt. OK, jetzt sagt vielleicht jemand, eclair (und ähnliche) sind so mit e17 verbunden, dass man einem themer zumuten kann, für einen ganzen, aber begrenzten, fundus von programmen themes zu erstellen, aber was, wenn die nutzung der efl sich auch nur annähernd so verbreitet wie die von gtk oder qt? Aus besagten gründen wird dann wohl fast nur noch die, nicht sehr herausragende, ewl benutzt werden.
Kurzum: das vorläufige ergebnis is schick, aber das design nicht zukunftsfähig.

Irgendwann bin ich zu diesem Schluss gekommen, und habe [mit meiner wenigen erfahrung und anhand des beispiels eclair] überlegt, wie man beides unter einen hut bringen kann. Was will man überhaupt:
-die möglichkeit, programme zu erstellen, die so gut aussehen wie eclair und co.
-1 theme für alle programme
-trotzdem enorme freiheiten für den themer

Jetzt kommen wir zur sache, folgendes habe ich mir überlegt:
was, wenn man das aussehen des programmes abstrakter hinterlegen würde? (OK, das sagt jetzt nichts, ich hoffe am nachfolgenden bsp. wirds klarer)
am beispiel eclair:
hier mal noch eclair in einem anderem theme. Eine abstrakte definition stelle ich mir so vor:
Wir haben ein rechteckiges hauptfenseter, verhältnis von länge und breite werden absolut zur abstrakten größe des bildschirms angegeben, die abstrakte größe des bildschirms sei 800x600. Links und rechts des hauptfensters gibt es einen rahmen, beide zentriert und mit absoluten (in wirklichkeit aber relativen) größenangaben. Der linke rahmen ist ein, ich nenne es jetzt mal ausfahrbare fenster, breite wie gehabt, vielleicht noch die angabe, dass es auf der selben ebene wie das hauptfenster liegt. Das bild wird schon fast zur nebensache. So geht das halt weiter... besondere aufmerksamkeit würde ich der knöpfen links schenken: angabe des mittelpunkts des play/pause knopfes, um den kreisförmig 4 andere knöpfe angeordnet sind, drumrum ein rahmen, angabe des radius des gedachten kreises, des abstandes zwischen den äußeren knöpfen, zw. den äußeren knöpfen und dem inneren knopf, und so weiter und so fort. Hier zeigt sich besonders schön die abstraktion: im rechten theme ist der rahmen z.b. nicht rund, aber trotzdem ist das konzept der kreisförmigen anordnung der knöpfe eingehalten. Die bilder auf den knöpfen sind entweder vektorgrafiken (die aber nur die form, nicht die farbe des bildes angeben) oder defaults (durch das theme bereitgestellt). Dazu klassische elemente: slider, listen, ... was halt so dazugehört. Alles hinter einem guidesigner versteckt.

Zur umsetzung habe ich mir folgendes überlegt: das programm hat 2 teile: ein mal seine aussehensdefinition, und andererseits seinen programmteil. Wird das programm gestartet, lädt das toolkit das aktuelle theme (das in wirklichkeit eine bibliothek ist) und übergibt diesem die aussehensdefinition, daraus macht das theme das bild, wie das programm aussieht und übergibt es dem renderer, der das programm darstellt. Kommt ein event rein, geht das ganze zunächst and das theme, welches feststellt, was zu tun ist. Wenn nötig, das erscheinungsbild des programmes ändern und das hauptprogramm informieren, wenn z.b. ein button geklickt wurde. Irgendwie muss diese verbindung auch rückwärts gehen, soll heißen, das programm sagt dem theme, was passieren soll. Setzt wohl eine gut geplante klassenhierarchie voraus.
Naja, so ungefähr jedenfalls.

Was haltet ihr davon?

[SideWinder]

Die Trennung von Logik und Aussehen halte ich sowieso für unabdingbar. MVC-Modell halte ich bei GUI-Toolkits immer für gut - umso mehr die V-Komponente vom System und nicht vom einzelnen Programm abhängt umso "gleicher" sehen die Programme aus.

Die Frage ist nur: Wäre es nicht besser für QT/GTK/sonstwas ein Theme-Konzept zu bauen (wenn das nicht bereits sowieso vorhanden ist...) als eine komplett eigene Library? Bedenke den Aufwand.

BTW: Such mal bei Sourceforge nach dem GOTT-Projekt und teile denen deine Ideen mit. Vielleicht finden die das auch ganz interessant

MfG SideWinder

[Artchi]

Also Qt und GTKmm haben ein eigenes Theme-System. Gut, ob sie so spektakulär aussehen können wie in den aufgeführten Links ist eine andere Frage. Die Themes von Qt und GTKmm sind jedenfalls so flexibel wie man es von Swing her kennt. Kann jeder z.B. mit GIMP2.x ausprobieren, da kann man mind. zwischen GTK-Look und XP-Look umschalten. Funktioniert wunderbar.

Und Model-View-Konzept hat ja selbst die alte MFC, nennt sich dort halt Doc-View-Konzept. Für GTK gibts eine Modelview-Erweiterung, kann man sich extra runter ziehen und Qt hat das ganze auch in Version4.0 eingeführt, nennt sich dort Interview.

[ness]

Äh, der post über mir, das war ich net, nur um das mal klarzustellen, beiträge sind weiter gewollt.
Ja, trennung von logik und aussehen ist natürlich richtig, dazu ist das theming/mvc ja da. aber mit edje wird soweit getrennt, dass ein theme immer nur auf ein programm passt.
Der einwand, dass das viel zu viel aufwand ist, ist sofort akzeptiert. Ich sehe mich auch gar nicht in der lage dazu, so ein großes projekt zu realisieren. Aber der vorschlag, meine idee in einem anderen Projekt unterzubringen, ist net schlecht. Was mich mehr interessieren würde ist, was ihr von einem derartigen abstraktionskonzept allgemein halten würdet.

[Mr. N]

sorry für den enormen delay.

du hast den Beitrag ins GOTT Forum verlinkt. leider ist das zu low-traffic um von den entwicklern gelesen zu werden *G*. ich les das hier jetzt mal und weise im channel darauf hin.

UPDATE:
kontakt am besten per IRC, irc.euirc.net (der server auf dem auch #cpp ist) channel #gott