Das Ultimative GUI Toolkit für C++ - Wie sollte sie aussehen?
-
Hey ihrs,
Ich habe mich schon länger nach einer GUI Bibliothek umgesehen, welche meine Wünsche erfüllt. Irgendwie bin ich nicht wirklich auf das richtige gestossen. Alles hat seine Vor und Natürlich Nachteile, und die Nachteile haben mich dazu bewogen was neues zu suchen.
Nun frag ich mich wie für euch die Ultimative C++ GUI Bibliothek aussehen sollte.
Für mich wichtig:
- Portabilität
- Minimale Anforderungen an den Endbenutzer (z.b. in auf Linux nicht gezwungen sein unter KDE GTK+ libs nutzen zu müssen oder gar diese installieren zu müssen)
- ein Modernes Design
- Möglichst keine Macros
- Auf gar keinen Fall irgendwelche Syntax Extensions (Code sollte auf API level in reinem C++ geschrieben sein, die abstraktion ist ja durchaus möglich)
- Einfache Verwendung für den EntwicklerIch glaub ich könnte noch mehr dazu packen aber schreibt mal einfach wie das für euch aussehen sollte.
Gruß,
Vinzenz
-
Da bist du nicht alleine!
Ich habe, nachdem ich meine bekannte Tabelle erstellt habe, auf den Gedanken gekommen, das dort ein Toolkit auftauchen sollte, das optimal ist.
Und so habe ich angefangen, im stillen Kämmerlein, meine GUI zu entwickeln. Vorallem aus den Postings in diesem GUI-Forum, kann man sehr gut die Wünsche "ablesen". Ich habe auch sogar aktuell mehr Arbeit (in Stunden) in die Dokumentation für den Toolkit-Anwender gesteckt. Gut, das Toolkit ist noch nicht fertig. Aber die Doku dient mir auch gleichzeitig als Lasten-/Pflichtenheft.
Bisher:
- keine Makros
- Namespaces
- Enums
- Templates, dort wo Sinn macht (ich habe keine Templates benutzt, nur um Templates drin zu haben)
- einfache API, mit den wichtigsten Klassen und Funktionen
- native Widgets!!!
- Callbacks über std::tr1::function!
- naja... und nur eine LIB-Datei..
-
Ja, es suchen wirklich noch mehr Leute nach der ultimativen" GUI: http://c-plusplus.net/forum/viewtopic-var-t-is-186830.html
Artchi, ich freue mich schon auf das eventuelle Release deiner Bibliothek. Ist diese auch OS-unabhängig? Und wieviele Klassen hat die schon? Erzähl mal was davon
-
Meine Lib habe ich eigentlich angefangen, weil ich was für meine eigene Anwendung brauchte. Also für den Eigenbedarf. Aber ich bin dabei, es anwenderfreundlich zu machen.
Die Lib ist plattformneutral, aber bisher von mir nur für Win32 implementiert. Klassen für den Anwender sind es nicht so viele.
Wenn meine eigene Anwendung damit soweit gut läuft, habe ich vor es zu releasen. Dürfte aber bis Weihnachten noch dauern. Ich habe aber im Forum schon von anderen Mitgliedern heraus gelesen, das der ein oder andere ebenfalls an seiner eigenen Lib bastelt. Ich bin da keine Ausnahme.
-
Ultimativ ist aus meiner Sicht einfach nicht machbar.
Das Thema ist zu komplex, und es gibt auch immer wieder Moden, und jeder hat dann noch eigene Vorlieben.Für mich wären wichtige Punkte:
+Nutzung nativer Widgets
+Einfache Schnittstelle um eigene Widgets (nativ) zu zeichnen.
+Wo möglich Templates als Datenstrukturen, bzw. einfache Möglichkeit in Interaktion mit den Daten zu treten.
+Eventmodel, welches keine Makros benötigt, und dennoch einfach zu handhaben ist.
+Keine_Komischen_Coding_Conventions
+Gute Dokumentation
+Einfacher aufbau, design by Simplicity. ( es kann immer noch eine Option für komplizierteres geben)
+evtl. Skinning, da das immer mal wieder Thema ist.
+Liberale Lizenz.
-
Ultimativ ist aus meiner Sicht einfach nicht machbar.
Das sehe ich anders, es müssten sich nur welche hinsetzen, und ne vernünftige Bibliothek bauen. Deine Kriterien sind doch ganz realistisch...
-
Yo, kann mikey nur zustimmen. Die Wünsche und Forderungen sind meistens nicht unrealistisch. Ich habe die letzten Jahre in meiner GUI-Lib-Rundreise immer eines festgestellt:
Alte gestandene Major-Libs:
Die alteingesessenen Projektleiter wollen alte C++-Technik bis zum Erbrechen weiter unterstützen, weil es z.B. laut wxWidgets-Projektgurus noch Compiler ohne ISO-Standard-Lib gibt. Und aktuelle C++-Technik würde für alte Projekte einen Bruch bedeuten. Es ist also kein Machbarkeitsgrund, sondern ein politischer Grund.Historisch gewachsene Libs:
Libs wie gtkmm sind vom C++-Style so wie ich mir das vorstelle. Aber das gtkmm mit seinem Rattenschwanz (tausend andere Libs werden benötigt) ist so komplex, das ich als MSVC-User echt aufgegeben habe, nur weil ich ein paar kleine Fensterschen aufmachen wollte. Und Windows eigentlich schon alles mitbringt. Unter Linux sicherlich alles out-of-the-box vorhanden, aber für Windows... Kanonnen auf Spatzen geschossen.Dann gibts da noch die kommunistischen Libs:
Wenn ich sowas lese, dann kommt mir das Ko***. Eine "freie" Lizenz die diskriminiert, wer nicht so denkt, wie die Lizenz. Fällt für mich raus, als MSVC-User (auch wenn jetzt jemand mit nem Hack kommt, aber darum geht es mir nicht). Wenn es ein technischer Grund wäre oder allgemein Qt nicht mit MSVC laufen würde (keine Manpower oder MSVC ist zu schlecht), würde ich Verständnis haben.Die dahin vigitierenden Libs:
Das sind die kleinen Libs, die zu Anfang Potential aufzeigten, aber durch die Übermacht der gestandenen Libs keine Weiterentwicklung erleben. Schade.
Da wären z.B. SmartWin und VCF zu nennen. Auch die Doku wird bei jungen Libs vernachlässigt, was höchst wahrscheinlich auch die Folge hat, das sie nicht weiter entwickelt werden, weil sie niemand nutzt weil die Doku schlecht ist. Selber schuld!Mein Fazit? Viele GUI-Libraries haben ihre Probleme "hausgemacht"! Nicht weil es technisch oder sowas unmöglich ist. Es sind sogar meistens politische Gründe.
Ich will mal die Wünsche von evilissimo und phlox81 kommentieren:
- Portabilität
Mit C++ das kleinste Problem. Für die Abstraktion bietet C++ gute Highlevel-Möglichkeiten.- Minimale Anforderungen an den Endbenutzer (z.b. in auf Linux nicht gezwungen sein unter KDE GTK+ libs nutzen zu müssen oder gar diese installieren zu müssen)
Mit Linux kenne ich mich nicht aus, aber sobald unter Linux etwas nativ sein soll, muß denke ich GTK+ oder Qt herhalten? Unter Windows ist es null Problemo, die Win32-API für die GUI ist immer gleich und immer vorhanden.- ein Modernes Design
Das es geht, hat gtkmm und SmarWin++ bewiesen. Beide haben unterschiedliche Design-Ansätze, aber beide modern (es gibt ja nicht einen einzigen richtigen Weg)- Möglichst keine Macros
Warum Makros sein müssen, habe ich bisher auch noch nie verstanden...- Auf gar keinen Fall irgendwelche Syntax Extensions (Code sollte auf API level in reinem C++ geschrieben sein, die abstraktion ist ja durchaus möglich)
Stimme ich 100% zu.- Einfache Verwendung für den Entwickler
Das ist möglich. Am besten nur Templates oder ein einfacher Build, der keine Compiler absichtlich ausschliesst. Für gängige Compiler sollte man sogar fertige Builds anbieten (siehe wxPack oder Boost-MSVC-Installer von Boost Consulting Ltd.).+Nutzung nativer Widgets
Das es für Multiplattform-Libs geht, hat wxWidgets und VCF bewiesen.+Einfache Schnittstelle um eigene Widgets (nativ) zu zeichnen.
Hem, verstehe ich nicht ganz.+Wo möglich Templates als Datenstrukturen, bzw. einfache Möglichkeit in
Interaktion mit den Daten zu treten.
Ein ModelView-Konzept lässt sich realisieren. Auch wenn ich es in einem ersten Schritt für vernachlässigbar halte. Für große datenlastige Applikationen aber auf jeden Fall wichtig!+Eventmodel, welches keine Makros benötigt, und dennoch einfach zu handhaben ist.
Yo, mit dem TR1 ist das mehr als einfach (std::tr1::function).+Keine_Komischen_Coding_Conventions
Ok, das ist jetzt aber wirklich Geschmackssache. Das kannst du nicht als schlecht oder gut bewerten. Da haben wir selbst hier in unserem Java-Projekt 5 Personen und 5 unterschiedliche Geschmäcker. Es gibt Überschneidungen, aber sobald du Details abfragst, mag und macht es jeder anders. Es gibt natürlich verbreitete Codingstyles, und die sollte dann eine Library auch vorzugsweise verwenden.+Gute Dokumentation
Seeeehr wichtig! Ich hasse nichts mehr, als wenn mir jemand eine Lib "verkaufen" will, und ich ne schlechte Doku habe. Da nützt mir die tollste Technik nichts. Vorallem für Anfänger ultimativ wichtig.+Einfacher aufbau, design by Simplicity. ( es kann immer noch eine Option für komplizierteres geben)
Yo, gehe ich 100% mit.+evtl. Skinning, da das immer mal wieder Thema ist.
Ist selbst bei nativen Win32-Controlls möglich (soweit ich mich mit Win32 auskenne). Muß man nur in der Lib geschickt implementieren und ermöglichen.+Liberale Lizenz.
Die ist autom. nötig, sonst scheitert solch eine GUI-Lib. Denn die GPL kann sich nur eine Lib leisten, die ein Alleinstellungsmerkmal hat. Da kann man bei einer GUI-Lib nicht gerade von reden.
-
mikey schrieb:
Ultimativ ist aus meiner Sicht einfach nicht machbar.
Das sehe ich anders, es müssten sich nur welche hinsetzen, und ne vernünftige Bibliothek bauen. Deine Kriterien sind doch ganz realistisch...
Sehe ich anders, weil wenns in die Details reingeht, schon Konflikte entstehen beim Design etc.
Der eine hätte es lieber so, der andere so. Gerade dies zeigt ja auch die Wirklichkeit bei den heutigen Frameworks.
Egal ob alt oder neu.Artchi schrieb:
Dann gibts da noch die kommunistischen Libs:
Wenn ich sowas lese, dann kommt mir das Ko***. Eine "freie" Lizenz die diskriminiert, wer nicht so denkt, wie die Lizenz. Fällt für mich raus, als MSVC-User (auch wenn jetzt jemand mit nem Hack kommt, aber darum geht es mir nicht). Wenn es ein technischer Grund wäre oder allgemein Qt nicht mit MSVC laufen würde (keine Manpower oder MSVC ist zu schlecht), würde ich Verständnis haben.Naja, ich kann Trolltech da aber verstehen, sie leben schliesslich auch von ihrer Lib. Da wollen sie natürlich keine freie Lösung für eine Professionelle IDE liefern.
Artchi schrieb:
Die dahin vigitierenden Libs:
Das sind die kleinen Libs, die zu Anfang Potential aufzeigten, aber durch die Übermacht der gestandenen Libs keine Weiterentwicklung erleben. Schade. Da wären z.B. SmartWin und VCF zu nennen. Auch die Doku wird bei jungen Libs vernachlässigt, was höchst wahrscheinlich auch die Folge hat, das sie nicht weiter entwickelt werden, weil sie niemand nutzt weil die Doku schlecht ist. Selber schuld!Mein Fazit? Viele GUI-Libraries haben ihre Probleme "hausgemacht"! Nicht weil es technisch oder sowas unmöglich ist. Es sind sogar meistens politische Gründe.
Ja, die hausgemachten Probleme kommen da noch hinzu. Nichts desto trotz gibt es halt auch designkonflikte etc.
Artchi schrieb:
- Minimale Anforderungen an den Endbenutzer (z.b. in auf Linux nicht gezwungen sein unter KDE GTK+ libs nutzen zu müssen oder gar diese installieren zu müssen)
Mit Linux kenne ich mich nicht aus, aber sobald unter Linux etwas nativ sein soll, muß denke ich GTK+ oder Qt herhalten? Unter Windows ist es null Problemo, die Win32-API für die GUI ist immer gleich und immer vorhanden.Ist halt eine der Fragen, wie setzt man das "OS Layering" in der Library um, so das es einfach zu implementieren ist, aber trotzdem nicht mehr im Alltag erscheint.
Artchi schrieb:
- ein Modernes Design
Das es geht, hat gtkmm und SmarWin++ bewiesen. Beide haben unterschiedliche Design-Ansätze, aber beide modern (es gibt ja nicht einen einzigen richtigen Weg)Was ist eine moderens Design?
Artchi schrieb:
+Einfache Schnittstelle um eigene Widgets (nativ) zu zeichnen.
Hem, verstehe ich nicht ganz.Es muss möglich sein, auch eigene Steuerelemente zu implementieren. Wie man das z.b. mit wxPanel machen kann,
in dem man dann die verschiedenen Events selber abfängt, und z.b. entsprechend die Ausgabe selberzeichnet.
Dieses Zeichnen muss so gekapselt sein, das es möglichst Nativ läuft. Es darf also nicht wie GTK erst noch auf eine Abhängigkeit aufsetzen.Artchi schrieb:
+Eventmodel, welches keine Makros benötigt, und dennoch einfach zu handhaben ist.
Yo, mit dem TR1 ist das mehr als einfach (std::tr1::function).Hatte eher an boost::signals gedacht. tr1::function ist mir noch nicht geläufig.
Artchi schrieb:
+Keine_Komischen_Coding_Conventions
Ok, das ist jetzt aber wirklich Geschmackssache. Das kannst du nicht als schlecht oder gut bewerten. Da haben wir selbst hier in unserem Java-Projekt 5 Personen und 5 unterschiedliche Geschmäcker. Es gibt Überschneidungen, aber sobald du Details abfragst, mag und macht es jeder anders. Es gibt natürlich verbreitete Codingstyles, und die sollte dann eine Library auch vorzugsweise verwenden.Ist aber wichtig. Denke sich an boost zu orientieren ist ratsam.
Aber auf keinen Fall sowas wie gtk, wo_dann_ellenlange_methoden_namen_entstehen_nur_weil_es_so_konvention_ist().Artchi schrieb:
+evtl. Skinning, da das immer mal wieder Thema ist.
Ist selbst bei nativen Win32-Controlls möglich (soweit ich mich mit Win32 auskenne). Muß man nur in der Lib geschickt implementieren und ermöglichen.Muss aber auch gescheit als Schnittstelle global definiert sein! Global denken, nativ handeln
phlox
-
Sehe ich anders, weil wenns in die Details reingeht, schon Konflikte entstehen beim Design etc.
Der eine hätte es lieber so, der andere so. Gerade dies zeigt ja auch die Wirklichkeit bei den heutigen Frameworks.
Egal ob alt oder neu.Geht es wirklich um Details?
Ich denke nicht. Es gibt in KEINEM Bereich eine perfekte Library. Aber darum geht es doch in den ewigen Threads nicht, wenn jemand was anzumeckern hat. Es geht doch einfach um grobe Schnitzer, wo man sich fragt: "Was soll das?" Z.B. Messagemaps per Makros. Mir ist es egal ob es function oder signal ist. Aber bitte keine Makrohölle.Wenn dich Details an jede Lib stören, mußt du selber was basteln. Ich finde die Std-Lib auch nicht bis ins Detail toll. Aber im großen und ganzen gefällt sie mir, und benutze sie gerne. Nur weil mich ein paar Details stören oder ich es anders gelöst hätte, ist die Std-Lib nicht schlecht. Würde ich aber an jeder zweiten Stelle oder an den meistgenutzten Stellen immer fluchen, wäre es tatsächlich schrott. Aber Event-Handling ist bei einer GUI das tägliche Geschäft, da tun sich Makros irgendwie schlecht. Würde z.B. das FOX-Toolkit nur an seltenen Stellen Makros benutzen, und nicht in den Messagemaps, wäre es richtig cool.
Was ist eine moderens Design?
Z.B. keine Makros. Ausnutzung der Std-Lib. Für mich heißt modernes Design nicht erzwungenes "weil ist cool" Design. Sondern einfach sauberes Design. gtkmm ist für mich z.B. modern. Keine Präprozessor-Tricks, kein Moc. Vom C++-Design halt wie C++ "rein" sein sollte.
Ich erwarte keine Hyper-Meta-Programming-Höhenflüge... weil es wahrscheinlich bei einer GUI nicht viel Vorteil bringen würde.Es muss möglich sein, auch eigene Steuerelemente zu implementieren. Wie man das z.b. mit wxPanel machen kann,
in dem man dann die verschiedenen Events selber abfängt, und z.b. entsprechend die Ausgabe selberzeichnet.
Dieses Zeichnen muss so gekapselt sein, das es möglichst Nativ läuft. Es darf also nicht wie GTK erst noch auf eine Abhängigkeit aufsetzen.Achso. OK, dann mußt du halt nur nen Grafikkontext anbieten, der Malfunktionen anbietet. Tief unten landet es aber immer irgendwo bei der nativen Grafikfunktion. Ob du was zwischen schaltest (z.B. Cairo), ist eine Designentscheidung die natürlich Abhängigkeit schafft. Technisch gibt es aber keinen Grund. Aber einen eigenen Gfx-Kontext zu basteln, ist Fleissarbeit.
Hatte eher an boost::signals gedacht. tr1::function ist mir noch nicht geläufig.
signals hatte ich bei mir auch erst drin. Aber es gibt so viele Leute, die es nicht gebacken kriegen Boost zu builden... und signals muß nunmal gebuildet werden. tr1::function ist aber templatebasiert undauch ein sauberes Konzept. Kann man sogar mit zur GUI-Lib direkt ausliefern, wenn jemand kein tr1 hat bzw. ab 2009 ist es eh offiziell std::function und bei den Major-Compilern serie.
Ist aber wichtig. Denke sich an boost zu orientieren ist ratsam.
Aber auf keinen Fall sowas wie gtk, wo_dann_ellenlange_methoden_namen_entstehen_nur_weil_es_so_konvention_ist().Ja, wie gesagt: man sollte eine verbreitete Codestyle verwenden. Ich selber benutze den Style der Std- und Boost-Lib (die Boost hält sich ja an die von der Std-Lib). Dann kann man nichts falsch machen.
-
Artchi schrieb:
Sehe ich anders, weil wenns in die Details reingeht, schon Konflikte entstehen beim Design etc.
Der eine hätte es lieber so, der andere so. Gerade dies zeigt ja auch die Wirklichkeit bei den heutigen Frameworks.
Egal ob alt oder neu.Geht es wirklich um Details?
Ich denke nicht. Es gibt in KEINEM Bereich eine perfekte Library. Aber darum geht es doch in den ewigen Threads nicht, wenn jemand was anzumeckern hat. Es geht doch einfach um grobe Schnitzer, wo man sich fragt: "Was soll das?" Z.B. Messagemaps per Makros. Mir ist es egal ob es function oder signal ist. Aber bitte keine Makrohölle.Wenn dich Details an jede Lib stören, mußt du selber was basteln. Ich finde die Std-Lib auch nicht bis ins Detail toll. Aber im großen und ganzen gefällt sie mir, und benutze sie gerne. Nur weil mich ein paar Details stören oder ich es anders gelöst hätte, ist die Std-Lib nicht schlecht. Würde ich aber an jeder zweiten Stelle oder an den meistgenutzten Stellen immer fluchen, wäre es tatsächlich schrott.
Naja. Also wenn es um die Ultimative GUI Lib geht, muss es auch um Details gehen können.
Und bisher sind die Vorschläge ja nur sehr Grob, klar das die keine Konflikte aufwerfen. Aber es geht halt nicht ohne die Details.
Von daher denke ich, das man zwar durchaus eine GUI Lib schreiben kann, die gut mit C++ hamoniert, aber man wird um gewissen Konflikte nicht herum kommen.Was die Messagemaps angeht, so hat man halt das damals gemacht. Templates waren da entweder nicht modern, oder entsprechend nicht vorhanden im Wissen der Entwickler.
Im übrigen ist man nicht auf diese Angewiesen.
Selbiges gilt für die Standard Library oder Erweiterungen wie Boost. Das man es heute anders machen würde, ist also völlig klar.Artchi schrieb:
Was ist eine moderens Design?
Z.B. keine Makros. Ausnutzung der Std-Lib. Für mich heißt modernes Design nicht erzwungenes "weil ist cool" Design. Sondern einfach sauberes Design. gtkmm ist für mich z.B. modern. Keine Präprozessor-Tricks, kein Moc. Vom C++-Design halt wie C++ "rein" sein sollte.
Ich erwarte keine Hyper-Meta-Programming-Höhenflüge...Sehe ich ähnlich, möglichst pures C++. Und es sollte in einer anständigen Zeit kompilierbar sein, was z.b. Templates angeht. So verhindert man auch codebloat.
Und die Library sollte ja auch gut zu debuggen sein.
-
Es wurden aber hier die Sachen genannt, die man haben will. Und das waren nicht details wie "eine Setter-Methode muß set_X heißen". Solche Dinge wurden hier nicht genannt, weil den meisten diese Details nicht sofort in den Sinn gekommen sind. Also sind sie auch nicht das Hauptproblem bei den ganzen C++-GUIs.
Natürlich hat jeder an Details, wenn er täglich damit arbeitet, was zu meckern. Ist ja normal. Deshalb machen wir hier auf Arbeit hin und wieder Code Reviews in den Meetings. Aber meistens werden grobe Schnitzer angesprochen. Ich selber denke mir bei Details "Naja, ich weiß das er gerne seine Variablen so und so benennt. Lass ich ihn. Aber das Ding, das geht ja garnicht!"
So in etwa.Von daher denke ich, das man zwar durchaus eine GUI Lib schreiben kann, die gut mit C++ hamoniert, aber man wird um gewissen Konflikte nicht herum kommen.
Und genau das muß erstmal gemacht werden. Konflickte sind immer da. Selbst bei einem HelloWorld, kommt einer an, und sagt "Benutze kein using namespace!". Aber das sind Luxus-Probleme.
Sehe ich ähnlich, möglichst pures C++. Und es sollte in einer anständigen Zeit kompilierbar sein, was z.b. Templates angeht. So verhindert man auch codebloat.
Und die Library sollte ja auch gut zu debuggen sein.Yo, stimme ich dir zu. ich habe z.B. nur in den Implementierungen Templates verwendet. Als User der Lib kommt man praktisch kaum damit in Berührung. Wenn es sinnvoll und Vorteil ist, kommt ein Template zum Zug.
-
das ultimative gui toolkit und das, was ich haben will, sind zwei dinge, die nicht vereinbar sind.
ultimativ bedeutet portabel, abstrakt, für alle fälle gewappnet. was striktes trennung von model und view bedeutet, abstrakte klasse, die noch viel abstraktere daten aufnehmen, zig callbacks besitzen und generell einfach unhandlich sind. das ist toll, wenn man... öhm. ne, eigentlich ist das nie toll
ich brauch nichts abstraktes. ich hab nicht das problem, dass ich in einer anwendung, 600 verschiedenenartige objekte in dieselbe tabelle kleben muss. ich hab eine handvoll objekte, die eh nicht alle gleichartig dargestellt werden. ich muss mir letztendlich eh irgendwelche handgestrickten controller für meinen bedarf selbst stricken. die ganze abstraktheit des toolkits ist unnötiger ballast, der es allgemein und "portabel" halten soll.also was wäre das total ultimative super gui toolkit? ein toolkit ohne schnickschnack, ohne abstrakte modelle. ein simples interface, das sich automatisch meinen daten anpasst, ohne dass ich 27 schichten zwischen datum und toolkit schalten muss. wer mir so ein toolkit baut, der hat gewonnen
-
Ja, phlox81 hatte ja die Einfachheit angesprochen. Das wollen wohl auch die meisten haben. Das ist denke ich auch ein Erfolgsgeheimnis von Swing. Man kann damit was anfangen. Details die mir daran nicht gefallen, kann ich in meiner sechs jährigen Swing-Laufbahn viel aufzählen (dazu gehört nicht mal Speed!). Aber im großen und ganzen ist Swing gut.
Habe schon in letzter Zeit im Netz gelesen, das es Leute gibt, die sich über die anwachsende Komplexheit von Qt aufregen. Ist aber halt nicht einfach die Balance für jeden Menschen/Projekt zu behalten. Ich denke, der Bedarf regelt, wie sowas sich entwickelt. Wird etwas in einer Form nicht gebraucht (weil es niemanden Recht ist), stirbt es.
Viele wollen eine größere C++-Std-Lib haben. Am besten alles rein was es an Technik gibt. Aber das C++-Komitee nimmt nicht jeden Mist auf. Sie müssen nachziehen, aber sie müssen eine Balance behalten.
-
Ich entwickle seit 6 Jahren nebenberuflich kommerziell Anwendungssoftware mit VC++ 6.0 und MFC. Da ich von MFC weg will habe ich mir sehr viele GUI-Libs angeschaut und war auch davor selbst eines zu entwickeln. Jedoch ist dies sehr viel Arbeit, gerade wenn diese Cross-Plattform sein soll.
Deswegen habe ich mich entschlossen doch auf eine vorhandene zu setzen und diese für meine Bedürfnisse anzupassen, dabei vielen in die engere Wahl:
- Qt
- wxWidgets
Die anderen C++ Libs können da einfach nicht mithalten, ist natürlich aus meiner Sicht und Anforderungen so.
Von den Grafikmöglichkeiten her gefiel mir noch JUCE (www.rawmaterialsoftware.com/juce).Qt ist mir einfach zu teuer (gerade wenn für 2 oder 3 Plattformen).
Meine Wahl viel also auf wxWidgets, auch wenn nicht ganz ohne "Bauchschmerzen".Man muss wohl einfach Kompromisse eingehen, denn ein GUI-Toolkit komplett neu zu entwickeln wird sehr schwer und allen kann es doch nicht gerecht werden.
-
Artchi schrieb:
- Minimale Anforderungen an den Endbenutzer (z.b. in auf Linux nicht gezwungen sein unter KDE GTK+ libs nutzen zu müssen oder gar diese installieren zu müssen)
Mit Linux kenne ich mich nicht aus, aber sobald unter Linux etwas nativ sein soll, muß denke ich GTK+ oder Qt herhalten? Unter Windows ist es null Problemo, die Win32-API für die GUI ist immer gleich und immer vorhanden.Naja, GTK und Qt setzen ja beide auf X auf. Man könnte also eine Grafikbibliothek direkt über X implementieren.
Ich bin jedenfalls gespannt auf deine GUI-Bibliothek
Vielleicht finden sich ja hier im Forum genügend, die die Linux und Mac-Ports entwickeln Felix
-
Ja ich weiß, dumme Frage:
Was sind native Widgets?
-
Phoemuex schrieb:
Naja, GTK und Qt setzen ja beide auf X auf. Man könnte also eine Grafikbibliothek direkt über X implementieren.
Ja, aber wenn man selber direkt auf X aufsetzt, muß man ja noch die Widgets implementieren? X bringt sicherlich keine mit, oder täusche ich mich da? Deshalb wäre es aus zeitlichen Gründen besser, wenn man auf eine fertige Widget-Lib setzt.
Phoemuex schrieb:
Ich bin jedenfalls gespannt auf deine GUI-Bibliothek
Vielleicht finden sich ja hier im Forum genügend, die die Linux und Mac-Ports entwickeln Wird Opensource die Lib, dann kann jeder mithelfen... aber da darf man nicht zu viel erwarten, die meisten OS-Projekte werden meistens eh nur von ihren ursprünglichen Initiatoren weiter entwickelt. Zus. Beitragende gibts selten.
-
SilentRob schrieb:
Ja ich weiß, dumme Frage:
Was sind native Widgets?
Ein Widget ist ein grafisches "Ding", z.B. ein Knopf, Eingabefeld, Kontextmenü. Nativ ist sozusagen eingeboren, natürlich oder auch gebürtig. Alles was nachprogrammiert oder selber gemacht ist, ist nicht nativ.
-
SilentRob schrieb:
Was sind native Widgets?
Interface-Elemente, die vom Wirtsystem bereitgestellt werden.
-
Native widgets:
Willst du einen Button haben dann schreibst du unter Windows:
CreateWindow("BUTTON","Hier der Text auf dem Button",...,Position,Größe,...)
BUTTON ist unter Windows eine vordefinierte "Klasse".Das Betriebssystem übernimmt nun das Zeichnen des Buttons und das Verhalten (Maus über Button, Mausclick, ...).
Vorteil: Button passt sich dem Style des Betriebssystems an (Win98, XP, Vista) auch wenn Themes aktiviert sind sieht der Button nicht fremd aus.Viele Toolkits zeichnen den Button selber und bilden auch das Verhalten nach, nur können dann die Buttons anders aussehen als "normale" Buttons des Betriebssystems.
Gleiches gilt für alle anderen Steuerelemente. Und so kommts das einige Programme unter WinXP/Vista aussehen wie unter Win95.