Das GUI von einem Container (HWND) soll verwaltet werden. Hab letztens hier gelesen das Th sich schonmal mit GUI Bibliotheken-Design rumschlagen musste. Wie würdet ihr so eine Bibliothek sinvoll anlegen? Die einzellnen Widgets (Controls) befinden sich jeweils in Frames (Windows). Soll ich einen Seperaten "Renderer" haben? Zwischen Eingabe und Ausgabe strikt trennen?

Also, gehen wir mal davon aus, das ich eine GUI Bibliothek am schreiben bin.

*lol* Du _bist_ dran, eine GUI Lib zu schreiben!

Ein- und Ausgabe kann man in GUIs oft nicht strikt trennen.
Welche Aufgabe hätte Dein Renderer?

greetz, Swordfish

Ist aber in dem Fall nicht wirklich angebracht... da zum rendern fest GDI+ genutzt wird.

*lol* Du _bist_ dran, eine GUI Lib zu schreiben!

Wie soll man deine Aussage interpretieren?

Swordfish schrieb:

*lol* Du _bist_ dran, eine GUI Lib zu schreiben!

Wie soll man deine Aussage interpretieren?

Du fragst wegen dem *lol*? Bitte denk' jetzt nicht, dass ich mich über Dein Vorhaben lustig mache. Mich hat nur Deine Ausdrucksweise amüsiert - so hart am Konjunktiv. Und zudem hab ich ein paar Minuten vor deinem Post wieder 'mal in "Warum machen wir uns nicht eine neue schöne C++ GUI Bibliothek?" gestöbert.

Mein Hauptaugenmerk bei einer GUI Bibliothek würde ganz klar auf der Usability liegen - für den Programmierer. Hast Du Dir schon über das Entstehen einer Oberfläche innerhalb Deines Konzepts Gedanken gemacht?

greetz, Swordfish

Diese werden von der Klasse Manager verwaltet. D.h. dieser kapselt ein WinAPI-Fenster (HWND) in eine Klasse und bei entsprechender Nachricht, kümmert er sich darum, das die Windows mit den entsprechenden Informationen versorgt werden.
Dann gibt es noch eine Klasse Menu, die auf gleicher ebene wie der Manager ist und einen Zeiger auf diesen hat. Dadurch kann durch ein Klick auf ein Menu-Item erreicht werden, dass bestimmte Fenster aus/eingeblendet werden.
Zusätzlich hat der Manager noch einen Status "waiting" in dem er durch ein Overlay abgedunkelt wird und ein "Ladekreis" eingeblendet wird(mit Animation).

Doch ehrlich gesagt finde ich das Klassendesign so sehr schlecht Und d.h. wollte ich mal eure Vorschläge dazu hören. (Hab anfangs kein Konzept gehabt und einfach drauf los geschrieben ... es funktioniert, aber schön / wiederverwendbar ist das nicht )

Diese werden von der Klasse Manager verwaltet. D.h. dieser kapselt ein WinAPI-Fenster (HWND) in eine Klasse und bei entsprechender Nachricht, kümmert er sich darum, das die Windows mit den entsprechenden Informationen versorgt werden.

Klingt mir sehr künstlich. Auf die schnelle würd' ich eher:

class menu_bar_t;
class tool_bar_t;
class status_bar_t;
class window_t;
class child_window_t : window_t;
class parent_window_t : window_t {

    menu_bar_t   m_menu_bar;
    tool_bar_t   m_tool_bar;
    status_bar_t m_status_bar;

    container_t< parent_window_t | child_window_t > childs;
};

class app_t;

class pushbutton_t : child_window_t;
class listbox_t : child_window_t;
...

Aber wahrscheinlich nicht praxistauglich (?)

greetz, Swordfish

Diese werden von der Klasse Manager verwaltet. D.h. dieser kapselt ein WinAPI-Fenster (HWND) in eine Klasse und bei entsprechender Nachricht, kümmert er sich darum, das die Windows mit den entsprechenden Informationen versorgt werden.

Ja, so in etwa wuerde ich das auch loesen. Wobei das Verteilen der Nachrichten ja schon von Windows gehandled wird. Die Manager-Klasse selbst wuerde ich als ein Container-Control implementieren.

Dann gibt es noch eine Klasse Menu, die auf gleicher ebene wie der Manager ist und einen Zeiger auf diesen hat. Dadurch kann durch ein Klick auf ein Menu-Item erreicht werden, dass bestimmte Fenster aus/eingeblendet werden.
Zusätzlich hat der Manager noch einen Status "waiting" in dem er durch ein Overlay abgedunkelt wird und ein "Ladekreis" eingeblendet wird(mit Animation).

Also das halte ich fuer Quark (sprichst du von Windows-Menues oder irgendwie etwas anderem?). Ich weiss nicht genau fuer was du das machen willst, aber ein Menue-Item sollte nicht irgendwie fest beinhalten, nur fuer das Verschwinden von Fenstern da zu sein.
Mach es zu einem Control wie etwa einen Button auch (ggf. gleiche "Zwischen"-Basisklasse) und mach das OnClick-Ereignis zu einer Callback-Methode (oder so...) und damit leicht aenderbar.
Aehnliches gilt fuer den "Ladekreis".

Ich bin selbst auch so vorgegangen (du hast ja offensichtlich den letzten Thread dazu gelesen) und bin damit auch sehr zufrieden, allerdings ist die Problemstellung bei mir etwas anders. Ich kapsle nicht nur fuer eine Plattform sondern will das ganze plattformunabhaengig haben. Ausserdem ist es mehr fuer Grafik-APIs wie OpenGL ausgelegt.

Naja...wie heißt es so schoen...Just my two cents

Gruss,
DeSoVoDaMu

Also das halte ich fuer Quark (sprichst du von Windows-Menues oder irgendwie etwas anderem?). Ich weiss nicht genau fuer was du das machen willst, aber ein Menue-Item sollte nicht irgendwie fest beinhalten, nur fuer das Verschwinden von Fenstern da zu sein.

Naja, es ist kein Quark Es handelt sich natürlich nicht um ein Standard Windows-Menü. Es ist noch ein weiteres "HWND" (gewrappet ...), das einen Array von Fenster-Zeigern, Menütitel, Menüicon beinhaltet.

Naja das Menü ist vielmehr die Möglichkeit, sich verschiedene "Desktops" aufzurufen. Jeder Menü-Punkt ist sozusagen ein Desktop (mit den einzellnen Frames, die wieder einzellne Controls haben) und der Benutzer kann den entsprechenden "Desktop" dann auswählen.

Aehnliches gilt fuer den "Ladekreis".

Naja ich könnte höchstens hingehen und einen Thread für den Ladekreis starten, und im anderen Thread dann eine OnLoad()-Callback aufrufen. Aber ob das wirklich komfortabel ist?

DeSoVoDaMu schrieb:

Wie bei GUIs offensichtlich oft verwendet, wuerde ich das Composite-Pattern nutzen.

Ich sollte mir GOF mal einverleiben

greetz, Swordfish

Also ich denke, das ich das so mache:
-Manager (Desktop):
* Container: Window
* MessageProc (WinAPI) an Fenster weiterleiten
* (De-)aktivierung der Eingaben: d.h. Layer über Desktop-Fenster blenden & Nachrichten-Weiterleitung unterbinden
-Fenster (Frames):
* Container: Control
* Behandeln der Nachrichten(von Desktop empfangen) & Weiterleiten an Controls
- Control (abstract)
* Behandeln der Nachrichten
* Alle Controltypen werden von Control abgeleitet

Naja recht einfaches Konzept, aber nun gut