3. GUI Bibliothek OOP Design

GUI Bibliothek OOP Design


  • (D)Evil schrieb:

    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

    0
  • *

    😉 Okay also es ist keine Platformübergreifende Bibliothek usw. gemeint 😉 Es ist nur im Moment so, dass ich es wie folgt aufgeteilt habe:
    - Basisklasse Window
    - Klasse Button
    - Klasse List
    - Klasse Label
    - usw. (Controls ...)
    - Klasse Frame

    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 😉 )

    0

  • (D)Evil schrieb:

    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

    0
  • ?

    (D)Evil das wird doch eh nichts. Du brichst spätestens nach ein paar Wochen dein Vorhaben ab.

    0
  • D

    @rolleis
    Warum sollte er das? - Ist doch interessantes Thema. Werde das früher, oder später auch noch machen.

    0
  • ?

    Das macht so gut wie jeder mal und 99% brechen es kurz danach wieder ab.

    0
  • D

    Wie bei GUIs offensichtlich oft verwendet, wuerde ich das Composite-Pattern nutzen.
    Dann so aehnlich vorgehen, wie du es schon selbst geschrieben hast: du hast eine Basisklasse und die elementaren Steuerelemente erben direkt von dieser. Des weiteren gibt es eine weitere Klasse fuer Container-Controls (Dialoge etc.), welche die zuvor erwaehnte Basisklasse erweitert.

    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

    0
  • *

    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?

    0
  • D

    Ich dachte bei einem Menue an son ein Popup-Menue bei Windows (oder ein "Haupt"-Menue einer Anwendung), da wuerde so eine feste Implementierung nicht wirklich sinnvoll sein. Ggf. koennte man auch durch Ueberschreiben eine Aenderung der Reaktion auf ein Ereignis aendern, aber das fuehrt zu zig Klassen ohne wirklichen Unterschied.
    Bei dem Desktop-Switcher ist das vermutlich etwas anderes.

    0
  • *

    Hat denn da jemand noch eine schöne Idee? 🙂

    0

  • nein. Zu meinem Design hast Du dich ja nicht geäußert...

    DeSoVoDaMu schrieb:

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

    Ich sollte mir GOF mal einverleiben 😉

    greetz, Swordfish

    0
  • *

    Hab da ehrlich gesagt nicht ganz verstanden wie du das meintest @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 😉

    0
Anmelden zum Antworten