Wer nutzt von euch Qt?

Julian__

ich nutze auch Qt, beruflich und privat.
allerdings bin ich - anders als viele hier - durch die privat angeeignete Qt-kenntnis erst an meinen job gekommen.

privat verkaufe ich mein zeugs nicht, also ist mit die (l)gpl absolut recht.
beruflich muss sich mein chef damit rumschlagen ...

alles in allem, bin ich mit api und unterstuetzten plattformen, sowie lizenzen sehr, sehr zufrieden. habe aber auch noch nichts wirklich groesseres mit gtk/wxwidgets/anderen vergleichbaren frameowkrs gemacht.

mfg
julian

Nehmen wir mal an, ich finde eine Anwendung die Qt nutzt und statisch linkt, aber keine Lizenz vorweisen kann. Darf ich die dann anschwärzen? Wenn ja, wo und wie?

Cefour

Inwiefern willst du jemanden anschwärzen. Soweit ich verstanden habe, darfst du wenn du die Kommerzielle Lizens von Qt kaufst, statisch linken. Des Weiteren musst du auch kein Hinweis drauf geben, das du QT verwendest. Weiterhin wie ich die Lizens verstanden habe, darf man sogar den Source von QT verändern ohne an Nokia diese Änderungen mitzuteilen.

Und wenn du jemanden anschwärzen willst, setz dich mit Nokia zusammen. Die helfen bestimmt einen weiter.

Ich bin selbst über wxWidegts zu QT gekommen. Finde QT ist das klar mächtige Framework, aber wxW hat auch seine Vorteile. Vorallem finde ich das wxW eine einfachere Methode entwickelt hat um Controlls zu positioneren als QT.

Aber QT ist brauchbar, schnell und sehr gut dokumentiert

zwutz schrieb:

wer entwickelt heute noch freiwillig in der MFC? Vor allem, wenn er Qt als Alternative bereitliegen hat? oO

Ich bin mit Qt auch durch die Arbeit zuerst in Kontakt gekommen. Seitdem nutze ich es auch privat, auch wenn ich fast ausschließlich für Windows entwickle (zumindest daheim).
wxW erinnert mich zu sehr an die MFC

Wie man hier im Forum sieht gibt es sehr viele die noch mit MFC oder sogar WinAPI entwickeln. Nur weil es irgendeine Möglichkeit gibt etwas "leichter" zu realisieren heisst das nicht das Jeder das auch so nutzt oder benutzen möchte. Wer z.B. die WinAPI zu seinem Freund gemacht hat der programmiert auch weiterhin damit, weil es für ihn einfach weniger Aufwand bedeutet als sich in ein neues Framework einzuarbeiten.

Und auch nicht jeder programmiert Killerapplikationen die so ein großes Framework wie Qt rechtfertigen. Für Standardsachen wie Menus Toolbox standard Controls Statusleiste etc. reichen alles Frameworks und APIs locker aus wenn es im normalen Rahmen bleibt. Da reicht sogar WinAPI nur mit C oder Assembler für aus.

Ich habe z.B einen Freund der programmiert immer noch per Emulator auf 68000er Assembler weil er halt nix anderes lernen möchte, wäre mir auch zu krass aber er hat Spaß dran und bekommt das hin was er haben möchte.

Aber das kann man hier endlos fortführen, es gibt mit Sicherheit eine million Gründe warum Leute nicht immer die aktuellsten Technologien einsetzen. Viele sind noch nicht mal bei OOP angekommen. Es gibt halt nix was es nicht gibt.

zwutz

WinApi seh ich ja ein, Assembler auch. Aber MFC? Klar, bestehende Projekte müssen gepflegt werden und einige "Urgesteine" haben auch sicher ihren Spass daran und müssen wegen mir nix neues lernen

Aber ich versteh wirklich nicht, wie jemand zwar mit Qt (und ähnlichen) programmieren kann und dann trotzdem MFC für neue Projekte verwendet. Wirklich nicht. Oder hat MFC irgendwelche gravierenden Vorteile, von denen ich nichts weiß?

Artchi

zwutz schrieb:

