wxWidgets vs Qt

jaf

[quote="scheiss qt"]Was ich damit meine ist, dass man die Methoden aus fertigen Klassen nicht kopieren kann wegen den ganzen Q_Q(...) und so ein dummes Zeug...

Wenn ich ein Event aus irgendein Widget neuimplementiere, dann gehen die ihre ursprüngliche Funktion nicht mehr weil es sich nicht mit copy&paste identisch kopieren lässt.....[/quote]

Du _kopierst_ den Code der Basisklasse, wenn Du was neuimplementierst und die Basisfunktionalitaet auch haben willst?

Warum rufst in Deiner Neuimplementation nicht einfach die Implementation der Basisklasse auf?

Qt nimmt einem vieles ab, aber ein bisschen C++ braucht man schon.

Abgesehen davon gibt es Eventfilter. Teuer, erlauben aber ohne jegliches Modifikation der Widgets auf Events zu reagieren, sie "anders" zu bearbeiten oder zu ignorieren.

also bitte... benutz visualstudio und .net. fertig. Alles andere is geknaubt und unprofessionell.

Scorcher24

Ich kann mich mit QT auch nicht anfreunden. Oft probiert.
Aber der Metakompiler und diese aufgezwungene Projekt-Datei machen das ganze für mich uninteressant. Ist mir zu viel rumgemurkse.
Ich hab letztens erst probiert einen Sizer so einzubauen im Editor, dass er mit dem Fenster wächst. War mir nicht möglich. Mag an meiner Unkenntniss liegen, aber wxWidgets ist da deutlich einfacher und intuitiver gestrikt.

Scorcher24 schrieb:

Ich hab letztens erst probiert einen Sizer so einzubauen im Editor, dass er mit dem Fenster wächst. War mir nicht möglich. Mag an meiner Unkenntniss liegen...

Ja, daran wirds liegen
Für sowas gibts layout, welche in Qt gut umgesetzt sind.

Scorcher24 schrieb:

... und diese aufgezwungene Projekt-Datei machen das ganze für mich uninteressant.

Das ist doch gerade der Clou, um unabhängig von der IDE eine verständliche Projekt-Datei zu haben, die sich vernünftig in einer Softwareverwaltung pflegen lässt. Damit ist die Softwaregenerierung deutlich nachvollziehbarer, was für Software-Releases ein absolutes muss ist. Ich für meinen Geschmack gehe noch weiter und nutze auch für reine QT-Projekte cmake.

Tyrdal

Scorcher24 schrieb:

und diese aufgezwungene Projekt-Datei

Häh? Welche aufgezwungene Projektdatei? Du kannst statt qmake auch CMake nehmen oder eine eigenes Makefile schreiben oder alles von Hand in VS definieren oder, oder ...

RHBaum

oder, oder ... das qt VS Addin verwenden ...

Alle GUI Bibliotheken machen irgendwo nen Spagat zwischen Performance, Usability und Conformität ... Und die GUI bibs unterscheiden sich meist nur welche der Philosophien sie bevorzugen, mit den Konsequenzen in den anderen bereichen.

Das wegen sollte es fuer einen programmierer nicht DIE GUI-Bibliothek geben, sondern er sollt nach Vorgaben des Projectes die best geeignetste auswaehlen. Und das ist ned einfach

