# Immediate Gui



## schalentier (9. Jan 2012)

Hallo,

hab ueber Weihnachten etwas entdeckt: Immediate Gui.

Is schon etwas aelter und offensichtlich gibts keine oder nur wenige Implementierungen, vielleicht ist es auch echt ne bescheuerte Idee... trotzdem mal die Frage: Kennt das jemand? Schon mal damit rumexperimentiert? Oder gar irgendwo sowas im Einsatz?

In Kurz gehts darum, dass die meisten Gui Frameworks (also z.B. Swing, Qt, CEGUI, ...) extrem umfangreich, komplex, nervig und vor allem unuebersichtlich sind. Das liegt zu einem grossen Teil daran, dass die Inhalte der Gui, jeweils zweimal gespeichert werden muessen (einmal direkt irgendwie an der Gui-Komponente und nochmal im Kontext der eigentlichen Anwendung - z.B. muss bei einer einfachen Taschenrechnerapp, die Zahl im Textfeld gespeichert werden und gleichzeitig natuerlich irgendwie im Rechenalgorithmus). Der meiste Gui Code beschaeftigt sich dabei mit der Synchronisierung dieser beiden Stellen (was meistens ueber Events, Listener oder Signal/Slot Techniken geloest wird).

Die alternative Idee ist nun, dass alles wegzulassen und stattdessen, das Ganze "immediate", also direkt abzuhandeln. Konkret sehe das dann ca so aus (Pseudocode):

```
String input;
void doGui() {
   for( int i=0; i<10; i++ ) {
     if( doButton( toString(i) ) ) { // true = Button wurde geklickt
        input += i;    
     }
   }
   if( doButton( "Exit" ) ) {
      System.exit();
   }
   input = doTextField( input ); // rendert ein Textfeld mit dem aktuellen Text und liefert den (evtl. per Tastendruck geaenderten zurueck) 
   ...
}
```

Die doButton() Methode koennte im Kern so aussehen:

```
int hot; // dieses Element ist hot, z.B. die Maus befindet sich ueber einem Button
int active; // dieses Element ist aktiv, z.B. ein Button ist aktuell gedrueckt

boolean buttonLogic( int id, boolean mouseOver, String text ) {
   boolean result = false;
   if( !isAnyElementActive() ) {
      if( mouseOver ) {
        setHot( id );
      }
      if( isHot( id ) && isMouseDown() ) {
        setActive( id );
      }
   }
   if( isActive( id ) ) {
      if( mouseOver ) {
         setHot( id );
      }
      if( isMouseUp() ) {
         result = isHot( id );
         clearActive();
      }
   }
   if( isHot(id) ) { renderButtonHovered(); }
   else if( isActive(id) ) { renderButtonPushed(); }
   else { renderButtonNormal(); }

   return result;
}
```

Ich hab absichtlich einiges (unerlaessliches) weggelassen, wie Layoutzeug oder Id-Vergabe und die "API" is alles andre als schoen; aber es geht ja ums Prinzip.

Da ich grad eine kleine GUI in einer OpenGL Anwendung brauche, experimentiere ich nun bissel rum, wie und ob man damit tatsaechlich was anfangen kann.

Falls das jemand genauer interessiert, es gibt nen Video, wo das schoen erklaert wird: 1h Videovortrag und die Diskussion dazu.

Eure Meinung dazu wuerde mich interessieren ;-)


----------



## XHelp (9. Jan 2012)

Wenn ich in Pascal eine GUI unter DOS machen müsste, würde die vermutlich so ähnlich aussehen :bahnhof:

Den erklärenden Vortrag müsste ich mir zwar noch angucken, aber das da sieht verdächtig nach Polling aus.
Darüber hinaus sprichst du oben von "extrem umfangreich, komplex, nervig und vor allem unuebersichtlich" und packst anschließend die ganze GUI in eine Methode. Na ob das besser ist... Also nur von deiner Beschreibung her sehe ich da weder Sinn noch Nutzen.


----------



## schalentier (10. Jan 2012)

Polling? Naja, ich hab glaub ich vergessen, dass es primaer um Guis fuer Spiele geht. Da hat man ja eigentlich immer nen Gameloop, in dem man update() und render() aufruft. Da kommt dann einfach noch nen Aufruf dazu, der die Gui abarbeitet. Ist das Polling?

Und natuerlich kann man den Gui Code auf mehrere Methoden aufteilen - das ist gleichzeitig auch der eigentliche Clou: Das alles ist kein Framework, in das man seine Fenster und Widgets programmiert, sondern eine Library, und man benutzt die Methoden zum Behandeln/Rendern der Widgets. _Wie_ man die benutzt, ist Sache der Anwendung, nicht des Frameworks...


----------