Oder hat MFC irgendwelche gravierenden Vorteile, von denen ich nichts weiß?

Die MFC wird nunmal von MS vorbildlich gepflegt und für jede Windows-Version die Features aktuell gehalten. Bevor die C#- oder WPF-Fraktion die Ribbons bekamen, wurden die MFC-User zuerst mit Ribbons versorgt. Daran sieht man, welcher Kunde bei MS immer noch die höchste Prio genießt. Klar sind die Konzepte hinter der MFC nicht umgebaut worden. Mir ist da bis heute einiges an der MFC unbegreiflich. Aber wer speziell für Windows programmieren will, ist mit der MFC mit am besten bedient. Er ist einfach mit am Ball.

Dafür haben die WPF u.a. natürlich andere Vorteile. Aber das Ribbons-Beispiel zeigt trotzdem wo der Hammer in der Windows-Welt hängt.

zwutz

wollte MS die MFC nicht einstampfen? Ich denke, die Änderungen an der MFC kommen nur deshalb so flott, weil man sie recht leicht aus der WinApi übernehmen kann. Und da kommen die neuen Funktionen prinzipbedingt als erstes

Tyrdal schrieb:

Außerdem hat man den Source.

Schon wieder so eine Aussage. Bei Qt hast du auch ohne diese Lizenz den Sourcecode.

Qtianer schrieb:

Tyrdal schrieb:

Außerdem hat man den Source.

Schon wieder so eine Aussage. Bei Qt hast du auch ohne diese Lizenz den Sourcecode.

Anscheinend habe ich den Kontext nicht richtig verstanden! Sorry!

Artchi

zwutz schrieb:

wollte MS die MFC nicht einstampfen? Ich denke, die Änderungen an der MFC kommen nur deshalb so flott, weil man sie recht leicht aus der WinApi übernehmen kann. Und da kommen die neuen Funktionen prinzipbedingt als erstes

Nein, wollten sie nicht einstampfen. Das ist ein Gerücht, das nie von den Gerüchtestiftern belegt werden konnte.
Und nein, die Ribbons u.ä. sind NICHT in der WinAPI enthalten. Das sind alles eigene Komponenten, die MS sogar teilweise einkauft. Und auch der Ribbons-Editor (wo man seine Ribbonfenter zusammen stellt) sind sicherlich nicht schnell mal aus der WinAPI im MSVC abgebildet.
Klar ist MFC hauptsächlich ein Wrapper. Aber sicherlich nicht für alles.

zwutz schrieb:

wollte MS die MFC nicht einstampfen? Ich denke, die Änderungen an der MFC kommen nur deshalb so flott, weil man sie recht leicht aus der WinApi übernehmen kann. Und da kommen die neuen Funktionen prinzipbedingt als erstes

Da wird nix eingestampft auch Windows 7 basiert auf WinAPI und das wrappt die MFC. Ohne diese beiden Technologien zu kennen sollte sich keiner Windows-Programmierer nennen dürfen.

Tyrdal schrieb:

Was ist an 3000€ ein hoher Preis? Man bekommt auch viel mehr als mit der MFC (vor allem Portabilität!)

Ich nutze es auch in der Firma, wegen der Portabilität und einfachen Nutzbarkeit. Wenn man es kommerziell nutzt kann man auch mal Support und solche Sachen in Anspruch nehmen. Außerdem hat man den Source. Wenn man also mal irgendein Verhalten nicht nachvollziehen kann, kann man wenigstens nachsehen warum das so ist wie es ist. Und gegenüber wxWidgets hat es den massiven Vorteil nicht nach MFC auszusehen.

Da hab ich ja ne Diskusionsrunde angestupst ^^.

Portabilität bei Qt ja, allerdings wie bei jedem Portablen Set muß der Umfang auf den kleinsten gemeinsammen Nenner der Plattformen gebracht werden.

3000.- ist hoch im Vergleich zu 280.- fürs VS Studio mit MFC.

Die LPGL Lizenz ist abgespeckt, GPL setzt GPL Entwicklung voraus.

