Welche GUI soll ich nehmen?
-
Schmeisse mal lib cinder einfach ein. Wenns nur 2D UI sein muss, kann cinder sehr viel, aktuell für Win und MacOS verfügbar:
http://libcinder.orgAnsonsten, Qt muss man nicht bezahlen, die LGPL Version ist frei verfügbar.
Qt ist auch das Framework was sich am schnellsten weiter entwickelt, QML kann man langsam ernstnehmen,
auch wenn noch für den Desktop einiges fehlt.
-
@dot
Vom Visual Studio habe ich die neueste Express Version.
Dann suche ich mir mal ein Tutorial aus.
Einfach soll es nicht sein. C++ schon
Ich halte C++ füt eine sehr mächtige und schnelle Sprache. Wenn ich C# nehmen soll kann ich auch bei Java bleiben.
Mit Low-Level hätte ich kein Problem.Ich denke, ich werde mir mal die WinAPI ansehen und wenn sie mir zu kompliziert ist, werde ich wohl mit fltk oder Qt weitermachen.
Danke. Ihr habt mir alle sehr geholfen.
-
Atlan schrieb:
Wenn ich C# nehmen soll kann ich auch bei Java bleiben.
Oh glaub mir, C# ist Java sprachlich dermaßen überlegen...würdest du C# kennen, würdest du niemals freiwillig Java verwenden wo es sich vermeiden lässt...
Abgesehen davon: Ich halte eine GUI immer noch für kein besonders gutes Beispiel um C++ zu lernen und möchte an dieser Stelle nochmal auf meinen obigen Vorschlag mit dem Spiel hinweisen. Und wenn du C++ selbst erst lernen musst, würde ich unbedingt zu einem guten Buch raten und auf keinen Fall zu einem Tutorial
...
-
Ein Buch habe ich. C++ lernen und professionell anwenden von Ulla Kirch-Prinz und Peter Prinz in der 3. Auflage.
Cinder ist wohl eher nichts für mich, da ich was C++ angeht noch ein Neuling bin.
Etwas, was man "langsam ernstenehmen" kann ist wohl auch eher nichts. Da laufe ich Gefahr Dinge nicht zu finden, die ich aber gerne hätte oder ich stolpere über einen Bug. Trotzdem danke.Eigentlich möchte ich durch die GUI nur die umständliche Konsole ersetzen. Aber wenn ich dabei gleich ein bisschen Erfahrung im Coden sammeln kann umso besser.
Das C# Java so weit überlegen ist wusste ich nicht. Aber es soll Java ähnlich sein. Und eigentlich wollte ich eine neue Sprache lernen. (Java und C++ ähneln sich zwar auch aber angeblich nicht so sehr, wie Java und C#)
-
Fang endlich an!
-
dot schrieb:
Natürlich stellt sich unweigerlich die Frage: Wieso eine riesige Library mitliefern, die nichts anderes tut, als das Betriebssystem zu imitieren, wenn man auch einfach das Betriebssystem verwenden könnte.
Naja...
- "riesige Library" spielt für uns und für die meisten anderen überhaupt keine Rolle. Unsere Software (also, alles was erstmal installiert wird) ist an sich schon paar GB groß, zusammen mit den Daten, die man üblicherweise verwendet, hunderte GB oder wenige TB. Selbst wenn nicht, spielt es für die meisten anderen auch keine Rolle. Dann liefert man halt noch 10 MB Dlls mit, OMG.
- Weil die Library das tut, und nicht du Ich finde, es ist unendlich viel mehr Aufwand, mit direkt mit der WinApi zu arbeiten, als mit einer entsprechenden Bibliothek. GUI unterteilt sich für mich in zwei Sachen. Zum einen gibts komplett uninteressante, lästige Standardsachen, die man schnell hinter sich bringen will. z.B. schnell einen Einstellungsdialog mit paar Eingabefeldern und Buttons hinrotzen. Geht mit Qt in einer halben Stunde, mit der WinApi müsste man erstmal jeden möglichen Scheiß von Hand machen. Warum sollte sich das irgendjemand antun? Und dann hat am Ende auch einen Haufen Boilerplate Code, den man auch irgendwann auch warten muss.
Zum anderen gibts auch (öfter) GUI Komponenten, die viel komplexer als irgendwelche Standardgeschichten sind. Und wenn die Bibliothek hier schon was bietet, schön. Allein die Layouts wären ein Grund, ein entsprechendes Framework zu verwenden. Es gibt in Windows z.B. nichts, was mit einer QTreeView vergleichbar wäre. Also, Baumansicht mit mehreren Spalten. Es gibt auch keine Labels, Tooltips usw., die ohne weiteres HTML rendern können. Sehr praktisch, wenn man sich dran gewöhnt hat. In Qt gibts Stylesheets und damit kann man das Aussehen sehr einfach und ziemlich flexibel anpassen. Das Konzept mit den Models und Delegates erlaubt es auch, relativ elegant an vielen Stellen einzugreifen und etwas anzupassen. In der WinApi gibt es keine Konzepte. Du reagierst auf WM_PAINT und machst was du willst. Das wird erfahrungsgemäß nicht elegant, jeder wirds machen, wie er will, nicht wiederverwendbar, nicht wartbar.
Also versteh ich deine Frage nicht so ganz. Ein entsprechendes Framework bietet sehr viele Vorteile gegenüber der reinen WinApi.Die WinApi find ich ungeeignet, um irgendwas zu lernen. Klar, Qt ist nur ein weiteres Gui Toolkit, da lernt man nicht viel interessantes. Aber das ist zumindest einfacher und angenehmer als die WinApi. Kann gut sein, dass man die WinApi nie brauchen wird, also braucht man sich da auch nicht großartig reinzudenken.
@Atlan: warum willst du die Dlls nicht einzeln mitausliefern? Das ist kein Nachteil. Die eigenen Programme, die man schreibt, bestehen auch sehr oft aus vielen Dlls und nicht aus einer monolithischen Exe.
-
Mechanics schrieb:
Naja...
- "riesige Library" spielt für uns und für die meisten anderen überhaupt keine Rolle. Unsere Software (also, alles was erstmal installiert wird) ist an sich schon paar GB groß, zusammen mit den Daten, die man üblicherweise verwendet, hunderte GB oder wenige TB. Selbst wenn nicht, spielt es für die meisten anderen auch keine Rolle. Dann liefert man halt noch 10 MB Dlls mit, OMG.Es mag keine Rolle spielen, trotzdem ist es keine saubere Lösung und ich finde es weder gut noch empfehlenswert...
Mechanics schrieb:
Ich finde, es ist unendlich viel mehr Aufwand, mit direkt mit der WinApi zu arbeiten, als mit einer entsprechenden Bibliothek.
Ich habe auch nie behauptet, dass es weniger Aufwand wäre, mit der WinAPI zu arbeiten...
Mechanics schrieb:
Also versteh ich deine Frage nicht so ganz. Ein entsprechendes Framework bietet sehr viele Vorteile gegenüber der reinen WinApi.
Ich glaub du verstehst mich falsch, ich argumentiere hier nicht gegen den Produktiveinsatz von Frameworks, Toolkits, etc.
Ich stelle allerdings die Frage in den Raum, wieso C++ verwendet wird, wenn Produktivität eine dermaßen große Rolle spielt...Mechanics schrieb:
Aber das ist zumindest einfacher und angenehmer als die WinApi.
Ja; genauso ist Python auch einfacher und angenehmer als C++ und Zivilisation angenehmer als allein in der Wildnis überleben...
Mechanics schrieb:
Kann gut sein, dass man die WinApi nie brauchen wird, also braucht man sich da auch nicht großartig reinzudenken.
Um unter Windows mit dem System zu reden, braucht man die WinAPI. WinAPI ist sehr viel mehr als nur das bisschen Zeug was Fensterchen macht. Die WinAPI ist die Schnittstelle zum ganzen Betriebssysystem. Wenn man C++ programmiert, wird man früher oder später mit dem System reden wollen. Wenn nicht, hat man mit C++ sehr wahrscheinlich von vorn herein die falsche Sprache gewählt. Wenn man sich unbedingt einbildet, C++ verwenden zu müssen, um ein GUI zu bauen und dabei etwas lernen will, hat man imo mehr davon, sich dabei mal anzuschauen, wie so GUI Kram im Hintergrund wirklich funktioniert und gleichzeitig mit der WinAPI vertraut zu werden, als in C++ wieder das zu machen, was man zuvor schon in Sprache XY gemacht hat und was man in jeder anderen Sprache genausogut nur einfacher machen könnte...
-
dot schrieb:
Wenn man C++ programmiert, wird man früher oder später mit dem System reden wollen.
Oder auch nicht unbedingt... Bei uns in der Firma hat kaum jemand direkt mit der WinApi zu tun. Das sind vielleicht 2-3 Leute, mich eingeschlossen. Wir bauen etwas an der Qt selber rum, wenn uns etwas nicht passt (und wir verwenden sie auch für Dateisystemzugriffe und Netzwerkkommunikation), dann haben wir eine COM Zwischenschicht, um die wir uns kümmern müssen, und natürlich muss man ab und zu verschiedene Problemchen beheben, wenn man mit anderen Programmen interagiert. Sonst hat keiner irgendwas mit der WinApi zu tun.
-
Mechanics schrieb:
Sonst hat keiner irgendwas mit der WinApi zu tun.
Dennoch hat also selbst dort jemand was mit der WinAPI zu tun...
-
dot schrieb:
Mechanics schrieb:
Sonst hat keiner irgendwas mit der WinApi zu tun.
Dennoch hat also selbst dort jemand was mit der WinAPI zu tun...
Klar, das wollte ich ja nie abstreiten. Ich wollte nur sagen, dass man als einzelner Entwickler durchaus durchs Leben kommen kann, ohne jemals mit der WinApi zu tun gehabt zu haben. Und wenn man sie jetzt noch nicht braucht, würde ich sie auch nicht von sich aus lernen wollen, weil sie einfach relativ komplex und unangenehm ist, vor allem wenn man sich noch nicht auskennt.
-
Welche Sprache mit welchem Framework ist denn gut für GUI-Anwendungen geeignet und steht auf allen Plattformen in robuster Form zur Verfügung?
Es gibt keinen Grund, warum man nicht auch in modernem C++ eine GUI-Bibliothek hinbekommt, die ohne MOC und Krams auskommt, außer dass es keinem kommerziellen Hersteller dient, da dies kein Vendor-Lock-In bietet. Und so kocht eben jeder sein eigenes kleines Süppchen. Apple macht Objective-C, Microsoft knallt WinRT unter C++ und was nicht noch alles.Die moderneren Teile der WinAPI sind durchaus brauchbar, manche erst im zweiten Anlauf und dort fällt einem dann auch schnell auf, wie sehr das mit guter C++-Kapselbarkeit einhergeht. Aber das eigentliche Fenstersystem und Gdi/Gdiplus und wie Direct2D umgesetzt ist zählt eindeutig zu den Verbrechen an der Menschheit.
-
@decimad
Also rätst du mir von der WinAPI ab, da die unnötig kompliziert und/oder "schlecht" gecodet ist? Zumindest der GUI Teil?@dot&Mechanics
Vielleicht sollte ich mich, sollte decimads Beitrag stimmen, erst mkt der WinAPI beschäftigen, wenn es so weit ist, dass ich sie benötige. Wenn ich am Programmieren dran bleibe wird es sicher, allein schon aus Neugier, so sein, dass ich der WinAPI begegne.Dann wird es wohl Qt. Die WinAPI behalte ich aber im Hinterkopf. fltk kann, denke ich, nicht mehr als Qt, weshalb ich es wohl nicht benutzen werde. Aber trotzdem behalte ich es auch im Hinterkopf.
Vielen Dank euch allen. Ihr habt mir sehr geholfen (zum, ich glaube, dritten Mal )
-
Ja, ich würde Dir auf jeden Fall zu Qt raten. Aber Qt ist wegen Moc, Lizenz und Unternehmen dahinter auch nicht der Weisheit letzter Schluss... Aber das beste momentan für C++ verfügbare - eine riesige Community und extrem aktive Entwicklung sprechen außerdem dafür. Du musst nur selbst entscheiden, wie sehr Du Dich auf das ganze drumherum einlässt, also alles, was nicht die GUI betrifft.
-
Oh mein Gott, jetzt ist es raus! Mein Neujahresgruß Account kann aufgrund von Unachtsamkeit eindeutig zugeordnet werden! *imbodenversink*
-
@ηatnθ
Interessanter Name
So werde ich es tun. Erst mit Qt anfangen, fltk mal ansehen und ggf. auch verwenden und dann mal die WinAPI benutzen, wenn ich angeben will oder sie brauche oder sie mal ausprobieren will.
-
Also die WinAPI ist beileibe keine Haxx0r-Angelegenheit, mit der man groß angeben könnte und eigentlich auch ziemlich gut dokumentiert. Sie ist eher so wie die Klisché-Freundin, die vor alles, das man theoretisch irgendwann einmal gebrauchen könnte, und auch wirklich nur das, ein paar Klimbim-Sachen stellt.
-
Also ist sie doch nicht so schlecht aber kompliziert?
Aber ich bleibe bei meinem Entschluss Qt zu verwenden, fltk mir anzusehen und ggf. auch verwenden und die WinAPI mir ansehen und ggf. auch verwenden.
Trotzdem danke.
-
Atlan schrieb:
Also ist sie doch nicht so schlecht aber kompliziert?
Schaus dir selber an
Nein, ich find sie auch nicht so schlecht und so kompliziert, aber ich arbeite schon seit über 15 Jahren ab und zu damit. Und wenn man langsam damit anfängt, muss man auch nicht so viel können. Aber grad das ganze GUI Zeugs in der WinApi ist sehr umständlich und unangenehm. Das muss man sich einfach nicht antun, wenn man nicht muss.
Ich hab früher (so vor 15 Jahren angefangen) Delphi prorgammiert und da musste ich noch einiges mit der WinApi machen. Die Delphi Komponenten waren hauptsächlich Wraper um WinApi Controls und Funktionen. Da war der Einstieg aber nicht so schlimm, ich musste nichts from Scratch machen. Ich hatte ja schon meine Fenster, Events usw. Ich konnte mir aber z.B. das Handle von einem Control holen und damit was machen, z.B. dem Control eine Message schicken, oder eine Funktion aufrufen, die der Delphi Wrapper nicht implementiert hatte. War alles halb so wild, waren ja nur einzelne Funktionen, in einem problemlos funktionierenden Grundgerüst.
So ein Grundgerüst mit der WinApi aufzubauen finde ich aber ziemlich ekelhaft. Das sind so 50-100 Zeilen Code, die man braucht, um überhaupt mal ein Fenster anzuzeigen. Und dann diese ganzen Windows Messages, die alle unterschiedlich aufgebaut sind, diese Funktionen mit 20 Parametern usw... Muss nicht wirklich sein.
-
Dieser Thread ist größer geworden, als ich gedacht hätte.
@Mechanics
Ich finde ja schon Funktionen mit fünf Parametern schlimm.
Zum Glück gibt es Dinge wie Qt, fltk, Cinder, MFC usw, die für mich diese Funktionen aufrufen. Jetzt hab ich mal eine Vorstellung, wie das Arbeiten mit der WinAPI ungefähr ist. Danke.
-
1. Qt runterladen
2. Die Beispiele und Tutorials im QtCreator ansehen und glücklich werden...
