Hallo, ich entwickle schon seit längerem an einer Bauteile-Verwaltung, die ich auch euch mal zur Verfügung stellen will (kann aber noch etwas dauern). Zuerst habe ich in C# programmiert, in der Hoffnung, mit Mono würde es auch unter Linux und Co. laufen. Es klappte zwar, aber man musste teils über viele "Umwege" programmieren, was das ganze recht unübersichtlich macht. Auch in Sachen Performance ist Mono manchmal nicht ganz so optimal. Dann stieg ich auf JAVA um, doch die Zukunft von Java ist ja auch sehr verwirrend. Ich habe die Sache jetzt nicht ganz genau verfolgt, aber seit der Übernahme scheint es ja nur noch Ärger zu geben. Von daher wollte ich mal Fragen, welche Programmiersprache ihr momentan zur Entwicklung plattformunabhängiger Software empfehlen würdet. Ich weiß, C mit entsprechenden Frameworks geht auch, aber momentan traue ich mir noch keine C-Programme für Windows zu, von daher würde ich das gerne mal außen vor lassen. Über was ich noch nachgedacht habe, wäre die Software als Web-Interface zu programmieren. Als Interface würde ich dann qooxdoo nutzen, darin bin ich recht fit und sieht ja auch fast wie ein Desktop aus. Würde gerne mal eure Meinung dazu hören :) Viele Grüße Julian
Julian W. schrieb: > Dann stieg ich auf JAVA um, doch die Zukunft von Java ist ja auch sehr > verwirrend. Ich habe die Sache jetzt nicht ganz genau verfolgt, aber > seit der Übernahme scheint es ja nur noch Ärger zu geben. Wieso sollte das die "Sprache" Java nicht "zukunftsfähig" machen? Wenn du auf Nummer sicher gehen willst, kannst du natürlich gegen die OpenJDK programmieren, aber das "Sun"-Java wird auch in Zukunft bestehen. Julian W. schrieb: > Über was ich noch nachgedacht habe, wäre die Software als > Web-Interface zu programmieren Hat natürlich auch Vorteile, würde dann aber auf irgendwas wie PHP+MySQL gehen das ist recht verbreitet und du bist nicht auf JS angewiesen.
Läubi .. schrieb: > Julian W. schrieb: >> Dann stieg ich auf JAVA um, doch die Zukunft von Java ist ja auch sehr >> verwirrend. Ich habe die Sache jetzt nicht ganz genau verfolgt, aber >> seit der Übernahme scheint es ja nur noch Ärger zu geben. > > Wieso sollte das die "Sprache" Java nicht "zukunftsfähig" machen? Wenn > du auf Nummer sicher gehen willst, kannst du natürlich gegen die OpenJDK > programmieren, aber das "Sun"-Java wird auch in Zukunft bestehen. Also du würdest JAVA noch als zukunftsfähig ansehen? Ich bin da halt momentan etwas verunsichert, da JAVA bei heise momentan ein Dauerbrenner ist, meist jedoch negativ... Läubi .. schrieb: > Julian W. schrieb: >> Über was ich noch nachgedacht habe, wäre die Software als >> Web-Interface zu programmieren > Hat natürlich auch Vorteile, würde dann aber auf irgendwas wie PHP+MySQL > gehen das ist recht verbreitet und du bist nicht auf JS angewiesen. Nunja, so etwas in der Art gibt es ja schon. Dann würde ich mich eher dem Projekt anschließen. Meine Absicht war es eher, dass ganze etwas benutzerfreundlicher zu Gestalten, was halt mit JS und qooxdoo wunderbar geht.
Ich bin in letzter Zeit Fan von Qt. Das ist C++ in einem (für mich) Java-ähnlichen Framework. Ich war von Anfang an begeistert, weil es so praktische Klassen für die allermeisten Zwecke gibt. Bei Hardware (Sound, serielle Schnittstelle, ...) wirds allerdings etwas dünn. Ich brauche diese Elemente aber überhaupt nicht...
Java ist, genauso wie C und dessen Derivate, keine ernstzunehmende Programmiersprache, sondern nur ein Treppenwitz der Informatik. Sowas benutzen nur merkbefreite BVWLer oder Möchtegern-Nerds auf copy-and-paste-progammierniveau. Die einzig brauchbare Programmiersprache ist noch immer der Assemblercode des jeweiligen Zielsystems!
Enno schrieb: > Die einzig brauchbare Programmiersprache ist noch immer der > Assemblercode des jeweiligen Zielsystems! Einzig übertroffen von Brainf*ck.
Di Pi schrieb: > Ich bin in letzter Zeit Fan von Qt. Das ist C++ in einem (für mich) > Java-ähnlichen Framework. > Ich war von Anfang an begeistert, weil es so praktische Klassen für die > allermeisten Zwecke gibt. Bei Hardware (Sound, serielle Schnittstelle, > ...) wirds allerdings etwas dünn. Ich brauche diese Elemente aber > überhaupt nicht... Nunja, mit C++ habe ich mich halt noch nie auseinandergesetzt, und QT erst recht nicht. Müsste mich dann halt erst mal einarbeiten. Was mich halt etwas stört ist die Lizenzpolitik von QT, von daher würde ich, wenn überhaupt, GTK+ einsetzten, dass ist zu 100% "freie Software" unter der LGPL.
Enno schrieb: > Die einzig brauchbare Programmiersprache ist noch immer der > Assemblercode des jeweiligen Zielsystems! Aber nur bei Programmen die in ihrer Komplexität so beschränkt sind, wie dein Posting ;)
Julian W. schrieb: > Was mich halt etwas stört ist die Lizenzpolitik von QT Was stört dich denn daran? Solange du im Qt-Quelltext nichts änderst musst du nichts zahlen...
GTK war, zumindest als ich es mal ausprobiert hatte, auf Windows noch eine einzige Baustelle. wxWidgets fällt mir auch noch ein, das wird auch öfters verwendet. fchk
Di Pi schrieb: > Julian W. schrieb: >> Was mich halt etwas stört ist die Lizenzpolitik von QT > > Was stört dich denn daran? Solange du im Qt-Quelltext nichts änderst > musst du nichts zahlen... Auch wenn ich das ganze kommerziell nutze? Wohl kaum, oder liege ich da falsch? Wobei ich mir nichtmal sicher bin, ob das als kommerziell gilt, was ich evtl. mal vorhabe: Ich wollte halt anbieten, gegen geringe Gebühr (1€ im Jahr?) die Daten auf meinen Server zu speichern, und somit überall Zugriff darauf zu haben. Hintergrund wäre halt, die Server-Kosten etwas zu decken. Evtl. gibt es auch noch ein kleines Web-Interface. Nur dumm wäre, wenn ich dann für QT tausende Euro Lizenzgebühren zu zahlen...
Julian W. schrieb: > Auch wenn ich das ganze kommerziell nutze? Wohl kaum, oder liege ich da > falsch? Auf http://qt.nokia.com/products/licensing/licensing findest du alle Infos. LGPL ist auch kostenlos dabei, die vorraussetzung ist aber, dass du alle Änderungen an Qt offenlegst. Meistens muss man Qt slebst aber nicht verändern. Man kann deren Klassen ja einfach per Vererbung erweitern ;)
Di Pi schrieb: > Julian W. schrieb: >> Auch wenn ich das ganze kommerziell nutze? Wohl kaum, oder liege ich da >> falsch? > > Auf http://qt.nokia.com/products/licensing/licensing findest du alle > Infos. LGPL ist auch kostenlos dabei, die vorraussetzung ist aber, dass > du alle Änderungen an Qt offenlegst. Meistens muss man Qt slebst aber > nicht verändern. Man kann deren Klassen ja einfach per Vererbung > erweitern ;) Stimmt, hab mal etwas in Wikipedia recherchiert: Scheinbar kann man QT nun auch kostenlos in kommerziellen Programmen nutzen :) Als ich das letzt mal danach geschaut habe, war das noch nicht möglich. Auf jeden Fall werde ich mir jetzt mal QT näher ansehen. Könnt ihr mit evtl. eine gute IDE empfehlen?
Der Qt-Creator ist ganz brauchbar, vor allem, weil die Installation der Toolchain total einfach ist. Es gibt aber auch ein nettes Qt für Eclipse.
Di Pi schrieb: > Der Qt-Creator ist ganz brauchbar, vor allem, weil die Installation der > Toolchain total einfach ist. > Es gibt aber auch ein nettes Qt für Eclipse. OK, dann werde ich mir die zwei Dinge gleich mal ansehen. Auch google mal nach ein paar Tutorials quälen :)
Di Pi schrieb: > Enno schrieb: >> Die einzig brauchbare Programmiersprache ist noch immer der >> Assemblercode des jeweiligen Zielsystems! > > Aber nur bei Programmen die in ihrer Komplexität so beschränkt sind, wie > dein Posting ;) Nein, eben nicht. Bei Leuten, welche sich mit der Programmierung über das beschriebene "copy and paste" hinaus beschäftigen, entsteht im Laufe der Zeit bei richtiger Herangehensweise eine Bibliothek an nützlichen Funktionen, welche in weiteren Projekten Verwendung finden kann. Der Vorteil liegt m.E. darin, das man GENAU weiss, was die jeweiligen Funktionen so treiben - im Gegensatz zu den Unzulänglichkeiten der z.B. verschiedenen C-Compiler und der absoluten Unbrauchbarkeit von Terrabytegroßen Java-Gedöns für Zielsysteme mit "eingeschränkten" Ressourcen oder kritischen Zeitverhalten. Das C bereits durch den Sprachkonstrukt inhärent fehlerträchtig ist, bedarf wohl keiner weiteren Erläuterung. Daher nochmal: Für Hobbyisten mag' C und JAVA für Lösungen "Marke Bastlerglück" vollkommen ausreichend sein, wenn sowohl Funktion als auch Haltbarkeit keine Rolle spielen. Sofern man mit seiner Software, bzw. seinem Produkt aus Hard- und Software Geld verdienen will (oder muss) und für die Funktion Gewährleistung bzw. Haftung übernimmt, beim Einsatz in sicherheitskritischen Umgebungen (wo z.B. das Leben von Menschen 'dranhängt) oder wenn reproduzierbare Ergebnisse gefragt sind, würde kein vernunftbegabter Mensch ernsthaft einen Gedanken an z.B. JAVA verschwenden!
Wenn du das Framework installierst ist da ein tolles Programm mit -zig Beispielen aller Größenordnungen dabei. Die kann man auch alle im QT-Creator öffnen und modifizieren.
Di Pi schrieb: > Wenn du das Framework installierst ist da ein tolles Programm mit -zig > Beispielen aller Größenordnungen dabei. Die kann man auch alle im > QT-Creator öffnen und modifizieren. Jop, die hab ich auch schon gefunden. Einfach genial :) Aber das "kleine" Tutorial schau ich mir auch noch an, sieht ganz brauchbar aus, ist aber 'en bisschen alt: http://mrunix.de/forums/showthread.php?t=31182
Julian W. schrieb: > Aber das "kleine" Tutorial schau ich mir auch noch an, sieht ganz > brauchbar aus, ist aber 'en bisschen alt: > http://mrunix.de/forums/showthread.php?t=31182 Sieht ganz brauchbar aus... Ich empfehle aber auch immer eng mit http://doc.qt.nokia.com/4.7/classes.html zusammen zu arbeiten. Da bekommt man 'schleichend' einen Überblick, was es sonst so alles gibt. Und die Doku der Klassen ist meistens ausgezeichnet.
Mensch, das is ja fast so schlimm wie youtube, da klickt man auf eins drauf und kann dann nicht mehr aufhören, sich "durchzuklicken" ;) Aber das Framework ist schon überwältigend, es gibt da ja wirklich fast alles, was man braucht :) Nur wie das mit PlugIn's funktioniert, muss ich noch schauen. Wäre nämlich schön, wenn ich meine Teile-Verwaltung mit PlugIn's erweitern kann, z.B. für zusätzliche Speicher-Interfaces (MySQL-DB, SQLite, Server, XML, ...)
Julian W. schrieb: > Nur wie das mit PlugIn's funktioniert, muss ich noch schauen. Wäre > nämlich schön, wenn ich meine Teile-Verwaltung mit PlugIn's erweitern > kann, z.B. für zusätzliche Speicher-Interfaces (MySQL-DB, SQLite, > Server, XML, ...) Hab ich auch noch nicht gemacht. Ich kann dir nur empfehlen (aber du scheinst dich schon ein wenig auszukennen), nicht mit den allergrößten Zielen anzufangen... Das Speicherinterface anzupassen dürfte nicht allzugroßen Aufand bedeuten, weil die Rückgabedatentypen sehr wahrscheinlich ähnlich oder gleich sind. Eine feste Entscheidung für SQL (mit wählbarer Quelle) wird dich aber wahrscheinlich nicht allzusehr einschränken.
Di Pi schrieb: > Sieht ganz brauchbar aus... Ich empfehle aber auch immer eng mit > http://doc.qt.nokia.com/4.7/classes.html zusammen zu arbeiten. Da > bekommt man 'schleichend' einen Überblick, was es sonst so alles gibt. > Und die Doku der Klassen ist meistens ausgezeichnet. Ich würde modulweise vorgehen; http://doc.qt.nokia.com/4.7/modules.html Aber besser ist noch, gleich den Qt Assistant zu öffnen. Da ist die komplette Doku auch noch mal drin, aber besser navigierbar und mit Index. Julian W. schrieb: > Nur wie das mit PlugIn's funktioniert, muss ich noch schauen. Da gibt's ein Beispiel, wie man das machen kann: http://doc.qt.nokia.com/4.7/tools-plugandpaint.html
Julian W. schrieb: > da JAVA bei heise momentan ein Dauerbrenner > ist, meist jedoch negativ... Da kann ich dir nix zu sagen, da ich kein Heise Leser bin... Aber wieso sollte Java keine Zukunft haben weil ein paar Leute auf heise negatives (was überhaupt?) berichten? Di Pi schrieb: > an kann deren Klassen ja einfach per > Vererbung erweitern Bis LGPL 2.0 galt dies aber schon als "zu veröffentliche Änderung" Enno schrieb: > wenn reproduzierbare Ergebnisse gefragt sind, würde > kein vernunftbegabter Mensch ernsthaft einen Gedanken an z.B. JAVA > verschwenden! So ein Quatsch! Hast du dir das selbst ausgedacht oder kannst du das auch belegen? Wieso sollten "Ergebnisse" in Java nicht reproduzierbar sein? Gerade unter Java hast du ein definiertes Laufzeitsystem was man idR so nirgends hat.
Di Pi schrieb: > Hab ich auch noch nicht gemacht. Ich kann dir nur empfehlen (aber du > scheinst dich schon ein wenig auszukennen), nicht mit den allergrößten > Zielen anzufangen... > Das Speicherinterface anzupassen dürfte nicht allzugroßen Aufand > bedeuten, weil die Rückgabedatentypen sehr wahrscheinlich ähnlich oder > gleich sind. > > Eine feste Entscheidung für SQL (mit wählbarer Quelle) wird dich aber > wahrscheinlich nicht allzusehr einschränken. Also bisher hab ich halt geplant, alle "Speicheraufrufe" in einer "Datei" auszulagern, diese also nicht quer über alle Klasse und Funktionen zu verstreuen. Und diese eine "Datei" wollte ich dann später halt als PlugIn auslagern. SQL ist ein guter Ansatz, jedoch wenn ich über's Internet auf eine MySQL-DB zugreife, würde ich dies lieber z.B. über ein php-Interface machen. Eine von außen erreichbare MySQL-DB erzeugt in mir ein unruhiges Gefühl, zudem ist die Übertragung noch unverschlüsselt und die meisten Hoster bieten sowieso keine von außen errreichbe MySQL-DB an. Aber gut, das ist ja alles noch Zukunftsmusik, aber ich wollte halt als schonmal die "Grundlagen" für eine evtl. Zukunft der Software legen.
Läubi .. schrieb: > Enno schrieb: >> wenn reproduzierbare Ergebnisse gefragt sind, würde >> kein vernunftbegabter Mensch ernsthaft einen Gedanken an z.B. JAVA >> verschwenden! > So ein Quatsch! Hast du dir das selbst ausgedacht oder kannst du das > auch belegen? > Wieso sollten "Ergebnisse" in Java nicht reproduzierbar sein? Gerade > unter Java hast du ein definiertes Laufzeitsystem was man idR so > nirgends hat. JAVA-Fanboy, hm? Weil z.B. das Typecasting in Java - wie auch in C - wohl eher dem "Prinzip Zufall" angelehnt ist, als das dort ein nachvollziehbares System hinterstehen würde! Darüber hinaus herrscht babylonische Vielfalt und Verwirrung, was die verschiedenen Compiler- und Interpreter anbelangt - ich darf mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, das ein Stück 10-15 Jahre alter Quellcode, welcher den Rahmen der bei den Javaisten so beliebten "Hallo-Welt"-Trivialitäten in Richtung "mehr Komplexität" durchbricht, bei den derzeitgen Compilern und Interpretern (und letzlich auch beim Programmierer) für akute Ratlosigkeit sorgt. Insofern ist meine Aussage vollkommen zutreffend; Ein Java-"Programm"-Kompilat wird, von zwei verschiedenen Compilern übersetzt (so es sich denn überhaupt mit einer anderen als der Compilervariante, für welche es erstellt wurde, compilieren lässt) - in der Hauptsache in mindestens einer Variante durch totale Funktionsverweigerung auffallen. Fazit: Der Java-Hobbymurks ist fast unmöglich zu portieren, die Sprache als solche unnötig ausladend und vom Konstrukt her wenig eindeutig, Terrabytegroße Funktionslibraries mit Nonkonformer- und somit Anwenderfeindlicher GUI und letzendlich Ablaufgeschwindigkeiten, welche einen in die "guten alten Zeiten" zurückkatapultieren, als Z80s mit 4 MHz Großrechnertechnik waren - das sind die bezeichnenden Merkmale von JAVA, die jedem ernsthaftem Programmierer die Zornesröte ins Gesicht treiben! Etwas sinnvolles mit Java zu programmieren, erscheint mir wie der Versuch, mit Hunde- oder Katzensch...e etwas leckeres zu kochen. Wohl bekommts!
Seit wann ist den QT eine Programmiersprache? Ich verwende seit Jahren nur noch Python. Meine Programme laufen bisher auf Windows, Linus und Mac ohne Probleme und bisher habe ich noch nie eine Programmieraufgabe gefunden wo ich nicht die passende Python Library (Modul) irgendwo gefunden habe. Man kann von einfachen Serverscripten bis zu ausgewachsenen Anwendungsprogrammen alles programmieren. Als Gui nehme ich meist wxWidget. Für meine mit Software auf Kriegsfuss stehend Kollegen packe ich das ganze mit py2exe noch in ein ausführbares Programm und sie sind zu frieden.
Enno schrieb: > JAVA-Fanboy, hm? Merkst du nicht, dass deine Beiträge einfach nicht das sind, was sich der OT erhofft? Ich schlag vor, nicht weiter auf Enno und sein ASM einzugehen.
Andreas Fischer schrieb: > Seit wann ist den QT eine Programmiersprache? QT ist zwar keine Programmiersprache, aber soweit ich das momentan abschätzen kann, "verändert" QT durch Erweiterungen und Makros C so stark, dass man schon fast von einer "neuen Programmiersprache" reden kann.
Julian W. schrieb: > Andreas Fischer schrieb: >> Seit wann ist den QT eine Programmiersprache? > > QT ist zwar keine Programmiersprache, aber soweit ich das momentan > abschätzen kann, "verändert" QT durch Erweiterungen und Makros C so > stark, dass man schon fast von einer "neuen Programmiersprache" reden > kann. Qt ist C++. Die Makros erweitern den Funktionsbereich und machen Konstrukte wie SIGNALs und SLOTs möglich. Die mitgegebenen Klassen sind einfach eine Sammlung sinnvoller vorgefertigter Funktionen. Ich würde es als "Aufsatz" und eben als Framework bezeichnen ;)
Enno, dann fände ich es aber interessant, mit welcher Sprache du deine PC-Anwendungen schreibst. Du möchstes mir doch nicht ernsthaft erzählen, dass du deine grafischen Oberflächen mit Assembler-Aufrufen der Win-API machst! Nico
>Sofern man mit seiner Software, bzw. seinem Produkt aus Hard- und >Software Geld verdienen will (oder muss) und für die Funktion >Gewährleistung bzw. Haftung übernimmt, beim Einsatz in >sicherheitskritischen Umgebungen (wo z.B. das Leben von Menschen >'dranhängt) oder wenn reproduzierbare Ergebnisse gefragt sind, würde >kein vernunftbegabter Mensch ernsthaft einen Gedanken an z.B. JAVA >verschwenden! Mir fällt mindestens eine Firma (eine nicht gerade kleine Firma!) ein, die Java (zumindest im Frontend) verwendet. MfG
Läubi .. schrieb: > Wieso sollten "Ergebnisse" in Java nicht reproduzierbar sein? Ganz offensichtlich eine Verwechslung mit: http://p-nand-q.com/humor/programming_languages/java2k.html Julian W. schrieb: > QT ist zwar keine Programmiersprache, aber soweit ich das momentan > abschätzen kann, "verändert" QT durch Erweiterungen und Makros C C++, nicht C. > so stark, dass man schon fast von einer "neuen Programmiersprache" reden > kann. Das ist etwas übertrieben. Es gibt ein paar Makros, die für die Erzeugung zusätzlichen Codes verwendet werden, der mit ans Programm gelinkt wird.
> so stark, dass man schon fast von einer "neuen Programmiersprache" reden > kann. Namens C++.
Ja, muss sagen, ich hab doch etwas übertrieben, muss aber auch einfach eingestehen, dass ich von QT schwer beeindruckt bin, vor allem da man es in kommerziellen Anwendungen "umsonst" nutzen darf, ohne den Quellcode zu veröffentlichen, dank LGPL :) Aber noch eine Frage hab ich: QT ist ja plattformunabhängig, läuft also ohne Anpassung z.B. auf Win, Linux und Mac. Doch wie sieht das mit dem kompilieren aus? Ich habe hier leider nur Windows und Linux zur Verfügung, könnte ich damit quasi auch den Compiler dazu bewegen, eine Mac-Version zu kompilieren oder geht das nur unter Mac?
Du kannst dir ne Cross-Toolchain vom GCC installieren. Geht wie jedes andere Crosscompilieren auch.
Andreas Fischer schrieb: > Ich verwende seit Jahren nur noch Python. Meine Programme laufen bisher > auf Windows, Linus und Mac ohne Probleme und bisher habe ich noch nie > eine Programmieraufgabe gefunden wo ich nicht die passende Python > Library (Modul) irgendwo gefunden habe. Man kann von einfachen > Serverscripten bis zu ausgewachsenen Anwendungsprogrammen alles > programmieren. Als Gui nehme ich meist wxWidget. Python ist aber extrem langsam.
Samuel K. schrieb: > Python ist aber extrem langsam. Für ein Programm zur Verwaltung von Bauteilen sollte es langen! Ansonsten kann man immer noch Teile in C++ schreiben und in Python einbetten. Ich denke für diese Aufgabe ist Python bestens geeignet. Ich würde Python und Qt empfehlen.
Um die Verwirrung komplett zu machen, werf ich mal Jambi ins Rennen. Endlich ein Toolkit das die Nachteile von Java mit den Nachteilen der Qt kombiniert! http://doc.qt.nokia.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-index.html
> Endlich ein Toolkit das die Nachteile von Java mit den Nachteilen der Qt > kombiniert! Nachteil * Nachteil = 2 * Nachteil :-) Oder meintest du das etwas anderes? ;)
> Würde gerne mal eure Meinung dazu hören :) Nimm die Sprache die du am Besten beherrschst. Eine lauffähige Umgebung hältst du bereit, wenn du willst jahrelang durch Erhal des alten Rechners. > ich entwickle schon seit längerem an einer Bauteile-Verwaltung Seit längerem ? Was bitteschön dauert daran länger als 1 Tag ? Vollautomatische Teileanzahl und Wert-Erkennung per WebCam ? Nachbestellungautomatik durch robot-Zugriff auf WebSeiten der bekannten Händler ? Doch nicht ne Liste mit Typennummer und Anzahl und noch ein paar Daten...
Gelegenheitsprogrammierer schrieb: > Nachteil * Nachteil = 2 * Nachteil nöö wenn dann: Nachteil² wer rechnen kann....
Julian, ich arbeite auch an einem Projekt mit Qt und bin ebenso wie Du beeindruckt und begeistert wie Du - insofern alles fein. In Deinem OP erwähnst Du die Option einer Web Applikation. Das würde ich - trotz aller Begeisterung - nochmal näher ins Auge fassen. Wir bewegen uns immer mehr in Richtung einer mobilen, browsergestützten always on Welt. Wenn Deine Applikation von vielen Menschen genutzt werden soll, würde ich auf eine Web Lösung gehen. Dann ist (fast) egal ob Sie Brauser wie FF, Opera, Safari oder ihre mobilen Pendants von Android, Blackberry, iOS, MeGoo, Symbian... nutzen. Du müsstest Dich zwar möglicherweise mit Kompatibilitätsproblemen der Brauser herumschlagen, jedoch Deine Programmlogik bleibt konstant. Nur so als Gedankenanstoss Schöne Feiertage, Jörg
Wenn Webapplikation, dann würd ich mir mal qooxdoo anschauen. Ist ein recht umfangreiches Web/Javascript-Toolkit, das sehr stark von der Qt inspiriert wurde. http://demo.qooxdoo.org/current/showcase/# http://demo.qooxdoo.org/current/demobrowser/#
Troll (Gast) schrieb: > wer rechnen kann.... Unter einer Verdopplung eines Nachteils kann sich jeder noch was vorstellen und nur darum gings. Das Ganze stellt man sich eher als eine Vereinigung einer Menge vor. Julian W. (julian-w) schrieb: Erster Akt > Zuerst habe ich in C# programmiert .. Zweiter Akt > Dann stieg ich auf JAVA um .. Dritter Akt > Ich weiß, C mit entsprechenden Frameworks geht auch, aber momentan traue > ich mir noch keine C-Programme für Windows zu Höhepunkt Tataaa!! > Ja, muss sagen, ich hab doch etwas übertrieben, muss aber auch einfach > eingestehen, dass ich von QT schwer beeindruckt bin, Irgendwie verstehe ich da was nicht. C++ mit Qt soll einfacher sein als C#, Java? Nicht Objekt-orientierter C-Code mit der guten, alten nativen Win32-API ist doch nach meiner Einschätzung deutlich weniger Lernaufwand als echtes C++ Gedöns und selbst C# mit seiner Objektorientiertheit erscheint von der Syntax her eingängiger, zumal das .NET Framework äußerst mächtig ist. Fragt ihr euch eigentlich auch mal, ob ihr überhaupt den Plattformübergriff braucht? Mir kommt das inzwischen vor wie eine Modeerscheinung: "Was?? Das ist nicht Plattformübergreifend? Dann ist das ja gar nicht hipp!" Oder bald "Die Cloud muss her! Es muss alles in die Cloud! Sonst taugt es nichts mehr, ist igitt unmodern .."
So, ich melde mich dann auch mal wieder zu Wort ;) Jap, ich habe schon einige Schritte hinter mir. Einige würden sagen, der laufende Wechsel hat "nur" unnötige Arbeit gemacht. Ich aber sage, es hat mich in meinen Fähigkeiten sehr viel weiter gebracht, z.B. hab ich die schwächen und stärken der Programmiersprachen erkannt, gemerkt, wie lange man für was braucht, was evtl. umständlich ist, ... Nicht umsonst hatte ich beim BwInf 2009/10 in der 1. Runde eine perfekte Einsendung ;) http://bwinf.de/index.php?id=454 Das Problem, dass ich einfach habe, ist das ich quasi einen Windows/Linux Mischbetrieb habe. Ich selbst benutzte mittlerweile fast ausschließlich Linux, aber der "ganze Rest" (Freunde, Bekannte, Helfer) benutzen Windows. Zuerst hatte ich auch meine komplette "PC-Flotte" auch mit Windows laufen, daher C# als erste Programmiersprache. Vor allem gab und gibt es zu C# viel "kostenloser" Code für alle möglichen Dinge, wie GUI-Elemente, zippen, SQL-DB, ... Als sich dann halt mehr und mehr die Notwendigkeit der Platzformunabhängigkeit (zumindest auf Windows und Linux musst die Software laufen) herausstellte, stieg ich halt auf JAVA um. Doch irgendwie konnte ich mich nie wirklich mit JAVA anfreunden. Daher wollte ich jetzt halt einfach mal C++ mit QT testen, ob das evtl. das ideale für mich ist. Immerhin ist ein Großteil der Software in C++ geschrieben, was wohl nicht ohne Grund so sein wird. Klar, das erste Programm wird kein Meisterstück sein, aber ich werde natürlich nicht gleich mit der Teile-Verwaltung anfangen ;) Im Grunde ist es ja egal, ob es ein Erfolg oder Misserfolg wird, auf jeden Fall werde ich Erfahrungen sammeln. Und ich denke, schon nur durch die Erfahrungen, die ich bis jetzt gewonnen haben, auch wenn quasi "nur" unfertige Alpha-Versionen entstanden sind, ist für mich das Projekt schon ein voller Erfolg. Die vielen Wechsel der Programmiersprache haben mir aber auch weitergeholfen, mein "Konzept" quasi reifen zu lassen, und somit wichtiges und unwichtiges zu filtern. Wenn ich nur daran denke, was ich für "Pläne" am Anfang hätte und was daraus geworden ist... schon beängstigend, was für Phantasien ich am Anfang hatte^^ Eine Web-Applikation ist auch eine gute Idee, aber da stellt sich wieder die Frage mit der Programmiersprache. php oder doch eher was in die Richtung phyton? Und wenn php, dann schon 5.3 oder doch bei 5.2 bleiben. php ist halt "Massentauglich", phyton und co. halt nicht :( qooxdoo ist auch recht nett und ich selbst setzt ist für mein WebCMS ein. Ist auch ein wirklich brauchbares Framework für JS, nur leider lässt hier auch die Performance etwas zu wünschen übrig, was aber evtl. auch eher an dem Browser liegt, Firefox ist ja momentan leider nicht mehr der schnellste, was sich aber ja mit v4 ändern soll... Hier ein paar Screenshots, wo ich qooxdoo einsetzte, falls es jemand interessiert: http://projects-tutorials.de/index.php?nav_page=3&nav_sid=14&con_mod=text&con_id=11 Auf meinem Netbook z.B. laufen die Beispiele von qooxdoo unter Firefox nicht wirklich "flüssig", also es gibt immer wieder ruckler, was halt nicht so schön ist. Aber gut, hier kann man ja wie gesagt auf die nächste Version des FF warten. Auf jeden Fall ist es mal eine interessante, aber auch anstrengende Erfahrung, eine Software wirklich Plattformunabhängig zu programmieren.
Samuel K. schrieb: > Python ist aber extrem langsam. mit haargenau derselben Argumentation könnte man behaupten, dass auch Matlab, R ebenfalls extrem langsam sind. Skripte sind "glue logic", alles rechenintensive soll und wird ausgelagert sein. Tipp: Für eine Schrittweite Python Optimierung bietet sich cython an.
Julian W. schrieb: > Eine Web-Applikation ist auch eine gute Idee, aber da stellt sich wieder > die Frage mit der Programmiersprache. php oder doch eher was in die > Richtung phyton? Und wenn php, dann schon 5.3 oder doch bei 5.2 bleiben. > php ist halt "Massentauglich", phyton und co. halt nicht :( hust .. Python heisst es
Solche Fragen tauchen gerne in Projekten auf, in welchen überhaupt noch eine Entscheidungsmöglichkeit bezüglich Sprache und Frameworks besteht. Interessant ist immer wieder die Aussage, daß Java plattformunabhängig sei. Tatsächliche Plattformunabhängigkeit würde vermutlich erst bestehen, wenn die Software als reine Energie ihre Funktion ohne jegliche Notwendigkeit einer Hardware- und Software-Umgebung erfüllen würde. Dem ist natürlich nicht so. Es bestehen also sehr wohl Anhängigkeiten zu bestimmten Versionen der Laufzeitumgebung. Im einfachen Fall. Interessant werden die Projekte, welche auf native, externe Bibliotheken angewiesen sind. Oder wenn Teile aus Sicherheits- bzw. Performanzanforderungen in anderen Sprachen implementiert sind. Die Plattformunabhängigkeit war dann aber tragendes Argument im Entscheidungsprozess, kann aber in der Praxis dann nicht umgesetzt werden, ohne weiteren Aufwand in Entwicklung und Test zu investieren. Die Schuld wird dann, nicht ganz zu unrecht, in den externen Komponenten gefunden. Dann wird beschlossen, in Zukunft vollständig auf externe Komponenten zu verzichten. Dann steht der nächste Entscheidungsprozess an und es wiederholt sich genau dieselbe Geschichte. Da ist es manchmal nicht so einfach, immer die unbedingt nötige Ruhe und Gelassenheit an den Tag zu legen. Wenn ich die Entscheidungsmöglichkeit hatte, habe ich in der Tendenz eher unabhängige Systeme gewählt. Eher GTK als QT. Eher PostgreSQL als MySql. Eher durch GCC unterstützte Sprachen, als die Beschränkung auf Sprachen mit ausschließlich kommerziellen Compilern. Das erfordert zwar manchmal etwas mehr Aufwand, bietet mir jedoch weitgehende Unabhängigkeit von wirtschaftlichen Entscheidungen Anderer. Ich stelle mir also die Frage, wieviel Vertrauen Oracle (oder jede Firma, welche Oracle übernehmen könnte) sich erarbeitet hat. Wie groß ist die Loyalität der Firma gegenüber der Gemeinschaft aller betroffenen Entwickler und Firmen? Die Antwort muß wohl jeder Entwickler für sich selber geben. Die Programmiersprache betreffend - mich beruhigt die sehr langsame Fortentwicklung von C/C++. Es gibt kein Feature, ohne welches ich heute nicht leben kann. Aber wenn es wirklich gewünscht ist und Sinn ergibt, wird es auf eine Art und Weise eingeführt, welche die wenigsten Nebenwirkungen mit sich bringt und so viel Kontinuität wie möglich bietet. Und mit etwas Erfahrung und Sorgfalt ist auf Quelltext-Ebene eine hohe bis vollständige... Plattformkompatibilität... möglich. Abschließend vielleicht noch einen Hinweis. Ich empfehle gerne die Verwendung von GPL bzw. LGPL Komponenten für die Entwicklung. Ich programmiere zwar gerne, schließe aber auch Projekte gerne ab. Verwendung von Bestehendem beschleunigt dies natürlich. Und auch für kommerzielle Projekte sind LGPL Bibliotheken ganz klar zu empfehlen. Nur bitte immer im Kopf behalten: Hinweis auf die GPL/LGPL irgendwo in der Dokumentation und dann gleich für die LGPL Komponenten deren Quelltext und die eigentliche Lizenz mit dazulegen. Der Kunde muß sich damit nicht auseinandersetzen. Er muß es nur können. Das reicht. Wird dies nicht berücksichtigt, kann es zu Problemen kommen, die natürlich auch ausgeräumt werden können, aber nicht sein müssen. Und damit verbunden würde die Verwendung von LGPL Komponenten im kommerziellen Umfeld in Verruf geraten, was nicht sein muß. My unsorted pile of 2-cent pieces. (A Clown)
Hallo "Clown", erst mal viele Dank für deinen sehr ausführlichen (und grammatikalisch sowie orthographisch nahezu vollkommen korrekten) Beitrag. RESPEKT Sieht man hier leider immer seltener. Ein paar Fragen hab ich aber noch: Clown schrieb: > Wenn ich die Entscheidungsmöglichkeit hatte, habe ich in der Tendenz > eher unabhängige Systeme gewählt. Eher GTK als QT. Warum würdest du GTK eher nehmen wie QT? QT steht ja mittlerweile auch unter einer sehr "freien" Lizenz (GPL/LGPL), zudem steht das KDE-Projekt dahinter, von daher würde ich die Zukunft von QT als gesichert ansehen und QT auch als "unabhängiges" Projekt betrachten, da ich nicht denke, dass Nokia in der Lage ist, "von heute auf morgen" der openSource-Gemeinde den Zutritt zu dem Projekt zu verwehren. Zudem bietet QT wesentlich mehr Möglichkeiten wie GTK. Von daher wäre es nett, wenn du mir ein paar Gründe nennen könntest, wo GTK Vorteile gegenüber QT hat, würde mich sehr interessieren, da ich selber eigentlich keine finden kann :/ Clown schrieb: > Nur bitte immer im Kopf behalten: Hinweis auf die GPL/LGPL irgendwo in > der Dokumentation und dann gleich für die LGPL Komponenten deren > Quelltext und die eigentliche Lizenz mit dazulegen. Der Kunde muß sich > damit nicht auseinandersetzen. Er muß es nur können. Das reicht. Das ist natürlich selbstverständlich. Normalerweise spende ich auch immer gerne ein paar Euro für diese Projekte, falls noch etwas Geld (2 bis 3€) auf dem PayPal-Konto "rumliegen", was öfters nach eBay-Einkäufen der Fall ist. Gut, bei QT bräuchte ich wohl nicht zu spenden ;)
Julian W. (julian-w) schrieb: > Hallo "Clown", > erst mal viele Dank für deinen sehr ausführlichen (und grammatikalisch > sowie orthographisch nahezu vollkommen korrekten) Beitrag. RESPEKT > Sieht man hier leider immer seltener. Ähem Julian :-), ich möchte ja nicht meckern, aber diese Stilblüten hier sind nun wirklich kein korrektes Deutsch. Das sind schlicht unvollständige Sätze, die man so nicht schreiben sollte. ". Im einfachen Fall." ". Eher GTK als QT." ". Eher PostgreSQL als MySql." Ansonsten ist nix dagegen einzuwenden (so wie du das hier schilderst), sich mal an verschiedenen Programmiersprachen bzw. Plattformen zu versuchen. Du hast dir mit deinem Umstieg auf Linux die Notwendigkeit sowohl für Linux als auch für Windows (wegen deinem Bekanntenkreis) zu programmieren quasi (ohne Not) ins Haus geholt. Ohne diesen Umstieg wäre die (Programmier-) Welt für dich einfacher, weil überschaubarer. Zumal es mit den MS-Produkten (Visual ..) hervorragende Tools gibt, für die man unter Linux so schnell keinen angemessenen Ersatz findet (das ist meine Meinung, das darf jeder gerne anders sehen). Immerhin dürfen wir alle froh sein, welche vielfältigen Möglichkeiten es inzwischen gibt Programmcode mit aufwendigen Tools zu erstellen, die z.T. (nach meinem Gefühl) leider einiges an Einarbeitungszeit erfordern. Man verliert sich schnell im Dschungel der Dialekte/Frameworks/Libs und wenn man mal eine Schneise ins Gestrüpp geschlagen hat, gibt es bereits wieder neues zu beachten oder man ist selber geneigt sich wieder neu zu orientieren. Alles nicht so einfach ;).
Clown schrieb: > Die Programmiersprache betreffend - mich beruhigt die sehr langsame > Fortentwicklung von C/C++. Es gibt kein Feature, ohne welches ich heute > nicht leben kann. Dann können die Ansprüche nicht hoch sein (scnr). > Abschließend vielleicht noch einen Hinweis. Ich empfehle gerne die > Verwendung von GPL bzw. LGPL Komponenten für die Entwicklung. Ich > programmiere zwar gerne, schließe aber auch Projekte gerne ab. > Verwendung von Bestehendem beschleunigt dies natürlich. Und auch für > kommerzielle Projekte sind LGPL Bibliotheken ganz klar zu empfehlen. Wenn man sich in rechtliche Grauzonen begeben will, gerne. Gerade wenn C++ verwendet wird, ist eine GPL/LGPL V2.1. definitiv nicht verwendbar, falls man rechtlich keine Probleme bekommen will (Qt bzw. Nokia tragen dem in der Nokia Qt LGPL Exception Version 1.0 Rechnung). Ähnlich unklar ist bspw. wie dynamisch generierter Quellcode zu behandeln ist bzw. ob dort auch entsprechende Ausnahmen vorgesehen sind. Code unter der AGPL kann ebenso zur Falle werden.etc. pp. > Nur bitte immer im Kopf behalten: Hinweis auf die GPL/LGPL irgendwo in > der Dokumentation und dann gleich für die LGPL Komponenten deren > Quelltext und die eigentliche Lizenz mit dazulegen. Der Kunde muß sich > damit nicht auseinandersetzen. Er muß es nur können. Das reicht. Der Kunde muß sich u.a. aufgrund der oben genannten Problematik mit der Lizenz auseinandersetzen (ebenso muss er sich um mögliche Urheberrechts- und Patentverstöße kümmern). > Wird dies nicht berücksichtigt, kann es zu Problemen kommen, die > natürlich auch ausgeräumt werden können, aber nicht sein müssen. Und > damit verbunden würde die Verwendung von LGPL Komponenten im > kommerziellen Umfeld in Verruf geraten, was nicht sein muß. Es gibt vernünftige Lizenzen (BSD, Apache etc.). "A less publicized and unintended use of the GPL is that it is very favorable to large companies that want to undercut software companies. In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior." http://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html#GPL-ADVANTAGES > My unsorted pile of 2-cent pieces. > (A Clown)
Gelegenheitsprogrammierer schrieb: > Zumal > es mit den MS-Produkten (Visual ..) hervorragende Tools gibt, für die > man unter Linux so schnell keinen angemessenen Ersatz findet (das ist > meine Meinung, das darf jeder gerne anders sehen). Nunja, daher habe ich auch vor, hauptsächlich unter Windows zu entwickeln, denn dann stehen mit all diese "tollen Tool's" zur Verfügung ;) Da ich momentan eh noch einen "Mitsch-Matsch-Betrieb" zwischen Windows und Linux fahre, ist es eigentlich recht egal, unter welchem OS ich das ganze entwickle. Wobei ich sagen muss, dass nicht alle Linux-Tools zum Entwickeln "schlecht" sind, so finde ich persönlich Code::Blocks ideal zum programmieren von AVRs in C und würde es momentan gegen nichts (NetBeans, Visual Studios, Eclipse, ...) eintauschen ;)
Julian W. schrieb: > Clown schrieb: >> Wenn ich die Entscheidungsmöglichkeit hatte, habe ich in der Tendenz >> eher unabhängige Systeme gewählt. Eher GTK als QT. > > Warum würdest du GTK eher nehmen wie QT? QT steht ja mittlerweile auch > unter einer sehr "freien" Lizenz (GPL/LGPL), zudem steht das KDE-Projekt > dahinter, von daher würde ich die Zukunft von QT als gesichert ansehen > und QT auch als "unabhängiges" Projekt betrachten, da ich nicht denke, > dass Nokia in der Lage ist, "von heute auf morgen" der > openSource-Gemeinde den Zutritt zu dem Projekt zu verwehren. Zudem > bietet QT wesentlich mehr Möglichkeiten wie GTK. > Von daher wäre es nett, wenn du mir ein paar Gründe nennen könntest, wo > GTK Vorteile gegenüber QT hat, würde mich sehr interessieren, da ich > selber eigentlich keine finden kann :/ Richtige Frage bzw. richtiger Einwand. Meine Präferenz war in diesem Fall durch zwei weitere Faktoren bestimmt. Zuerst die Lizenzfrage. Mit der LGPL würde ich nun auch QT wieder stärker bei einer Entscheidung berücksichtigen. Das war früher ein Problem, da die GPL in dieser Form der Verwendung bei kommerziellem Einsatz die Veröffentlichung aller beteiligten Quelltexte erforderte. Wirtschaftlich betrachtet ein sehr gewagtes Vorgehen. Und die kommerzielle Trolltech Lizenz war schlicht ein zu berücksichtigender Kostenfaktor. Und dann, die Abhängigkeit von der Firma Nokia wird durch die Verwendung durch das KDE Projekt und deren starke Entwicklergemeinschaft ganz klar relativiert. Hier muß ich jedoch eine persönliche Befangenheit eingestehen. Nach der Einmischung von Nokia in die finnische Gesetzgebung (Lex Nokia), sind mir die ein Dorn im Auge. Kurzum, ich würde aber auch QT in der Evaluierung berücksichtigen. Es ist mehr als 6 Jahre her, daß ich QT und GTK verglichen habe. Da hat sich inzwischen auf beiden Seiten mit Sicherheit sehr viel verändert. Nachdem Java als Sprache und .NET als Framework an Ausschlußkriterien gescheitert waren, blieben im wesentlichen nur noch QT und GTK. Ein verhältnismäßig oberflächlicher Vergleich hatte ergeben, daß beide Systeme die Anforderungen erfüllen. Damit war die Lizenz ausschlaggebend und die LGPL brachte somit den entscheidenden Vorteil. Technisch hat QT sicher einiges zu bieten und ist in manchen Bereichen vermutlich GTK überlegen. Kann in Bereichen natürlich auch umgekehrt der Fall sein. Ich habe die letzten Jahre sowohl GTK- als auch QT-Programmierer über ihr Framework fluchen hören. Interessant habe ich an GTK gefunden, daß es sich eigentlich um eine C Bibliothek handelt und die C++ API nur eine Erweiterung ist. Ich denke, daß die Anbindung von nicht-objektorientierten Sprachen dadurch vereinfacht wird. Das hat natürlich den Nachteil, daß die C++ Schnittstelle geringfügig höhere Ressourcen verwendet. Was mich an QT irritiert hat, war die Verwendung des MOC (meta-object-compiler). Da mag ich etwas puristisch denken, aber es gibt genau eine Instanz, welche einen Quelltext modifiziert. Das ist entweder ein Entwickler oder ein Programm. Einen Text-Editor sehe ich hier als Erweiterung des Entwicklers an. Aber bereits wenn der Editor Änderungen am Quelltext vornimmt, ohne daß es explizit von mir initiiert wurde, sehe ich das als Problem. Das wäre vermutlich ein Punkt, welchen ich genau untersuchen würde, wenn die Entscheidung für oder gegen QT ansteht. Kann ich auf die Verwendung des MOC verzichten, ohne ebenfalls auf wesentliche Aspekte von QT verzichten zu müssen? Wie kompliziert ist die Integration in meine üblicherweise verwendeten Werkzeuge (Visual Studio, autotools, CodeBlocks)? Und in diesem Zusammenhang wäre dann auch qmake zu untersuchen. Ich sehe es nicht gerne, wenn Werkzeuge einzelner Komponenten den Einsatz für das Gesamtprojekt erforderlich machen oder nur mit Aufwand zu vermeiden sind. Nicht weil qmake an sich schlecht wäre, sondern weil ich die Zahl der verpflichtenden Abhängigkeiten gerne in Grenzen halte. Letztlich noch, ich bin vor Jahren von KDE auf Gnome umgestiegen, bin deswegen vermutlich auch etwas voreingenommen. Ich habe aber gerade im Vergleich auf diesen beiden Plattformen oft den Eindruck gewonnen, daß GTK deutlich schonender mit den Ressourcen umgeht. Das kann natürlich verschiedene Ursachen haben, sei es meine Voreingenommmenheit, Lasten aus der Verwendung in der jeweiligen DE (desktop environment) oder Fehler in der Implementierung des jeweiligen Programms. Ich kann also leider/glücklicherweise keine ausschlaggebenden Vorteile von GTK über QT nennen. Aber der theoretische sowie dann aber auch alltagsrelevante Vergleich beider Systeme würde mich sehr interessieren. Vermutlich ein wenig von meiner Hoffnung getrieben, ein paar Vorteile von GTK zu finden... :-)
Clown schrieb: > Zuerst die Lizenzfrage. Mit der LGPL würde ich nun auch QT wieder > stärker bei einer Entscheidung berücksichtigen. Das war früher ein > Problem, da die GPL in dieser Form der Verwendung bei kommerziellem > Einsatz die Veröffentlichung aller beteiligten Quelltexte erforderte. Wenn man denn das Programm selbst überhaupt veröffentlichen will. Wenn man es nur intern nutzen will, muß man gar nichts veröffentlichen. > Was mich an QT irritiert hat, war die Verwendung des MOC > (meta-object-compiler). Da mag ich etwas puristisch denken, aber es gibt > genau eine Instanz, welche einen Quelltext modifiziert. Das ist entweder > ein Entwickler oder ein Programm. Das Gerücht hält sich auch hardnäckig. Der MOC modifiziert am von dir geschriebenen Code genau gar nichts. Der wird so, wie du ihn geschrieben hast, an den Compiler weitergegeben. Was MOC tut, ist lediglich eine zusätzliche Datei erzeugen, die mit ans Programm gelinkt werden muß. Aber Autocode-Generatoren sind nun nichts außergewöhnliches und kommen häufig vor. Warum da gerade auf dem MOC immer rumgeritten wird, verstehe ich nicht. > Das wäre vermutlich ein Punkt, welchen ich genau untersuchen würde, wenn > die Entscheidung für oder gegen QT ansteht. Kann ich auf die Verwendung > des MOC verzichten, ohne ebenfalls auf wesentliche Aspekte von QT > verzichten zu müssen? Nein. Ohne MOC kannst du z.B. keine Signale oder Slots definieren, und das ist ein wesentlicher Aspekt von Qt. > Wie kompliziert ist die Integration in meine üblicherweise verwendeten > Werkzeuge (Visual Studio, autotools, CodeBlocks)? Um Visual Studio hat sich Trolltech/Nokia schon gekümmert. autotools werden von vielen Qt-Projekten verwendet, sollten also auch kein Problem darstellen. Zu CodeBlocks kann ich nichts sagen. > Und in diesem Zusammenhang wäre dann auch qmake zu untersuchen. Wenn du qmake benutzt, mußt du nur die verwendeten Header-Dateien im Projekt-File angeben, dann kümmert es sich selbst um moc. > Ich sehe es nicht gerne, wenn Werkzeuge einzelner Komponenten den Einsatz > für das Gesamtprojekt erforderlich machen oder nur mit Aufwand zu > vermeiden sind. Nicht weil qmake an sich schlecht wäre, sondern weil ich > die Zahl der verpflichtenden Abhängigkeiten gerne in Grenzen halte. qmake ist sicher nicht zwingend. Was die Abhängigkeiten betrifft, sehe ich aber kein Problem, wenn du eh schon von Qt abhängst. Da hast du ja eher weniger Abhängigkeiten als z.B. mit Autotools.
Rolf Magnus schrieb: > Das Gerücht hält sich auch hardnäckig. Der MOC modifiziert am von dir > geschriebenen Code genau gar nichts. Der wird so, wie du ihn geschrieben > hast, an den Compiler weitergegeben. Was MOC tut, ist lediglich eine > zusätzliche Datei erzeugen, die mit ans Programm gelinkt werden muß. > Aber Autocode-Generatoren sind nun nichts außergewöhnliches und kommen > häufig vor. Warum da gerade auf dem MOC immer rumgeritten wird, verstehe > ich nicht. Mein Fehler, das hätte ich genauer ausdrücken sollen. Prinzipiell ist ein ein vergleichsweise sauberes Vorgehen. Wenn ich da an meine letzten .NET oder Java/NetBeans Erfahrungen denke, sträuben sich mir immer noch die Nackenhaare. Ich möchte klar getrennte Zuständigkeiten bis zum Compiler. Und solange es meine Sprachdomäne ist, bevorzuge ich das letzte Wort vor dem Compiler. Nun läßt sich argumentieren, daß MOC auch nicht viel mehr ist als ein Compiler. Technisch gesehen vermutlich eher ein Präprozessor, aber der Unterschied scheint im Bezug zur Sache jetzt nicht wichtig. Meine Skepsis mag zum Teil in der Anfangsphase begründet liegen, als es noch Probleme mit dem Parser bzw. Quelltext Generator gab. Ich gehe aber davon aus, daß diese inzwischen im Wesentlichen behoben sind. Vom Standpunkt der Entwicklungswerkzeuge ist es jedoch so, daß jetzt MOC und C++ Compiler denselben Parser (bzw. jeweils Parser für dieselbe Syntax) benötigen. Es wird dadurch zwei Instanzen, welche den vollen Sprachumfang unterstützen müssen. Meine Sorge ist die, daß durch MOC hier Einschränkungen einführt werden, welche nicht nicht im C++ Compiler begründet liegen. Das mag jetzt weder ein großes, noch zwingendermaßen ein Problem sein. Wenn es aber eine elegantere Lösung geben sollte, bevorzuge ich die natürlich. Ein Ansatz, der mir sehr gefallen hatte, war die Generierung spezifischer Basisklassen bei GTK. Ein Ansatz, welcher derzeit leider nicht weiter verfolgt wird. Aus der XML-Beschreibung der zu erzeugenden Benutzungsoberfläche werden dabei für alle wesentlichen Objekte Basisklassen erzeugt. Welches die wesentlichen Objekte sind, kann durch den Entwickler festgelegt werden. Das kann nur ein Hauptfenster sein, welches sämtliche weiteren Objekte enthält. Es können aber auch für bestimmte Unterobjekte, beispielsweise ein Zeichenbereich, eigene Basisklassen generiert werden. Die Basisklassen enthalten alle Implementierungen, welche aufgrund der Oberflächenspezifikation automatisch generiert werden können. Von den generierten Basisklassen werden jetzt die Applikationsklassen abgeleitet und dort die Implementierung der Anwendung vorgenommen. Für Signal-Handler werden in der Basisklasse abstrakte Methoden generiert, in welchen in der abgeleiteten Klasse dann die eigentliche Funktionalität implementiert wird. Auf Instanzen aller enthaltenen Objekte kann über generierte Objektvariablen der jeweiligen Basisklasse direkt zugegriffen werden. >> Das wäre vermutlich ein Punkt, welchen ich genau untersuchen würde, wenn >> die Entscheidung für oder gegen QT ansteht. Kann ich auf die Verwendung >> des MOC verzichten, ohne ebenfalls auf wesentliche Aspekte von QT >> verzichten zu müssen? > > Nein. Ohne MOC kannst du z.B. keine Signale oder Slots definieren, und > das ist ein wesentlicher Aspekt von Qt. Rein theoretisch noch etwas - ob das in der Praxis nun Sinn ergeben würde, möchte ich vorerst dahingestellt lassen. Fügt der MOC nur Quelltext hinzu, oder wird bestehender Quelltext modifiziert? Wenn keine Modifikation erfolgt, wäre es technisch umsetzbar, auch hier das System der generierten Basisklassen und manuell geschriebenen Applikationsklassen umzusetzen? > qmake ist sicher nicht zwingend. Was die Abhängigkeiten betrifft, sehe > ich aber kein Problem, wenn du eh schon von Qt abhängst. Da hast du ja > eher weniger Abhängigkeiten als z.B. mit Autotools. Für kleine Projekte, die primär auf eine QT Anwendung ausgerichtet sind, ist dies sicher die richtige Überlegung. Autotools sehe ich aber in nächster Zukunft weder durch qmake, noch durch ein anderes System derart verdrängt, daß ich vollständig darauf verzichten werde. Ich bin dann eher in der Situation, daß ich Autotools sowieso und qmake, eventuell sogar zusammen mit make, einsetzen würde. Das war nur die Situation, welche ich bei der Erwähnung von qmake im Kopf hatte.
Clown schrieb: > Rein theoretisch noch etwas - ob das in der Praxis nun Sinn ergeben > würde, möchte ich vorerst dahingestellt lassen. Fügt der MOC nur > Quelltext hinzu, oder wird bestehender Quelltext modifiziert? Weder noch. Er erzeugt ein zusätzliches File, welches halt auch noch durch den Compiler+Linker muss. > Wenn keine > Modifikation erfolgt, wäre es technisch umsetzbar, auch hier das System > der generierten Basisklassen und manuell geschriebenen > Applikationsklassen umzusetzen? Macht die QT doch schon so. Was meinst du woher die GTK+-Entwickler die Idee dazu hatten ;)
Schorsch schrieb: > Clown schrieb: >> Rein theoretisch noch etwas - ob das in der Praxis nun Sinn ergeben >> würde, möchte ich vorerst dahingestellt lassen. Fügt der MOC nur >> Quelltext hinzu, oder wird bestehender Quelltext modifiziert? > > Weder noch. Er erzeugt ein zusätzliches File, welches halt auch noch > durch den Compiler+Linker muss. Das ist soweit klar. Meine Frage bezieht sich auf den Inhalt der von MOC erzeugten Datei. Wird mein Quelltext durch MOC erweitert oder verändert, bevor das Ergebnis in die neue Datei geschrieben wird? >> Wenn keine >> Modifikation erfolgt, wäre es technisch umsetzbar, auch hier das System >> der generierten Basisklassen und manuell geschriebenen >> Applikationsklassen umzusetzen? > > Macht die QT doch schon so. > Was meinst du woher die GTK+-Entwickler die Idee dazu hatten ;) Na, dann sind die Unterschiede schon wieder etwas kleiner geworden. Die Diskussion, wer von wem inspiriert wurde, können wir vielleicht eines Tages in einem anderen Thread führen... :-)
Clown schrieb: > Das ist soweit klar. Meine Frage bezieht sich auf den Inhalt der von MOC > erzeugten Datei. Wird mein Quelltext durch MOC erweitert oder verändert, > bevor das Ergebnis in die neue Datei geschrieben wird? Es werden BEIDE Dateien Compiliert. Deine. Unverändert. Und die vom MOC generierte, dort ist halt das "Meta-Object" definiert, String-Constanten für die SLOT-Namen usw. d.H. in der MOC-Datei ist nur Zusätzlicher Code, keine Kopie deines Codes.
"Unverändert" in dem Sinne, das der MOC da nichts daran herumwurschtelt. Die QT-Header, die du includieren musst, definieren einige Macros, und der normale C-Präprozessor wurschtelt dann in deinem Code rum.
Du bist mir vielleicht ein Spaßvogel. Assembler in einer kommerziellen Software mit GUI? Da kann ich nur lachen. Oder mal eben einen kleinen TcpIp- Netzwerkstack in Assembler programmieren? Das möchte ich mal sehen. Und wenn, dann mußt du da massenweise Betriebssystemfunktionen ansprechen die auch meistens in c oder c++ geschrieben wurden. Aber vielleicht bist du ja in der Raumfahrt, da gelten sicher andere Verhältnisse. Aber auf einem normalen PC? Assembler nur wenns wirklich um die Wurst geht.
Das war eben für den Beitrag von Enno gedacht.
Ja, das meinte ich eingangs zu Enno auch. Gemeldet hat er sich seitdem nicht mehr hier im Thread.
Was ist von LISP im Vergleich von Java zu halten? http://www.youtube.com/watch?v=HM1Zb3xmvMc Kann mir jemand kurz die Vorteile erklären?
chris schrieb: > Was ist von LISP im Vergleich von Java zu halten? > http://www.youtube.com/watch?v=HM1Zb3xmvMc > > Kann mir jemand kurz die Vorteile erklären? Auch wenn deine Frage nicht ganz zum Thread-Thema passt: Hier ist ganz kurz der Hauptvorteil erklärt: Lisp ist flexibler als Java. Im Video findest du ein paar weitere Vorteile, in dem im Video beworbenen Buch sicher noch einige mehr :) Hier sind noch ein paar Zitate, die das Wesen von Lisp kurz beschreiben: Aus "Lisp is a Chameleon" (CACM, September 1991) von John Foderaro: "Lisp is a programmable programming language." einen Auszug aus dem Artikel gibt es hier: http://www.paulgraham.com/chameleon.html Aus "What Made Lisp Different" von Paul Graham: "The whole language always available. There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime." http://www.paulgraham.com/diff.html Aus "XKCD: Lisp" von Randall Munroe: "Truly, this was the language from which the Gods wrought the universe!" http://xkcd.com/224/ ... ok, Perl ist also auch nicht schlecht :) Falls du an einer weitergehenden Diskussion zu diesem Thema interessiert bist, startest du dafür am besten einen neuen Thread, damit dieser hier nicht zu sehr entzweit wird.
So, ich hab mich dann für QT entschieden. Jedoch weiß ich noch nicht, welche IDE ich einsetzten werde. Am besten scheint wohl "Visual Studios" zu sein, jedoch hab ich nur die kostenlose Express-Version, in der ja leider das QT-PlugIn nicht läuft. Und Geld für die Professionell-Version hab ich leider nicht so wirklich. Eclipse hab ich mir schon angeschaut, sieht aber alles sehr kompliziert aus... :/ Von daher wollte ich mal Fragen, ob einer Erfahrung mit dem QT Creator hat. Ist ja mittlerweile Version 2.0 und sieht recht nett aus. Evtl. könnte da ja einer mal seine Erfahrungen postet, ob der auch z.B. für größere Projekte was taugt.
> QtCreator ist die Wahrheit.
Steht das auf der Verpackung?
:-)
den gibts nicht in Schachteln zu kaufen.
> den gibts nicht in Schachteln zu kaufen.
Seit wann ist denn Werbung an Verkauf gebunden, ebenso wie Marketing
Sprüchlein wie deines?
Verpackung ist für mich ein materieller Gegenstand, den man in die Hand nehmen kann.
> Verpackung ist für mich ein materieller Gegenstand, den man in die Hand > nehmen kann. Und das macht dein Sprüchlein "QtCreator ist die Wahrheit" jetzt besser?
Damit habe ich die Frage beantwortet, warum es nicht auf der Schachtel steht. Meine Aussage hat den gleichen Wahrheitswert wie "Am besten scheint wohl "Visual Studios" zu sein"
Ach Axel komm .. hättest du mal etwas sinnvolles zu diesem Thread beigetragen, anstatt dich an Julian's Vorliebe hochzuziehen. Was sollen denn solche Eskapaden? Neidkomplexe weil einer mal Visual Studio gut findet? Minderwertigkeitskomplex weil nicht gleich wieder die OSS in den Himmel gelobt wird?
Ich hab mal einige Jahre Geld mit Qt programmieren verdient und da einige IDEs ausprobiert und Einigkeit ist erst eingekehrt, als der Creator auf dem Markt war. Ich hindere niemand da drann, VS einzusetzen, nur würde ich das niemand empfehlen, der neu einsteigt und Visual Studio bisher nicht eingesetzt hat, weil wie Julian schon sehr richtig festgestellt hat, dort die Integration nicht funktioniert. Nun könnte man entweder Geld auf den Tisch legen, eine Version von der Uni organisieren oder basteln, nur würde ich das niemand empfehlen, der eben gerne Qt programmieren will und nicht ins Plugins-Schreiben für VS einsteigen will. Vielleicht kannst du mir aber noch auf die Sprünge helfen und mir zeigen, wo du hier was sinnvolles geschrieben hast?
Und warum sagst du das nicht gleich, anstatt hier erst mal mit Sprüchlein wie "QtCreator ist die Wahrheit" herumzuprollen? > Vielleicht kannst du mir aber noch auf die Sprünge helfen und mir > zeigen, wo du hier was sinnvolles geschrieben hast? Aber gerne, ich würde mir an Julian's Stelle erst gar nicht antun unbedingt plattformunabhängigkeit durchzudrücken, zumal wenn man bereits mit den MS Visual Tools ganz gut zurecht kommt. Warum sollte ich es mir unnötig schwer machen? Auf den einen Seite wollt ihr mit der Brechstange und ohne Not (eher aus ideologischen Gründen heraus) weg von Windows und dann merkt man plötzlich, dass man sich damit erst recht neue Probleme einhandelt und sich selber ins Knie schießt. Mir ist das völlig unbegreiflich, aber jeder wie er will (und wie er kann).
Du möchtest also den Kunden gerne belehren, dass du seine Anforderungen nicht für sinnvoll hälst? Aber um dir mal ein paar Argumente zu geben, warum plattformunabhängige Programmierung sinnvoll ist: Ich bastel seit einiger Zeit an einer Lichtsteuerungssoftware. Die ist mit Qt implementiert. Ich entwickle sie auf nem Mac, ein Kumpel steuert eine Komponente bei, die er auf Linux entwickelt und der Masterplan ist, dass der immer-an-Teil auf einer Fritzbox laufen wird. Auf der läuft ein Linux. Also geh ich her, kompilier mir ein subset von Qt für die Fritzbox zusammen und schon läuft die Lichtsteuerung da. Ohne GUI natürlich, weil ich keinen Monitor da dran habe, aber eben der Core-Teil und ein Webinterface. Es gibt außerdem auch zahlende Kunden, die eben gerne eine Software für mehrere Plattformen anbieten möchten, ohne große Teile davon neu zu schreiben. Um ein Beispiel zu nennen: Eagle ist mit Qt implementiert und läuft hier auf dem Mac und bei uns in der Uni auf Windows hervorrragend. Ich gehe davon aus, auf Linux auch, aber das hab ich selber noch nicht ausprobiert.
Gelegenheitsprogrammierer schrieb: > Aber gerne, ich würde mir an Julian's Stelle erst gar nicht antun > unbedingt plattformunabhängigkeit durchzudrücken, zumal wenn man bereits > mit den MS Visual Tools ganz gut zurecht kommt Ja, aber nur, weil ich in C# programmiert habe. Gut, für QT scheint es auch PlugIn's zu geben, dafür muss man sich aber für viel Geld die Professionell-Version kaufen. Bisher habe ich halt auch noch mit der Express-Version Erfahrung gesammelt, die halt eben ein paar Einschränkungen hat. Und Plattformunabhängigkeit ist eben für mich ein wichtiges Kriterium, zum ersten mache ich viele Erfahrungen (positiv sowohl bestimmt auch negativ) und zweitens kann ich, wenn ich schon in C++ programmiere, auch gleich durch den Einsatz geeigneter Frameworks plattformunabhängig programmieren. Ob ich jetzt mit MFC oder QT anfange, ist doch im Grunde egal, nur QT bietet mir eben viel mehr Möglichkeiten. Ich wollte nur wissen, ob der QT Creator was taugt, da man im Netz leider nicht so viel findet, wenn nur von "älteren" Versionen (v1 und nicht v2). Meist wird immer auf eclipse geschworen, wobei ich kein so Freund von eclipse bin...
> Du möchtest also den Kunden gerne belehren, dass du seine Anforderungen > nicht für sinnvoll hälst? Komm mal runter vondeinem "Kunden .." Geschwafel. Die meisten die solche hier Anfragen stellen, wollen in erster Linie mal etwas programmieren und nicht gleich ein "auf kundenwunsch verkaufsfähiges Produkt" erstellen. Ihr blast immer solche Dinge auf das einem schlecht werden kann. Mal ganz abgesehen davon, ginge es wirklich um kommerzielle Auftragserfüllung und würde mir dann einer erzählen, er hätte nicht das Geld für ein popliges Microsoft Visual Studio, dann würde ich ihm raten doch lieber mit anderen Dingen Geld zu verdienen.
Julian W. (julian-w) schrieb: > Ob ich jetzt mit MFC oder QT anfange, ist doch im Grunde > egal, nur QT bietet mir eben viel mehr Möglichkeiten. Mit MFC würde ich sowieso nicht anfangen. > Ich wollte nur wissen, ob der QT Creator was taugt, da man im Netz > leider nicht so viel findet, wenn nur von "älteren" Versionen (v1 und > nicht v2). Meist wird immer auf eclipse geschworen, wobei ich kein so > Freund von eclipse bin... Von etwas was im Netz nicht sonderlich verbreitet ist würde ich eher die Finger lassen. Denn es hat immer einen Grund, warum Dinge lings liegen gelassen werden und die Mehrheit sich lieber anders orientiert. Ob das beim Creator so ist vermag ich nicht zu beurteilen, da ich ihn nicht benutze. Im übrigen halte ich solche Anfragen wie die deine eher für schwierig und die Antworten werden dir letztlich auch nicht viel bringen. Da spielen zu viele eigene Vorlieben mit ein. Du wirst also nicht umhin kommen und es selbst rausfinden müssen und das kann einiges an Zeit verschlingen ..
An den TO: Falls es doch VS werden soll, die Pro-Version gibt es für Schüler und Studenten kostenlos (www.dreamspark.com/)
Arc Net schrieb: > An den TO: Falls es doch VS werden soll, die Pro-Version gibt es für > Schüler und Studenten kostenlos (www.dreamspark.com/) Nunja, aber leider nur als Student. Ich besuche momentan noch das Gymnasium, da scheint es leider nichts zu geben, zumindest kann ich mich über keine der genannten Möglichkeiten verifizieren (hab keinen "Activation Code" von einem MS-Vertreter bekommen, habe auch keine "ISIC Card" und meine Schule ist online auch nicht aufgeführt).
Es gibt auch 60-Tage Versionen von VS .. Alternativ mal im Bekanntenkreis umhören, ob nicht irgend ein Student(in) dir weiterhelfen kann (kleine Gegenleistung motiviert meistens ;)).
Die VisualStudio Express Versionen sind/waren kostenlos und ohne zeitliche Limitierung von Microsoft per Download erhältlich. Wer kein Microsoft Passport Login anlegen möchte, kann auch die DVD als ISO herunterladen. Für Anwendungen im Studium oder Hobby durchaus zu gebrauchen. Qt, GTK, OpenGL oder einfache Konsolenanwendungen sollten kein Problem sein. Die Verzeichnispfade zu den entsprechenden Bibliotheken müssen gegebenenfalls von Hand eingetragen werden.
So ziemlich die einzige Einschränkung der Visual C++-Express-Version ist das Fehlen der MFC-Unterstützung. Solange man aber keine MFC-Programme erstellen möchte, sondern andere GUI-Klassenbibliotheken wie Qt oder auch wxWidgets damit nutzen will, ist das gut benutzbar.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.