Hier in dem Forenbereich wird die MFC im als auslaufender alter Hut abgestempelt, und das ist so nicht richtig. Für das Windowsumfeld immer noch das beste Toolset mit einer spitzen IDE.

Ich will nicht behaupten Qt währe schlecht, im Gegenteil.

Das mit den Toolsets auch ein wenig wie mit den Programmiersprachen und den Diskusionen dazu, es gibt keine beste, es gibt Problemstellungen und Sprachen / Toolsets womit man die Probelmstellung besser lösen kann.

Ist die eine der Gegebenheiten Plattformunabhängigkeit währe meine erste Wahl Qt, im Windowsumfeld immer MFC.

Zum Thema Plattformunabhängigkeit, wieviel Netzwerke gibt es den wo Linux als Client genutzt wird? Und da wo Äpfel im Netz mit sind, sind das in der Regel
einzellne Creativ Bereiche die selten das volle Netzwerk nutzen.
Hier sollte mann genau prüfen ob man die Portabilität braucht, oft geht man dafür auch Kompromisse ein. Gerade bei MS SQL der nicht selten anzutreffen ist.

Sind das Projekte wie Skype oder ein Browser sieht das schon anders aus, aber wer sitzt den wirklich an solchen Projekten die auch in dem Umfang genutzt werden? In der Regel werden für solche Projekte eigene Toolsets entwickelt, aus denen dann ja auch Dinge wie QWebView hervorgehen.

Und wie schon erwähnt MFC ist vom Lernaufwand extrem gegenüber anderen, ich kann jedem der zu der "Ich sag auch mal das MFC alt ist weil ich das irgendwo gelesen hab" Fraktion gehört mal MFC auszuprobieren und das Konzept zu verstehen.

l'abra d'or

Zooonk schrieb:

Portabilität bei Qt ja, allerdings wie bei jedem Portablen Set muß der Umfang auf den kleinsten gemeinsammen Nenner der Plattformen gebracht werden.

Das versteh ich jetzt nicht. Qt macht viel mehr als auf X11 angeboten wird, das Model/View-Framework ist was ganz eigenes, genauso wie das GraphicsView-Framework. Ein Blick in Richtung QML/Qt-Declarative verschärft das ganze noch mehr, da so etwas in der jeweiligen Basis der Plattformen (somit auch nicht im gemeinsamen Schnitt) auch nicht implementiert ist.

Die LPGL Lizenz ist abgespeckt, GPL setzt GPL Entwicklung voraus.

Eigentlich haben die die LGPL um eine Ausnahme erweitert, so dass es mit den Macros und templates keine Probleme gibt.

In der Regel werden für solche Projekte eigene Toolsets entwickelt, aus denen dann ja auch Dinge wie QWebView hervorgehen.

Kennst du den Pfad in Richtung QtWebKit? Der ist arg verschlungen. Seine Ursprünge hat der in kde! KHTML hieß die Engine. Apple gefiel das so gut, dass sie es als Basis für ihren Safari genommen haben. Deren Patches waren wohl so umfangreich und teilweise kaum auf den KHTML anwendbar. Irgendwann hat sich ein eigenes Projekt daraus entwickelt - WebKit. QtWebKit ist nur die Qt-Integration.
Der Grund für QtWebKit ist nicht so einfach "ich schreibe einen Browser und brauche dafür eine Engine".

Tyrdal

3000.- ist hoch im Vergleich zu 280.- fürs VS Studio mit MFC.