Was mir an qt z.b. nicht gefaellt:
- QBbjecte die automatisch geloescht werden, irgendwann (da kann ich gleich GC's nehmen)
- Impliziet sharing -> die QT Container verhalten sich nicht 100% vorhersehbar, macht grad in Multithreading Umgebungen aerger.
- keine versionierungen in den dll namen ... damit werden qt dlls nur lokal problemlos einsetztbar -> jedes programm isntalliert erst mal zig Megabytes mit -> widerspruch zur dll - Philosophie
- kein 100% statisches linken möglich (also auch die M$ runtimes statisch)

Trotzdem ist die qt damit noch eine der besseren GUI bibliotheken

der groesste Vorteil:
Man baut halt sch.... schnell seine GUI's zusammen.

Das ganze hat auch nen positiven effekt. Da ich so viel wie möglich qt frei haben will, trenn ich Immer Logic und GUI schicht, und zwar recht sauber ...

Ciao ...

RHBaum schrieb:

- QBbjecte die automatisch geloescht werden, irgendwann (da kann ich gleich GC's nehmen)

QObjects werden nicht irgendwann einfach gelöscht, sondern eindeutig nachvollziehbar.

RHBaum schrieb:

- kein 100% statisches linken möglich (also auch die M$ runtimes statisch)

Also mit mingw ist das definitiv möglich.

RHBaum

QObjects werden nicht irgendwann einfach gelöscht, sondern eindeutig nachvollziehbar.

Theorethisch weisst du es, aber praktisch "solltest" DU das wissen nicht verwenden ! Besonders nich, wenn die Teile mit deleteLater rausgenommen werden.

Wenn ich den Aufbau eines GC's kenne, kann ich auch vorraussehen, wenn ein Object geloescht wird. Aber auch hier sollte ich das Wissen nicht verwenden ...

Also mit mingw ist das definitiv möglich.

Also ich meine nicht Dein Project. Klar, das kannst statisch gegen die QT und statisch gegen die runtime linken. Nur iss das quasi witzlos, weil die statisch gebaute qt immer noch gegen die dynamische runtime linkt.
DU musst also die statische Qt auch auf die statische runtime verweissen lassen.
Und da steht in der Doku ausdruecklich, das man das nicht machen sollt

Schoen wenn es fuer die mingw geht, fuer den msvc gehts nicht (2005 SP3 + 4.6.4).

Ciao ...

ScyllaIllciz

@RHBaum
Natürlich geht das auch mit dem msvc200xx Compiler. Dazu muss man nur im mkspec folgende Änderung vornehmen:
original:

QMAKE_CFLAGS_RELEASE    = -O2 -MD
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MD -Zi
QMAKE_CFLAGS_DEBUG      = -Zi -MDd

andern zu:

QMAKE_CFLAGS_RELEASE    = -O2 -MT
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MT -Zi
QMAKE_CFLAGS_DEBUG      = -Zi -MTd

und schon ist das Binary alleine lauffähig auf allen PC's.
Ich benutze das schon lange so. Das einzige lästige ist, dass man alles selber kompilieren muss

RHBaum

Welche Version der Qt ? Welche Lizenz ? Pro oder die LGPL version ?
Bei mir hat eben genau dieses geknallt ...
Und ich hatte ne Supportanfrage deswegen bei Digia Mit eben der Antwort: statisch linken = nicht unterstützt
war glaub ich die 4.6.1 oder so, wo ich es versucht hab ...

Ciao ...

ScyllaIllciz

Ich benutze die LGPL Version. Statisch linken benutze ich bestimmt scon seit mindestens Version 4.3. Das wichtigste war immer die Anpassung der mkspec Datei um die Abhängigkeit der msvc Runtime Libs Weg zu bekommen! Statisch linken benutze ich aber nur Haus intern, nicht für Endprodukte. Für Endprodukte gibt es einen Installer mit allen notwendigen Libs.

RHBaum

Ich bräuchte es fuer paar tools.
Man glaubt gar ned, was "verzeichniss kopieren und exe darin starten" und "exe kopieren und starten" beim user fuer unterschiede machen
Aber grad die runtimes sind immer kritisch. Bei manchen werden die updates ausgespult, bei manchen nicht -> aerger.
Für distributierte Software klar, kommt nen Installer(mit runtime check und isntall) zum Einsatz.

Ciao ...

Softwaremaker

Man glaubt gar ned, was "verzeichniss kopieren und exe darin starten" und "exe kopieren und starten" beim user fuer unterschiede machen

Um eine exe zu bekommen packe ich die Dateien in ein 7zip-Archiv und verbinde es mit dem Selbstentpacker (7zS.sfx, nicht im Standard-7zip-Download!).
Dann ist es eine exe und extrem gut komprimiert, beim Starten entpackt er alles in ein temporäres Verzeichnis und startet die exe. Klappt sehr gut, wenn das Programm nichts speichern muss.

Kommt drauf an, besser bzw schlechter ist mir zu Schwarz und Weiß.

Mit Qt kommt mann in einigen Dingen schnell ans Ziel.

Was mir nicht gefällt sind zum Beispiel die Containerklassen, wirken ziemlich überladen. Auch andere Dinge sind überladen.

Und ab und an sitzt mann vor einem Problem was unerklärlich scheint, gerade bei stored Procedurs. Einmal ist alles I.O. und im gleichen Kontex gibts bei anderen Dingen Probleme. Das sind dann die Dinge die einem den Nerv rauben.

Kleine Programme gehen mit Qt recht Fix, alles was größer ist wird mit Qt zum Gedultsspiel.

Wenn Plattformunabhängigkeit wichtig wäre würde ich zu Qt greifen solgane es keine DB Anwendung ist. Oft ist aber der Browser mit einer Web App die bessere Wahl. Plattformunabhängigkeit wird selten wirklich benötigt und teuer erkauft.Die meisten Firmen arbeiten mit Windws Clients. Sollten da ein paar Mac Books bei sein, kann mann auch eine Terminalsitzung verwenden oder wie gesagt Web App.

My Way:

-kleine Dinge Qt
-das meiste mit MFC
-Plattformunabhängig = Silverlight
-Web ASP.Net / WPF Webanwendung Firmenintern

ScyllaIllciz

My Way:

-kleine Dinge Qt
-das meiste mit MFC
-Plattformunabhängig = Silverlight
-Web ASP.Net / WPF Webanwendung Firmenintern

Wenn ich die Wahl habe zwischen MFC und Qt, dann hat Qt einen Vorsprung um Faktor 1000 ;-). MFC ist einfach nur eine Katastrophe, leider bei uns in der Firma noch standard aber das wird gerade geändert

besser bzw schlechter ist mir zu Schwarz und Weiß.

besser/schlechter ist eine Abwägung zwischen verschiedenen Übeln und eigenen Anforderungen. Unbrauchbar/das einzig Wahre wäre schwarz/weiß.

Was mir nicht gefällt sind zum Beispiel die Containerklassen, wirken ziemlich überladen. Auch andere Dinge sind überladen.

Und was findest du an denen überladen?

Und ab und an sitzt mann vor einem Problem was unerklärlich scheint, gerade bei stored Procedurs. Einmal ist alles I.O. und im gleichen Kontex gibts bei anderen Dingen Probleme. Das sind dann die Dinge die einem den Nerv rauben.

Wenn man nach Problemen mit "stored procedure Qt4" sucht, sind die meisten Sachen Anwendungsfehler, also falsche Queries. Hast du ein konkretes Beispiel, wo du alles richtig gemacht hast, aber trotzdem Probleme auftraten?

-Plattformunabhängig = Silverlight

WTF?!? Was ist daran plattformunabhängig? Das gibt es nur für Win+Mac, Novel darf eine abgespeckte Version als "Moonlight" anbieten, ist aber immer noch proprietär und auf den wenigsten Kisten installiert. Wer WIRKLICH plattformunabhängig sein will (weil er möglichst viele Kunden bedienen will/muss) greift zu wirklich plattformunabhängigen Lösungen, die da sind Terminal-Anwendungen in reinem C/C++ OHNE WinAPI usw., bei GUIs eben Toolkits ala Qt/wxWidgets/GTK[mm]/... Aber eben NICHT so ein verkrüppeltes Webbrowser-Addin-Silverlight-Dingens...

Softwaremaker

My Way:
-kleine Dinge Qt
-das meiste mit MFC
-Plattformunabhängig = Silverlight
-Web ASP.Net / WPF Webanwendung Firmenintern

Also dass du MFC (gerade bei großen Dingen) dem Qt vorziehst kann ich nicht verstehen. Ich habe jahrelang nur mit MFC gearbeitet, man bekommt ja auch sehr schnell kleine Sachen hin, nur gerade wenn das Projekt größer wird und Sachen wie i18n realisiert werden sollen, Bilder verschiedenster Formate geladen und manipuliert werden sollen (nicht über OLE), dann muss man 3th-party-Bibliotheken einbinden (z.B. CxImage).
i18n mittels Resource-DLLs finde ich total umständlich, Dritte (nicht-Programmierer) können eine Übersetzung kaum durchführen und gute Resource-Editoren gibts nicht kostenlos (ResourceHaker ist ok und kostenlos, kann aber bestimmte Dinge nicht, z.B. feste Texte in ComboBoxen, muss man also als StringResource realisieren und dynamisch die CmbBox füllen). Ändert man die Oberfläche im Programm, dann läuft das neue Programm nicht mehr mit den alten Resource-DLLs.

Da ist der wx/Qt-Weg besser, PoEdit/QtLinguist sind kostenlos und Dritte können problemlos übersetzen. Neues Programm funktioniert auch mit alten Sprachdateien.
Die Qt-Container-Klassen finde ich sehr gut gemacht (ist ja wie bei MFC, nur flexibler), da bei Qt in einem Container auch Container verwendet werden können, bei MFC muss man Ableiten und CreateElement,Copy,... realisieren.
Skinning und Oberfläche verändern (andere Designs) geht bei MFC mit den Boardmitteln nur begrenzt und sehr aufwendig, bei Qt geht das super einfach ohne Programmänderungen mittels StyleSheets.
Ich mache mit MFC nichts mehr, da es mit dem Qt-Creator in Qt bei kleinen Dingen genauso schnell und einfach klappt wie bei VS/MFC und wenns komplexer wird Qt für mich viel besser ist.

Sonja Saubertochter schrieb:

Wer WIRKLICH plattformunabhängig sein will (weil er möglichst viele Kunden bedienen will/muss) greift zu wirklich plattformunabhängigen Lösungen, die da sind Terminal-Anwendungen in reinem C/C++ OHNE WinAPI usw., bei GUIs eben Toolkits ala Qt/wxWidgets/GTK[mm]/... Aber eben NICHT so ein verkrüppeltes Webbrowser-Addin-Silverlight-Dingens...

Der Vorteil einer Terminalsitzung ist, dass es egal ist welche API / OS am Terminalserver arbeitet. Warm sollte ich ein Programm was auf einem Terminalserver läuft ohne Winapi entwickeln?

Und wo ist wirklich Plattformunabhängigkeit wichtig? Wo gibt es Firmennetzwerke die Linux als Client verwenden ? Seltenst Mac. Der Webbrowser oder Terminalsitzung sind da die besten Schnittstellen.

Mobile / Embeddet, da ist derzeit c++ nicht die beste Wahl. Und auch hier ist der Browser wieder die beste Schnittstelle.

Qt nicht überladen? Qtlist Operator[] ?

ODBC MSSQL und Qt sind Dinge die nicht zusammenpassen bzw auch nur rudimentär supported wird. Wer natürlich seine DB ohne Sp´s baut ( warum auch immer) könnte Qt verwenden um mal schnell eine Tabelle zu Mappen. Mit stored Prozeduren Chancenlos.

Spätestens wenn man versucht von einem Linux Client mit einem plattformunabhängigen QT Client auf einen MS SQL oder Oracel zuzugreifen stellt man fest, dass der Browser oder eine Terminalsitzung der beste Weg ist.

Dean schrieb:

Der Vorteil einer Terminalsitzung ist, dass es egal ist welche API / OS am Terminalserver arbeitet. Warm sollte ich ein Programm was auf einem Terminalserver läuft ohne Winapi entwickeln?

Wir reden aneinander vorbei. Terminal == Konsole == "TUI" - zwar bietet die WinAPI nette Funktionen zum Formatieren, wer plattformunabhängig bleiben will sollte es wenigstens gut wegkapseln.
Mehr wollte ich nicht sagen. Eine Client-Anwendung für einen Terminalserver meinte ich nicht.

Und wo ist wirklich Plattformunabhängigkeit wichtig? Wo gibt es Firmennetzwerke die Linux als Client verwenden ? Seltenst Mac. Der Webbrowser oder Terminalsitzung sind da die besten Schnittstellen.

Das interessiert hier doch gar nicht! Ich sage "Wer plattformunabhängig will" und du meinst "wo ist das interessant" - völlig andere Diskussion.

Mobile / Embeddet, da ist derzeit c++ nicht die beste Wahl. Und auch hier ist der Browser wieder die beste Schnittstelle.

Browser + Addin + (gescriptete?) Software sind besser als ein dünnes C++-Programm?

Qt nicht überladen? Qtlist Operator[] ?

QList ist nicht das ws du meinst -> Doku.
QList ist was spezielles, wenn du std::list meinst -> QLinkedList.

ODBC MSSQL und Qt sind Dinge die nicht zusammenpassen bzw auch nur rudimentär supported wird.

Aha! Du verallgemeinerst die Kombi "ODBC MSSQL Qt Stored Procedure" in ein "Qt Stored Procedure".
Ich hatte bisher noch nichts mit MS SQL zu tun - vllt. liegts daran.
Da dir aber auch die Funktionsweise von QList nicht bekannt ist, denke ich du bist nie wirklich tiefer in Qt eingestiegen, könnte also auch ein Anwendungsfehler sein...