wxWidgets vs Qt

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

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?]

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.

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

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.

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

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.

ScyllaIllciz schrieb:

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.

Schonmal versucht verschachtelte Q_OBJECT- Klassen zu verwenden? Wird nicht klappen Bin noch recht neu in Qt, wusste das nicht und brauchte eine geschachtelte Klasse. Stattdessen musste ich das ganze durch friend-class-rumgemurkse loesen...

Irgendwo in der Qt-Dokumentation gibts eine fette Liste an Beschraenkungen, die man durch den moc hat. Das ist dann schon wirklich kein echtes C++ mehr und genau deswegen regen sich viele (einschl. mir) auf.

ChuckNorris schrieb:

wusste das nicht und brauchte eine geschachtelte Klasse. Stattdessen musste ich das ganze durch friend-class-rumgemurkse loesen...

Was hat "geschachtelte Klasse" mit "friend" zu tun?!? Wenn du den Zugriff der einschließenden Klasse auf private/protected-Elemente der eingeschlossenen Klasse meinst, muss ich dich an den Standard verweisen:

11.8 Nested classes
1
[class.access.nest]
The members of a nested class have no special access to members of an enclosing class, nor to classes or
functions that have granted friendship to an enclosing class; the usual access rules (clause 11) shall be
obeyed. The members of an enclosing class have no special access to members of a nested class; the usual
access rules (clause 11) shall be obeyed. [Example:
class E {
  int x;
  class B { };
  class I {
    B b;                // error: E::B is private
    int y;
    void f(E* p, int i)
    {
      p->x = i;         // error: E::x is private
    }
  };
  int g(I* p)
  {
    return p->y;        // error: I::y is private
  }
};
—end example]

Du wirst also auch bei nested classes nicht um friend herum kommen.

Irgendwo in der Qt-Dokumentation gibts eine fette Liste an Beschraenkungen, die man durch den moc hat. Das ist dann schon wirklich kein echtes C++ mehr und genau deswegen regen sich viele (einschl. mir) auf.

"fette Liste" ist arg übertrieben. Assistant aufmachen, "moc" suchen, Unterpunkt "limitations". Sind 7 Punkte, von denen mir persönlich bisher noch keiner in die Quere gekommen ist.

Zu deiner Aussage:

Schonmal versucht verschachtelte Q_OBJECT- Klassen zu verwenden? Wird nicht klappen

Das ist arg verallgemeinert, vielmehr sagt die Doku:

Nested Classes Cannot Have Signals or Slots

Ein "nested QWidget" mit selbst überschriebenen virtuellen Funktionen -> geht.
Ein QObject mit properties -> geht.
Es werden eben auch keine bereits in der Basisklasse existierenden Signals/Slots weggeschnitten.

no friend schrieb:

ChuckNorris schrieb:

wusste das nicht und brauchte eine geschachtelte Klasse. Stattdessen musste ich das ganze durch friend-class-rumgemurkse loesen...

Was hat "geschachtelte Klasse" mit "friend" zu tun?!? Wenn du den Zugriff der einschließenden Klasse auf private/protected-Elemente der eingeschlossenen Klasse meinst, muss ich dich an den Standard verweisen:

Seltsam. Ich hab mir den Standard zwar noch nie durchgelesen, aber ich hatte schwoeren koennen, dass das problemlos geht ...
Trotzdem zeigt folgender Test, dass ein Zugriff unter gewissen Umstaenden trotzdem moeglich ist (getestet mit QtSDK-MinGW und MSVC10):

...

class A
{
public:
	A(int h) : a(h) {}
private:
	int a;
	class B
	{
	public:
		int Geta(const A& a) const
		{
			return a.a;
		}
	};
public:
	int Geta() const
	{
		B b;
		return b.Geta(*this);
	}
};

int main(int argc, char** argv)
{
	QApplication app(argc, argv);

	A a(2);
	int test = a.Geta();

	...
}

ChuckNorris schrieb:

Trotzdem zeigt folgender Test, dass ein Zugriff unter gewissen Umstaenden trotzdem moeglich ist

Deine "gewissen Umstände" sind "B::Geta() ist public" - also nichts aufregendes, kein Hack oder etwas weswegen man "friend" bräuchte. OK, class A::B ist private, aber von außen greifst du ja nicht drauf zu und A hat auf alles "in sich" Zugriff, auch auf private Member oder auf private nested classes.

no friend schrieb:

ChuckNorris schrieb:

Trotzdem zeigt folgender Test, dass ein Zugriff unter gewissen Umstaenden trotzdem moeglich ist

Deine "gewissen Umstände" sind "B::Geta() ist public" - also nichts aufregendes, kein Hack oder etwas weswegen man "friend" bräuchte. OK, class A::B ist private, aber von außen greifst du ja nicht drauf zu und A hat auf alles "in sich" Zugriff, auch auf private Member oder auf private nested classes.

A::B hat dann ja aber auch Zugriff auf die privaten Member von A anscheinend. Das waere eben sonst nur mit friend moeglich.
Uebrigens funktioniert das ganze auch, wenn du A::B public machst.
Dass heisst, es wuerde dann auch folgendes gehen:

A a(4);
	A::B b;
	int test = b.Geta(a);

Obwohl A::a privat ist.
Widerspricht das nicht dem Text-Auszug aus dem Standard?
Bin jetzt etwas verwirrt.

Bei meinem Problem damals ging es um folgendes:
Ich hatte eine QWidget-Klasse und brauchte eine kleine QThread-Klasse, die ich auch nur fuer diese QWidget-Klasse brauchte (und auch nur innerhalb der QWidget-Klasse). Um herauszufinden, wann der Thread beendet wurde brauchte einen Slot fuer das Signal finished() (deswegen war ja auch keine geschachtelte Klasse moeglich). In diesem Slot habe ich dann eine private Variable von der QWidget-Klasse aendern muessen.
Das ganze waere dann wohl anstatt friend auch mit einer geschachtelten Klasse moeglich gewesen, wenn moc es nicht verbieten wuerde.