Ich kann dir auch ein VS zu 14000€ rasussuchen (http://www.hottools.de/d/produkte/visualstudio.html ganz unten)

Die MFC bietet zu dem geringerem Preis wie gesagt auch weniger, schon allein wegen fehlender Portabilität. Und die 3000€ für QT sind weniger als mein Bruttomonatslohn. Wenn man mehr als ein "Hello World" Projekt macht geht das im Rauschen der Kosten unter.

Artchi

Lächerlich diese Preise! Wir haben hier gerade an den Einkauf eine Bestellung für eine Java-Komponente für 17.000 EUR aufgegeben, als Konzernlizenz. Und vor Jahren haben wir von einer Schweizer Uni eine Java-Crypto-Komponente für 100.000 EUR gekauft.

Da sind die 3000 EUR für Qt ein Witz! Könnte lediglich nicht mehr witzig sein, wenn man 1000 Developer hat! Und 200 oder 300 EUR für MSVS sind hinter her geschmissen, wenn man bedenkt, das da nicht nur MFC, sondern viel mehr dabei ist.

Ach ja, das MFC nicht portabel ist, ist für jemanden der für Windows entwickelt ziemlich unwichtig.

Artchi

Tyrdal schrieb:

Ich kann dir auch ein VS zu 14000€ rasussuchen (http://www.hottools.de/d/produkte/visualstudio.html ganz unten)

Das ist aber ein MSDN Abo für 2 Jahre. Da bekommst du die ganzen Server-Produkte, Windows-Betriebssysteme, das MS-Office u.a. MS-Produkte für Entwicklung und Test dazu! Das MS-Office sogar zur produktiven Nutzung. Nicht nur das MSVS. Das ist ein ganz anderes Angebot als Qt.
Ich hatte auch mal privat ein kleines MSDN Abo, und jeden Monat hatte ich die neuesten Versionen aller MS-Produkte auf DVDs in meinem Briefkasten. Alle Windows-Versionen in allen Sprachen, alle Server usw.

Wer voll in die professionelle Windows-Entwicklung einsteigen will, und den globalen Markt bedienen will/muß, sollte ein MSDN-Abo haben.

Was ist an Qt Portabel ?

Laut Qt WebPage wird MS Sql mit ODBC unterstützt, wird aber nicht mitinstaliert unter Linux, unter MAc auch nicht.
Der UnixODBC unterstützt weder NativeClient noch dessen Funktion.

Instalation unter Suse ist der Megagau, gerade in Bezug auf SQL Plugins(2 Tage den Bach runter), auch unter Mac geht nix out of the Box, selbst Visual Studio Plugin erfordert Aufwand.

Für solche rumbasteleien gehen etliche Stunden und Tage den Bach runter.

Einen Großteil kann mann eh auf den jeweilen Plattformen neu schreiben.

Visual Studio CD rein und los gehts , das verstehe ich unter einem fertigen Produkt, sollte das irgendwann bei Qt und Konsorten auch mal möglich sein werd ich nochmal drüber nachdenken und solange die "Plattformunabhängige" Entwicklung den Javas überlassen. Oder die sollen halt Wine nutzen.

zwutz

Strunzinatori schrieb:

Visual Studio CD rein und los gehts , das verstehe ich unter einem fertigen Produkt, sollte das irgendwann bei Qt und Konsorten auch mal möglich sein werd ich nochmal drüber nachdenken und solange die "Plattformunabhängige" Entwicklung den Javas überlassen. Oder die sollen halt Wine nutzen.

Wieso? SDK herunterladen, installieren und es kann ebenfalls sofort losgehen. Solang nichts plattformspezifisches benutzt wird, läuft es ohne Änderungen auf jeder unterstützten Plattform. Hatte dahingehend bisher keine Probleme, selbst bei komplexerer Software

Qt SDk unter Windows ja.

Unter Mac, erst die Mac XCode Plattform installieren, vorher bei Mac Developper anemdelden .
Unter Suse der Megagau, in den Repros nicht das aktuelle Qt, SDK downloaden, installieren.
Es wird weder unter Mac noch unter Linux ein Sql Plugin oder Treiber erstellt ausser Sqlite.
Setup zeigt zwar an das Startmenüeinträge erstellt werden´, aber nix wird erstellt. Da Nur Sqlite als Sql Plugin erstellt wird, erfordert alles andere ein configure und co. Kompiliert das komplette Set durch, was halt dauert, danach findet man aber kein QWebKit mehr und anderes auch nicht, obwohl im Configure angegeben.
Dann wird das Toolset unter einem anderen Pfad erstellt QWebkit fehlt im neuen obwohl es mit angegeben wurde. Im Qt Creator lässt sich nur noch qt aus Pfad einstellen. Neverending Story.

Strunzinatori schrieb:

*Geschwaffel*

Bin selbst Suse-User und benutze Qt.