wxWidgets vs Qt

[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.

[Dean]

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

[Sonja Saubertochter]

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.

[Dean]

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.

[Sonja Saubertochter]

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...

[RHBaum]

Die Mfc hat aber auch Vorteile, sollte man nicht unerwaehnt lassen.

- Ich kann multithreaded direct auf die MessageQueues schiessen. unter QT, no way.
- Performancemaessig ist die Qt ziemlich ... naja sie ist sehr abstract. Eigene Queue ueber die nativen Windows Message-Queues. Aber wie scho gesagt, Performance spielt ned die absolute rolle.
- die MFC iss nur nen duenner Wrapper, die Winapi ist pures C. Bei Modularer Programmierweisse, also eigene Dlls mit C-Schnittstellen, tut man sich etwas leichter. Nen QString und nen QWidget linearisierst ned soo schnell wie nen Wrapper der um TChar und um HWND aufgebaut ist.

Wie gesagt, es kommt auf den anwendungsfall an.
Bei tools, zeugs was ich unter kontrolle habe, etc, nehm ich auch gern die QT. Weil performanceanforderung sind meist normal, also gering ... und es sind kaum Kollisionen zu erwarten.
bei "groesseren projekten" "kotzt" ich oft auch über die Qt Abhaengigkeiten.

Wir arbeiten mit der Main App auf Qt 4.6.1 ... und liefern unser Setup abgesichert auch mit den 4.6.1er qt dlls aus ... und das plugin vom zulieferer xyz will ploetzlich eine 4.6.4 ?

Arbeite mal in groesseren Modularen Projekten, dort wirst Du QT-Freiheit, überhaupt freiheit von jeglicher 3d. party dynamischen lib echt schätzen lernen.

Ciao ...

[jaf]

Dean schrieb: "My Way: -Plattformunabhängig = Silverlight"

Ich bin neugierig: Hast Du das schon mal _ernsthaft_ unter Linux versucht? [Moeglicherweise gar auf einer nicht-Novell-Distribution?]

[Dean]

Soweit mir bekannt ist, gibt es für Silverlight mit Linux auch eine Möglichkeit mit Moonlight. Unabhängig von Silverlight/MS gibt es da diverse Anbieter und unterschiedliche Web Frameworks.

Der Browser und ein Terminalsserver sind die besten Möglichkeiten in heterogenen Netzwerken Plattformprobleme zu lösen.

@Sonja Saubertochter Terminalserver != Terminalzugriff über SSH an einer Linux Kiste / TTY. Schau die mal Citrix oder MS TS an. Eine App mit Windows Api und über RDP oder vergleichbar wird eine Sitzung hergestellt. Auf dem Client muß quasi gar kein OS ( boottp ), ein Terminalserver Client muß vorhanen sein da reicht auch ein Thinclient, der Zugriff ist auch von Linux/Mac möglich. Ähnlich dem X Protokoll.

Und ja unabhängig der Qlinkedlist ist Qt einfach überladen, bei MFC liegt die Problematik weniger an der Arbeit mit der MFC als im Lernumfang und nicht oder kaum vorhandener Literatur.

[Dean]

Sonja Saubertochter schrieb:

Dean schrieb:

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?

C++ auf einem Smartphone?

RIM/Blackberry = Java (Micro Edition)
Android = java
WP7 = C#
Palm = Web OS / HTML 5
Symbian = noch C++ bald C# da es auf Nokia Handys durch WP7 ersetzt wird.
Apple IOS = Objektive c

Der Weg geht da ganz klar richtung Browser als Schnittstelle zwichen den Plattformen und Systemen. Ein Appp für alle Plattformen separat schreiben?

Das ist auch das was die PC Welt erwarten wird.

[firefly]

Dean schrieb:

Sonja Saubertochter schrieb:

Dean schrieb:

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?

C++ auf einem Smartphone?

RIM/Blackberry = Java (Micro Edition)
Android = java
WP7 = C#
Palm = Web OS / HTML 5
Symbian = noch C++ bald C# da es auf Nokia Handys durch WP7 ersetzt wird.
Apple IOS = Objektive c

Der Weg geht da ganz klar richtung Browser als Schnittstelle zwichen den Plattformen und Systemen. Ein Appp für alle Plattformen separat schreiben?

Das ist auch das was die PC Welt erwarten wird.

Android geht auch c++ mit dem Andorid NDK

[ScyllaIllciz]

Android geht auch c++ mit dem Andorid NDK

Ich habe hier auf meinem Android Smartphone Qt am Laufen

[Wurst]

Dean schrieb:

Der Weg geht da ganz klar richtung Browser als Schnittstelle zwichen den Plattformen und Systemen.
...
Das ist auch das was die PC Welt erwarten wird.

Ich finde solch subjektiven Prognosen einfach bescheuert.

@scheiss qt
Einen unqualifizierteren Namen hast du wohl nicht gefunden.

[Blubb]

Einfach mal, weil Qt so mies ist, und sowieso nur auf frickeligen Linux-Heimrechnern läuft:
http://blogs.kde.org/node/4474
Ich weiß auch schon, was jetzt von Dean kommt: Qt verbrät so viel Leistung, dass man ne riesige Kühleinheit braucht, um die CPU vorm Durchschmoren zu bewahren

[qt hasser]

Qt ist das mit abstand beste Framework, dass jemals von Menschenhand gebaut worden ist ...

Dank ausgeklügelten konzepten wie moc, wird der Makrowahn um noch eine Ebene höher geschraubt.

[Wurst]

qt hasser schrieb:

Qt ist das mit abstand beste Framework, dass jemals von Menschenhand gebaut worden ist ...

Dank ausgeklügelten konzepten wie moc, wird der Makrowahn um noch eine Ebene höher geschraubt.

Du musst es ja nicht nehmen, viele andere tun es gern und haben keine Problem den MOC zu verstehen und zu gebrauchen.

[ScyllaIllciz]

Ich verstehe das ganze "moc ist scheiße" gar nicht. Ich habe mir noch nie Gedanken darüber machen müssen, weil alles reibungslos funktiert. Was soll das also. Nehmt Qt oder laßt es! Ich will auf Qt nicht verzichten, weil es (für mich) keine vernünftige Alternative gibt.