Komplett eigene GUI-Bibleothek programmieren
-
-
Ja schon klar.
Die Frage war ja, ob du sowas wie die WinAPI machen willst, oder eher den Aufsatz für die WinAPI, also wxWidgets usw.
Wenn es sowas wie die WinAPI werden soll, dann sag ich schon mal viel Spaß (ca. 80 Zeilen Code nur für einen Button).
-
Es sollte sowas wie wxWidgets und Qt sein, also eine GUI-Bibleothek mit eigenen GUI-Elementen (neuer Rand, Bedienbuttons (Minimieren, Schließen etc) und neue Fensterbuttons), also ich glaube eher ein "Aufsatz".
Wenn es sowas wie die WinAPI werden soll, dann sag ich schon mal viel Spaß (ca. 80 Zeilen Code nur für einen Button).
Seitwann kann man eine GUI-Bibleothek ohne Ansatz der API des OS machen?
-
patrik++ schrieb:
Seitwann kann man eine GUI-Bibleothek ohne Ansatz der API des OS machen?
Indem man statt Winapi, OpenGL verwendet.
-
OpenGL hört sich gut an, da ich mir sowieso ein Buch dazu kaufen möchte.
Gruß,
Patrik
-
Hey Patrick!
Ich kann deinen "Selbermach-Willen" nur allzu gut verstehen (Den besitze ich nämlich selber auch ;-)) Aber ich will zu all den API kurz etwas erklären:
wxWigdets "wrappt" andere API's um einfacheres Programmieren zu ermöglichen und vorallem um den selben Code auf mehreren OS zum laufen zu bringen.
Andere API's zeichnen alles selber (Stichwort: SDL,OpenGL,DirextX,...) und kümmern sich um Dinge wie Textfelder , Zeichen usw. Hierbei ist immer das Problemder Portabilität undvorallem: DES AUFWANDES!
»
Ich habe wirklich schon lange gebraucht um eine brauchbare Konsolen API für meine Programme zu erstellen aber für eine richtige GUI würde ich jedenfalls eine Ewigkeit brauchen.Lg nt0r
EDIT: Bei Selbstrendernden GUI-APIs ist die Portabilität eigentloch sehr hoch. Sorry
-
Hi,
ich schreib zur zeit ein Spiel, und schreibe dafür ein eigenes GUI toolkit.
Dafür benutze ich QPainter, QImage und QSvgRenderer.
Ich erzeuge keine eigenen Fenster, und ich rendere auf ein 2d overlay, allerdings sollte die Logik und das rendern an sich nicht besonderst anderst sein.Wenn du willst, kann ich dir ein paar Tips geben, wenn du nicht weiterkommst, oder wie du anfangen sollst.
mfg matogel
EDIT: Ich benutze für das Rendern Qt, und für die Styles SVG's, eventuell lohnt es sich für dich auch, Cairo(https://de.wikipedia.org/wiki/Cairo_(Grafikbibliothek)) anzuschauen, Damit kannst du auch SVG's rendern, das ist meiner Meindung nach die EInfachste möglichkeit. Alles selber rendern, das würde ich mir nicht antun. Und ich tu mir viel an
Edit2: Achso, OpenGL lohnt sich nicht, das ist zu viel Arbeit, eine 3D API für 2D Anwendungen? Meiner Meinung nach macht das keinen Sinn, ausser du willst eine high-performance GUI schreiben. Und wenn du verschiedene Betriebssysteme unterstützen willst, macht es das ganze nochmal aufwendiger
-
Hi,
das mit dem Aufwand ist mir klar, werde dieses Projekt dann sowieso mit 'nen Kollegen machen. Ich werde aber eher OpenGL nehmen (dazu gleich dieses Buch: http://www.it-fachportal.de/shop/buch/3D-Grafik%20mit%20OpenGL/detail.html,b168879), da sich OpenGL halt für mehr einsetzen lässt, als nur für GUI-Entwicklung (als SDL nur für 2D).
Gruß,
Patrik
-
patrik++ schrieb:
..., da sich OpenGL halt für mehr einsetzen lässt, als nur für GUI-Entwicklung ...
Naja, die Api lässt sich ja auch für mehr einsetzen als nur für die GUI-Entwicklung. Also, mit dem Argument solltest du aber nicht an die Sache rangehen
-
patrik++ schrieb:
das mit dem Aufwand ist mir klar, werde dieses Projekt dann sowieso mit 'nen Kollegen machen.
Hm, es wird trotzdem sehr viel Aufwand, glaub mir, ich schreib zur Zeit auch ein eigenes GUI Toolkit...
patrik++ schrieb:
Ich werde aber eher OpenGL nehmen
Das ist den Aufwand nicht wert. Benutz OpenGL lieber für die Sachen, für die es gedacht ist: für 3D Anwendungen.
Ich würde dir aus meiner Erfahrung mit GUI's empfehlen, dass du dir wirklich auf 2D Libraries beschränkst, das ist schon schwer genug.
-
Du könntest dir auch mal die AlgierLib von Artchi anschauen. Leider scheint es so, als hätte er die Entwicklung vor Kurzem eingestellt
-
Nexus schrieb:
Du könntest dir auch mal die AlgierLib von Artchi anschauen. Leider scheint es so, als hätte er die Entwicklung vor Kurzem eingestellt
Was wirklich schade ist, da mir die Lib eine schoene, moderne API hatte.
Was ich an den meisten GUI Bibliotheken hasse ist, dass die Standard Bibliothek nicht verwendet wird (und stattdessen selbstimplementierte Bibliotheken verwendet werden). Ausserdem werden bei den meisten GUI Libs moderne C++ Features nicht verwendet (selbst Kleinigkeiten wie namespaces).
Ich versteh ja, dass die Compiler das frueher nicht konnten, aber ist der Aufwand sooo gross eine existierende GUI Lib mal der heutigen Zeit anzupassen?
-
Ich versteh ja, dass die Compiler das frueher nicht konnten, aber ist der Aufwand sooo gross eine existierende GUI Lib mal der heutigen Zeit anzupassen?
Ja. GUI's sind nicht mal eben so gemacht.
Wenn ich bedenke, dass meine GUI (die noch keine aufwendigen Sachen beinhaltet, nur standart Krams) schon an die 6000 Zeilen hat, und Qt an die 3000000 Zeilen hat, ist es ein riesen Aufwand etwas zu ändern.
-
[quote]Was ich an den meisten GUI Bibliotheken hasse ist, dass die Standard Bibliothek nicht verwendet wird (und stattdessen selbstimplementierte Bibliotheken verwendet werden). Ausserdem werden bei den meisten GUI Libs moderne C++ Features nicht verwendet (selbst Kleinigkeiten wie namespaces).
Ich versteh ja, dass die Compiler das frueher nicht konnten, aber ist der Aufwand sooo gross eine existierende GUI Lib mal der heutigen Zeit anzupassen?[/quote]Mit dem Anpassen der Library ist es nicht getan. Aenderungen wie Du sie vorschlaegst, sind in der Regel nicht transparent (Source und ABI) fuer die _Benutzer der Bibliothek_, die muessten also ihr Zeug _auch_ anpassen, und das ist gerade im kommerziellen Bereich schwer. Software wird haeufig extern "eingekauft", und muss dann ein paar Jahre halten. Fuer Anpassungen ist kein Geld da, und wenn dann gar noch irgendwelche Zertifizierungen noetig sind wie z.B. im medizinischen Bereich, dann ist fuer Aenderungen gar kein Platz. Im Open Source-Bereich ist es nicht viel besser. Schau die mal an, wie lange KDE gebraucht hat, um von 3 auf 4 zu wechseln.
Abgesehen davon gehst Du davon aus, dass Standard eitel Sonnenschein und alles andere Mist ist. Ist beides nicht so
Und es ist auch nicht so, dass neue Sprachfeature komplett ignoriert wuerden. Bei Qt kannst Du z.B. konfigurieren, ob die Bibliothek in einem Namespace liegen soll, und wie der heissen soll. Und wenn Du Dir mal QStringBuilder anschaust, wirst Du feststellen, dass da _deutlich_ mehr "modernes C++" verbaut ist, als in einer typischen std::string Implementation.
-
https://paste.ofcode.org/Ej8SQMF3sQ77pQqbmYRy5m
Es bleibt leider nur eine Woche online.Durch _meinen_ begrenzten IQ un die Stereotaxie mit Rinderkollagen ergeben sich halt immer Fehler beim konzeptionellen Weitblick. Aber es kann Fenster erzeugen, auch Topmost- oder Modalfenster einfügen in die Hierarchie und man kann die Update-Semaphoren dann auch im Programm abfangen und das Zeug verarbeiten.
Für DOS-Spiele wie Sim City, Civilization, Dune oder Populus ist das wohl gut genug. Aber ich habe ernsthafte Verständnisprobleme mit so einer Message-Queue oder Multitasking. Es fängt ja schon mit kbhit() an, während die Anwendung noch auf eine Antwort vom Druckertreiber wartet. Ich meine, verschiedene Streams und das Eingabe-Verarbeitung-Ausgabe-Prinzip. Jetzt heißt es, die Anwendung kann die Message-Queue auch nach einer bestimmten Sorte Signale durchsuchen (etwa für das entsprechende hwnd-Window oder für Eingabetypen wie Tastatur oder Modem). Aber mein Gott. Ich belasse es mal dabei, daß die Eingabeabfrage immer nach dem ersten Signal direkt abbricht und daß das dann erst einmal verarbeitet werden muß. Doppelklicks wären auch kein Problem, wenn ein Fenster-Datenobjekt immer zwei Timestamps drinnen hat...
ich habe ernsthafte Verständnisprobleme zum Thema Multitasking und Multithreading. Entweder das EVA-Prinzip oder das Prinzip der atomaren Transaktionen wären eine Antwort. Man muß wohl immer aufpassen...
Aber wenn ich sage, ich blicke das, dann schreibe ich das, so gut ich provisorisch erstmal kann.