ich habe mir QtJambi bereits vor einigen Monaten angeschaut und es sieht echt Klasse aus. Da ich überwiegend GNOME verwende finde ich es fast schade, dass die GNOME-Jungs so extrem auf Mono setzen, statt auf z.B. Java GNOME, aber naja :)
Also ich kann nur empfehlen sich QtJambi mal anzuschauen. Die Eclipse-Integration sieht auch sehr schick aus.
Von dem irren Paranoiden am Do, 8. Februar 2007 um 08:47 #
Die Gnome-Entwickler werden wahrscheinlich von M$ bezahlt. Wenn genug in Mono entwickelt wurde zücken die Redmonder ihre Patentlisten und dann wird Gnome einfach platt gemacht. Wieder ein Gegner weniger...
btw: Wenn die Entwickler einigermaßen vernünftige Menschen wären, dann würden die mal langsam anfangen aus GTK + QT eine Einheit zu bilden.
Das trolltech monopol hat aber alles unter GPL und verhindert nicht mit Patentabkommen dass es andere im Sinne der GPL verwenden koennen, so wie das mit Mono passiert.
Von dem irren Paranoid am Do, 8. Februar 2007 um 09:35 #
Monopol? Mmmmh, da fällt mir gerade ein... wie bezahlen die das eigentlich alles? Die Entwicklung von QT samt Abkömmlingen kostet doch ein Vermögen, da extrem arbeitsaufwendig... Gibt es darüber Statistiken, Grafiken, Geschäftsberichte etc.? Haben die einen Milliardenschweren Sponsor?
Von dem irren P.... am Do, 8. Februar 2007 um 10:08 #
Ja, das war eine ernst gemeinte Frage.
Dual-Licensing-Model? Nun, kennst Du auch nur *eine* Killeranwendung die auf ein kommerzielles QT setzt? Im Ernst: Ich nicht. :(
Ich bleibe bei meinen Zweifeln der Tragfähigkeit. Ich kann mir nicht vorstellen, dass Firmen QT lizensieren wenn sie z.B. Java völlig kostenlos bekommen können - und damit geht bekanntlich so ziemlich alles was digital ist...
> Nun, kennst Du auch nur *eine* Killeranwendung die auf ein kommerzielles QT setzt? Im Ernst: Ich nicht.
Du hast schon mal von "Google Earth" gehört? Oder von Abobes Photoshop Elements? Du könntest natürlich auch einfach mal bei Trolltech auf den Link "Customers" klicken...
> Nun, kennst Du auch nur *eine* Killeranwendung die auf ein kommerzielles QT setzt?
Nur weil Du keine kennst, heisst das nicht dass es keine gibt. Ausserdem ist ein Grossteil der Software da draussen Individualsoftware oder so speziell, dass der Heimuser sie nie zu Gesicht bekommt. Du darfst gerne Zweifel an der Tragfaehigkeit haben, Trolltechs Bilanz spricht eine klare Sprache ;-)
Zu Java: Jeder der schonmal eine ernstzunehmende UI unter Swing entwickeln musste, wird gerne die paar Kroeten fuer Qt=Lizenzen bezahlen. Das Geld hat man schnell wieder drin, wenn der Entwickler auch nur 20% produktiver wird.
> und damit geht bekanntlich so ziemlich alles was digital ist...
Ja genau, der Markt ist ueberschwemmt von Desktop-Anwendungen in Java. Traeum weiter
Warum GTK + QT? QT alleine reicht doch. Java/Qt hat gegenüber .NET den Riesenvorteil, dass es wirlich plattformunabhängig ist. .NET ist nur auf Windows zugeschnitten und Mono ist IMHO keine ernsthafte Alternative, da es .NET in der Entwicklung immer hinterher hecheln wird.
och man langsam regt mich das halbwissen hier auf [ ] du weisst das CLI und C# ISO standardisiert sind [ ] du weisst was ISO bzgl. Patenten fordert danke...
[ ] du weisst das CLI und C# ISO standardisiert sind [ ] du weisst was ISO bzgl. Patenten fordert
Ich benutze in der Arbeit .Net unter Windows und halte es durchaus fuer ganz brauchbar. Dass CLI und C# ISO standardisiert sind stimmt, aber die .Net Klassenbibliothek ist leider (teilweise) ISO-standardisiert. Soweit ich weiss ist der System-Namespace ISO-standardisiert, der Microsoft-Namespace (der unter anderem Windows.Forms enthaelt) aber z.B. nicht. Und WPF z.B. wird sicher nicht ISO-standardisiert. Solange man also nur Klassen aus dem System-Namensraum verwendet, ist man vor Patentanspruechen seitens Microsoft sicher. Bei Klassen aus anderen Namespaces ist man es nicht.
.Net ist sicher eine sehr gute Technologie, aber leider wird sich wohl Mono nicht wirklich durchsetzen (was eigentlich schade ist). Und der Microsoft-Novell Deal hat der Akzeptanz von Mono wohl auch eher geschadet. Und Miguel de Icaza ist sicher ein genialer Programmierer, aber dass man bei der Suse-Uebernahme durch Novell erstmal alle KDE-Benutzer (und Programmierer) so richtig for den Kopf gestossen hat, war wohl auch eher ungeschickt. Etwas mehr Diplomatie haette meiner Meinung nach der Verbreitung von Mono sicher gutgetan.
zurueck zum ursprung,weder windows.forms noch wpf wird in gnome je verwendet werden...so what? sofern man mono einfach als eine implementierung von paar standards sieht ist die vm brauchbar und c# nicht schlecht..als versuch MS .net nachzubauen und kompatibel zu halten ist es allerdings ungeeignet. daher vergesst doch einfach ms und freut euch ueber ne nette sprache und vm auf unix
jetzt heißt es das alte AWT rauswerfen (Swing geht ja mittlerweile) und stattdessen qtjambi von Trolltech lizensieren und in Java integrieren. Dann steht dem Durchbruch von Java, auch bei Desktopanwendungen, nichts mehr im Wege.
Von Christoph David Hermann am Do, 8. Februar 2007 um 12:36 #
Also ich persönlich empfinde SWT schon als hervorragende Lösung zum GUI programmieren in Java (Ich weiß, nicht von Sun). Da habe ich eine einheiltiche plattformunabhängige API. Zum Zeichnen werden die betriebssystemeigenen Funktionen verwendet. Da sind auch schon schöne Javaschnittstellen wie Java2D integriert. Perfekt
Ich wundere mich ja immer noch, dass Sun damals nicht Tk aus GUI-API in Java eingebaut hat, sondern das (alte) AWT, das ja einige Zeit danach schon durch Swing ersetzt werden musste, programmiert hat. Dabei hatte Sun den Tcl/Tk-Erfinder, John Ousterhout, damals gerade bei sich angestellt! (Und ihn nicht lange danach wieder entlassen...) Tk ist von API und Implementierung her einfach genial. (Die Sprache Tcl ist nicht so toll, aber Tk kann man ja recht problemlos auch unabhängig von Tcl benutzen)
Wenn Java von Anfang an auf Tk gesetzt hätte, hätte das "Java auf dem Desktop" schon frühzeitig einen Riesenschub gegeben. Stattdessen gibt es jetzt mit AWT, Swing, SWT und QtJambi jetzt schon alleine vier Versuche, API und Implementierung für "Desktop-Java" neu zu erfinden... :-(
Nachdem John Ousterhout, wohl auch wegen der Entscheidung für AWT als Java-GUI, Sun verlassen hat, stagniert übrigens die Weiterentwicklung von Tcl und Tk. Wenn man sich vorstellt, wo Tk heute, fast 10 Jahre danach, stehen könnte... vermutlich könnte man dann in Tk (plattformunabhängige!) Features, die es heute im Open-Source-Umfeld praktisch nur bei Qt gibt - allerdings nochmal *deutlich* komfortabler als Qt...
(Durchgesetzt haben sich immerhin etliche der neuen oder von Ousterhout perfektionierten Tk-Konzepte, die in fast alle modernen Toolkits Eingang gefunden haben, wie z.B. abstrahierte/wählbare Layout-Manager, ein objektbasiertes "Canvas"-System, Rich-Text-Felder mit CSS-ähnlichem Tagging, usw.)
> Stattdessen gibt es jetzt mit AWT, Swing, SWT und QtJambi jetzt schon alleine vier Versuche, API und Implementierung > für "Desktop-Java" neu zu erfinden...
Fuer C und C++ gibt es noch ungleich mehr Toolkits, und das hat die Welt nicht davon abgehalten, einen Grossteil der heutigen Desktopanwendungen in diesen Sprachen zu schreiben
Von M wie Meikel am Fr, 9. Februar 2007 um 10:13 #
> Ich wundere mich ja immer noch, dass Sun damals nicht Tk aus GUI-API in Java eingebaut hat, sondern das (alte) AWT, das ja einige Zeit danach schon durch Swing ersetzt werden musste, programmiert hat.
Hmm, mag ja sein, dass Tk ein paar interessante Konzepte unter der Haube hatte, aber es ist in meiner Erinnerung weder besonders mächtig gewesen und definitiv ziemlich häßlich. Auch war der Port nach Perl lange Zeit ein ziemlicher Krampf. Das hat IMHO schon einige selbstgemachte Gründe, dass Tk nicht über längere Zeit erfolgreich geworden ist.
Dass mit Java 1.2 dann Swing kam, hat wohl weniger mit den technischen Möglichkeiten von AWT zu tun gehabt, sondern wohl eher politische Gründe. Da gibt es Geschichten, dass ehemalige Smalltalk-Entwickler bei Sun sich mit ihrer Idee durchgesetzt haben, dass man plattformabhängigke GUIs nicht direkt auf den Plattformwidgets aufsetzen sollte. Wer weiß, wie ein ständig aktualisiertes AWT heute aussehen würde.
Und dass Dritte so etwas wie SWT, Cocoa-, Qt- oder GTK-Bindings entwickeln, liegt ja nicht an Sun. Swing ist der gesetzte Favorit und da scheint sich in absehbarer Zeit auch nichts dran zu ändern.
Tk war nie für grosse Applikationen gedacht, es war dazu dazu Scripte mit ner simplen GUI (Konfig-Auswahldialoge,... ) zu verheiraten. Der Krampf mit Tk geht schon los wenn man die einzelenen Komponenten auffhübschen oder erweitern will, da wird der einst kompakte Code schnell unübsichtlich und auch zunehmend sperriger, da merkt man dann was in Tk alles fehlt. Deshalb gab es schnell zig inoffizielle Erweiterungen.
Sun tat gut daran sich von Tk fern zu halten oder man hätte ne Entwicklertruppe dafür abgestellt die das nochmal komplett überarbeitet. Tk ist über all die Jahre auch deshalb nicht grossartig weiterentwickelt worden weil die Leute fehlen, kein Vergleich zu dem was Sun an Personal an Swing abbestellte, obwohl da auch vieles schnell zusammengebastelt wurde. Im Java Developers Journal gab es eine Umfrage an die Entwickler von Java (Gosling, einige die mit der Swingentwicklung zu tun hatten,...) was sie an Swing anders machen würden wenn sie es nochmal komplett neu entwickeln könnten. Interessant bei den Antworten ist, dass vieles was damals als Vorteil von Swing heute von den Swingvätern eher als Nachteil gesehen wird, gleichzeitig aber die Fanboys immer noch diese "Vorteile" von Swing propagieren.
Dass mit Java 1.2 dann Swing kam, hat wohl weniger mit den technischen Möglichkeiten von AWT zu tun gehabt, sondern wohl eher politische Gründe. Da gibt es Geschichten, dass ehemalige Smalltalk-Entwickler bei Sun sich mit ihrer Idee durchgesetzt haben, dass man plattformabhängigke GUIs nicht direkt auf den Plattformwidgets aufsetzen sollte. Wer weiß, wie ein ständig aktualisiertes AWT heute aussehen würde.
AWT kann und konnte früher bestimmte Dinge nicht. So warend und sind Icons in Buttons nicht möglich. Das liegt dadran, daß AWT nur das anbietet, was das jeweilige Betriebssystem auch native kann. Um sich stärker von der Abhängigkeit der Plattform zu lösen, hatte Netscape früher die Internet Foundation Classes (IFC) erstellt. Sun fand die Idee prima und hatte dann zusammen mit Netscape Swing entwicklet.
Und AWT und Swing sind nun mal die beiden Extreme unter Java. AWT besteht nur aus nativem Look and Feel. Swing hingegen besteht (wenn es das MetalLookAndFeel ist) nur aus plattformunabhägigem Look and Feel. Und die plattformanhängigen LAFs wurden nur wegen des Erfolgs fon SWT nachgeschoben.
ich habe mir QtJambi bereits vor einigen Monaten angeschaut und es sieht echt Klasse aus. Da ich überwiegend GNOME verwende finde ich es fast schade, dass die GNOME-Jungs so extrem auf Mono setzen, statt auf z.B. Java GNOME, aber naja :)
Also ich kann nur empfehlen sich QtJambi mal anzuschauen. Die Eclipse-Integration sieht auch sehr schick aus.
Gruß
Mike
btw: Wenn die Entwickler einigermaßen vernünftige Menschen wären, dann würden die mal langsam anfangen aus GTK + QT eine Einheit zu bilden.
und verhindert nicht mit Patentabkommen dass es
andere im Sinne der GPL verwenden koennen, so wie
das mit Mono passiert.
lg
Erik
Haben die einen Milliardenschweren Sponsor?
lg
Erik
Dual-Licensing-Model? Nun, kennst Du auch nur *eine* Killeranwendung die auf ein kommerzielles QT setzt? Im Ernst: Ich nicht. :(
Ich bleibe bei meinen Zweifeln der Tragfähigkeit. Ich kann mir nicht vorstellen, dass Firmen QT lizensieren wenn sie z.B. Java völlig kostenlos bekommen können - und damit geht bekanntlich so ziemlich alles was digital ist...
Opera, Adobe Photoshop Elements, Google Earth, Mainactor, Skype, ...
Schau doch am besten selbst nach.
lg
Erik
Da freue ich mich schon drauf, obwohl ich es bezahlen muss.
lg
Erik
Denn das ist hier anders als bei Nutella! Nicht überall wo nicht QT drauf steht ist auch nicht QT drin
Du hast schon mal von "Google Earth" gehört? Oder von Abobes Photoshop Elements?
Du könntest natürlich auch einfach mal bei Trolltech auf den Link "Customers" klicken...
Nur weil Du keine kennst, heisst das nicht dass es keine gibt. Ausserdem ist ein Grossteil der Software da draussen Individualsoftware oder so speziell, dass der Heimuser sie nie zu Gesicht bekommt.
Du darfst gerne Zweifel an der Tragfaehigkeit haben, Trolltechs Bilanz spricht eine klare Sprache ;-)
Zu Java: Jeder der schonmal eine ernstzunehmende UI unter Swing entwickeln musste, wird gerne die paar Kroeten fuer Qt=Lizenzen bezahlen. Das Geld hat man schnell wieder drin, wenn der Entwickler auch nur 20% produktiver wird.
> und damit geht bekanntlich so ziemlich alles was digital ist...
Ja genau, der Markt ist ueberschwemmt von Desktop-Anwendungen in Java. Traeum weiter
[ ] du weisst das CLI und C# ISO standardisiert sind
[ ] du weisst was ISO bzgl. Patenten fordert
danke...
[ ] du weisst was ISO bzgl. Patenten fordert
Ich benutze in der Arbeit .Net unter Windows und halte es durchaus fuer ganz brauchbar. Dass CLI und C# ISO standardisiert sind stimmt, aber die .Net Klassenbibliothek ist leider (teilweise) ISO-standardisiert. Soweit ich weiss ist der System-Namespace ISO-standardisiert, der Microsoft-Namespace (der unter anderem Windows.Forms enthaelt) aber z.B. nicht. Und WPF z.B. wird sicher nicht ISO-standardisiert. Solange man also nur Klassen aus dem System-Namensraum verwendet, ist man vor Patentanspruechen seitens Microsoft sicher. Bei Klassen aus anderen Namespaces ist man es nicht.
.Net ist sicher eine sehr gute Technologie, aber leider wird sich wohl Mono nicht wirklich durchsetzen (was eigentlich schade ist). Und der Microsoft-Novell Deal hat der Akzeptanz von Mono wohl auch eher geschadet. Und Miguel de Icaza ist sicher ein genialer Programmierer, aber dass man bei der Suse-Uebernahme durch Novell erstmal alle KDE-Benutzer (und Programmierer) so richtig for den Kopf gestossen hat, war wohl auch eher ungeschickt. Etwas mehr Diplomatie haette meiner Meinung nach der Verbreitung von Mono sicher gutgetan.
Da fehlt natuerlich ein nur:
...leider nur (teilweise) ISO-standardisiert.
sofern man mono einfach als eine implementierung von paar standards sieht ist die vm brauchbar und c# nicht schlecht..als versuch MS .net nachzubauen und kompatibel zu halten ist es allerdings ungeeignet. daher vergesst doch einfach ms und freut euch ueber ne nette sprache und vm auf unix
qtjambi von Trolltech lizensieren und in Java integrieren. Dann steht dem Durchbruch von
Java, auch bei Desktopanwendungen, nichts mehr im Wege.
Ich wundere mich ja immer noch, dass Sun damals nicht Tk aus GUI-API in Java eingebaut hat, sondern das (alte) AWT, das ja einige Zeit danach schon durch Swing ersetzt werden musste, programmiert hat. Dabei hatte Sun den Tcl/Tk-Erfinder, John Ousterhout, damals gerade bei sich angestellt! (Und ihn nicht lange danach wieder entlassen...) Tk ist von API und Implementierung her einfach genial. (Die Sprache Tcl ist nicht so toll, aber Tk kann man ja recht problemlos auch unabhängig von Tcl benutzen)
Wenn Java von Anfang an auf Tk gesetzt hätte, hätte das "Java auf dem Desktop" schon frühzeitig einen Riesenschub gegeben. Stattdessen gibt es jetzt mit AWT, Swing, SWT und QtJambi jetzt schon alleine vier Versuche, API und Implementierung für "Desktop-Java" neu zu erfinden... :-(
Nachdem John Ousterhout, wohl auch wegen der Entscheidung für AWT als Java-GUI, Sun verlassen hat, stagniert übrigens die Weiterentwicklung von Tcl und Tk. Wenn man sich vorstellt, wo Tk heute, fast 10 Jahre danach, stehen könnte... vermutlich könnte man dann in Tk (plattformunabhängige!) Features, die es heute im Open-Source-Umfeld praktisch nur bei Qt gibt - allerdings nochmal *deutlich* komfortabler als Qt...
(Durchgesetzt haben sich immerhin etliche der neuen oder von Ousterhout perfektionierten Tk-Konzepte, die in fast alle modernen Toolkits Eingang gefunden haben, wie z.B. abstrahierte/wählbare Layout-Manager, ein objektbasiertes "Canvas"-System, Rich-Text-Felder mit CSS-ähnlichem Tagging, usw.)
> für "Desktop-Java" neu zu erfinden...
Fuer C und C++ gibt es noch ungleich mehr Toolkits, und das hat die Welt nicht davon abgehalten, einen Grossteil der heutigen Desktopanwendungen in diesen Sprachen zu schreiben
Hmm, mag ja sein, dass Tk ein paar interessante Konzepte unter der Haube hatte, aber es ist in meiner Erinnerung weder besonders mächtig gewesen und definitiv ziemlich häßlich. Auch war der Port nach Perl lange Zeit ein ziemlicher Krampf. Das hat IMHO schon einige selbstgemachte Gründe, dass Tk nicht über längere Zeit erfolgreich geworden ist.
Dass mit Java 1.2 dann Swing kam, hat wohl weniger mit den technischen Möglichkeiten von AWT zu tun gehabt, sondern wohl eher politische Gründe. Da gibt es Geschichten, dass ehemalige Smalltalk-Entwickler bei Sun sich mit ihrer Idee durchgesetzt haben, dass man plattformabhängigke GUIs nicht direkt auf den Plattformwidgets aufsetzen sollte. Wer weiß, wie ein ständig aktualisiertes AWT heute aussehen würde.
Und dass Dritte so etwas wie SWT, Cocoa-, Qt- oder GTK-Bindings entwickeln, liegt ja nicht an Sun. Swing ist der gesetzte Favorit und da scheint sich in absehbarer Zeit auch nichts dran zu ändern.
es war dazu dazu Scripte mit ner simplen GUI (Konfig-Auswahldialoge,... ) zu verheiraten.
Der Krampf mit Tk geht schon los wenn man die einzelenen Komponenten auffhübschen oder erweitern will,
da wird der einst kompakte Code schnell unübsichtlich und auch zunehmend sperriger, da merkt man dann
was in Tk alles fehlt. Deshalb gab es schnell zig inoffizielle Erweiterungen.
Sun tat gut daran sich von Tk fern zu halten oder man hätte ne Entwicklertruppe dafür abgestellt die das
nochmal komplett überarbeitet. Tk ist über all die Jahre auch deshalb nicht grossartig weiterentwickelt worden weil die Leute fehlen, kein Vergleich zu dem was Sun an Personal an Swing abbestellte, obwohl da auch vieles schnell zusammengebastelt wurde.
Im Java Developers Journal gab es eine Umfrage an die Entwickler von Java (Gosling, einige die mit der Swingentwicklung zu tun hatten,...) was sie an Swing anders machen würden wenn sie es nochmal komplett neu entwickeln könnten.
Interessant bei den Antworten ist, dass vieles was damals als Vorteil von Swing heute von den Swingvätern eher als Nachteil gesehen wird, gleichzeitig aber die Fanboys immer noch diese "Vorteile" von Swing propagieren.
AWT kann und konnte früher bestimmte Dinge nicht.
So warend und sind Icons in Buttons nicht möglich. Das liegt dadran, daß AWT nur das anbietet, was das jeweilige Betriebssystem auch native kann.
Um sich stärker von der Abhängigkeit der Plattform zu lösen, hatte Netscape früher die Internet Foundation Classes (IFC) erstellt. Sun fand die Idee prima und hatte dann zusammen mit Netscape Swing entwicklet.
Und AWT und Swing sind nun mal die beiden Extreme unter Java.
AWT besteht nur aus nativem Look and Feel.
Swing hingegen besteht (wenn es das MetalLookAndFeel ist) nur aus plattformunabhägigem Look and Feel. Und die plattformanhängigen LAFs wurden nur wegen des Erfolgs fon SWT nachgeschoben.
Mir fehlt bei Swing eigentlich nichts.
http://www.trolltech.com/pdf/jambi-whitepaper-a4.pdf
Angeblich vereinfacht Jambi die Entwicklung.
Als Beispiel:
Ein Slider-Demo in Swing:
slider.addChangeListener(new ChangeListener() {
public void stateChanged(ChangeEvent e) {
spinner.setValue(slider.getValue());
}
});
spinner.addChangeListener(new ChangeListener() {
public void stateChanged(ChangeEvent e) {
slider.setValue((Integer)spinner.getValue());
}
});
Selbiges mit Jambi:
slider.valueChanged.connect(spinBox, "setValue(int)");
spinBox.valueChanged.connect(slider, "setValue(int)");
Zugegeben, ist es nur ein Beispiel. Aber Trolltech lobt sich in dem Withepaper selber über den grünen Klee.