Das Ultimative GUI Toolkit für C++ - Wie sollte sie aussehen?
-
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.
-
Was findet ihr besser?:
a.) alle Widgets als (Windows)Fenster
b.) alle Widgets mit OGL oder DX o.ä. zeichnen@Artchi, @******* und @softwaremaker
Danke für die Erklärung von nativen Widgets
-
a
-
Und, wo bleiben die Ergebnisse?
Evtl. solltet ihr euch mal zusammensetzen, und versuchen ein gemeinsames Konzept zu erarbeiten, welches dann umgesetzt werden kann...
-
Für den schnellen und leichten Einstieg in die GUI - Programmierung halte ich Qt4 in Verbindung mit der HiQt - IDE http://www.hiqt.org auf Windowsebene für eine traumhafte Lösung.
Da Qt4 so leicht zu installieren ist und neben der guten Dokumentation eine Fülle von hervorragender Beispielen hat, würde ich jedem, der Qt4 nicht kennt, empfehlen, es wenigstens zu probieren.
Der Aufwand ist ziemlich gering und lohnt sich in jedem Fall.
-
Ähm, hier gehts gerade um die Alternativen zu solchen Monsterlibraries wie QT (wenn auch schön und modern), wxWidgets oder GTK.
-
Sorry, friends ...
-
antwort b
-
phlox81 schrieb:
+Eventmodel, welches keine Makros benötigt, und dennoch einfach zu handhaben ist.
Was hält ihr vom Observer-Muster?
-
Also wenn dir mit dem Observer Pattern was ähnliches wie bei Java Swing vorschwebt halte ich da nichts von, da C++ dieses Anonyme-Klasse-von-Interface-Innerhalb-eines-Funktionsaufrufes-Ableiten nicht untersützt und es ohne ne ziemliche Tortur wäre.
Mir würde etwas Windows.Forms Ähnliches über Boost.Signals oder was vergleichbarem gefallen.