Das Ultimative GUI Toolkit für C++ - Wie sollte sie aussehen?
-
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.