Freies Swing replacement:Native oder binär-kompatibel, was ist euch wichtiger??

[Lin728]

Wie vieleicht ein paar von euch schon mitbekommen haben, arbeite ich und ein anderer gerade an einer SWING-Implementierung für den gcj, so dass man bald auch kompilierte Programme mit swing-oberfläche schreiben können sollte.

Kurz und gut: Was ist ech wichtiger?

Mfg

[peschmae]

ich bin natürlich schon aus Prinzip für fltk... :D

allerdings unterstützen die Widgets wohl kein HTML und das gibt Arbeit...

QT ist natürlich realistischer, abgesehen davon dass das Projekt selbst unrealistisch ist ;-)

MfG Peschmä

[anda_skoa]

Original geschrieben von ceisserer
Was würde ihr von einem swing halten, bei dem die ganzen Oberklassn (JFrame, JButton,...) fast gleich sind, aber halt das interne Design und die classen-hirachie total anders ist.
Ich hätte da noch an native Widgets gedacht, so dass dann diese SWING-Programme echte QT-Programme sind und sich voll in den KDE3-Desktop integrieren.


Versteh ich nicht ganz.
Wenn es kein SWING ist, wie unterscheidet es sich dann von den vorhandenen Bindings, zb qtjava/kdejava?



hat, dauert es mindestens 3 Jahre, und wer weiß wo sun danns chon wieder ist.

Java2 gabs jetzt ewig :)
Die nächste Stufe hält sicher auch wieder einige Jahre.



Wenn man jedoch gleich davon ausgeht, dass man nicht 100%ig kompatibel sein kann (Der code sollte ohne änderungen auf dem Sun-JDK trotzdem laufen aber nicht umgekehrt), kann man sich auf nützlichere Sachen konzentrieren.


Versteh ich da richtig:
Ein Programm, das dieses neue Toolkit benutzt, kann auch ohne dieses Toolkit laufen, aber ein SWING Programm läuft nicht unbedingt mit dem neuen Toolkit?
Also, dass die API des neuen Toolkits eine Untermenge der SWING API ist?

Kannst du vielleicht ein Beispiel geben, wie der Unterschied in etwa aussähe?

Ciao,
_

[SeeksTheMoon]

Ich wäre dafür, dass es kompatibel ist. Es hat zwar diverse Vorteile, wenn es nativ umgesetzt wird und sinnvoller strukturiert ist, aber ich möchte für Java Programme keine andere Hirarchie, die vom Sun-Standard abweicht, denn Java soll halt einmal kompiliert überall laufen und wenn man den Quellcode ändern müsste, das wäre weniger gut.

Nicht dass ich die offizielle Struktur gut fände (es wird mal langsam Zeit für eine Umstrukturierung der java und javax-Pakete, wo dann auch gleich die deprecated-Sachen wegfallen können - dann hätten wir ja schon Java 3, oder?), aber es sollte auf allen Systemen einheitlich sein.

Den Faktor "hässlich" kann man ja mit Look-And-Feels (z.B. dem Kunststoff L&F von www.incors.org) ausgleichen. Wenns ein wenig schneller gehen soll, kann man ja AWT oder SWT nehmen.

Vielleicht wäre ja folgendes denkbar:
Ihr macht ein komplett Sun-Kompatibles SWING für den GCJ und dann noch (separat) eine SWT-Erweiterung für QT, falls das lizenzmäßig, zeitmäßig, oder ohne sonstige Probleme geht.
Ich kenne mich mit SWT nicht so aus, aber ich denke, dass das so in die Richtung geht, was Du Dir vorstellst. Bisher läuft es ja leider nur auf gnome2 und Windows. Wenn noch QT dazu käme, das wäre sicher nicht schlecht.

[Lin728]

@anda_skoa:
Ich habe mir gedacht, dass man die TopLevel-klassen mit denen der user ja hauptsächlich arbeitet kompatibel macht, somit muss man keine neue api lernen und außerdem kann man swing-gui builder weiterhin verwenden.

Mal sehen was sich machen lässt...

Mfg

[anda_skoa]

Original geschrieben von ceisserer
@anda_skoa:
Ich habe mir gedacht, dass man die TopLevel-klassen mit denen der user ja hauptsächlich arbeitet kompatibel macht, somit muss man keine neue api lernen und außerdem kann man swing-gui builder weiterhin verwenden.


Ich denke, jetzt versteh ich es.

Es ist also praktisch eine alternative SWING Implementierung, die aber nicht wie das "echte" SWING auf AWT aufbaut, sondern direkt auf Native Komponenten.

Praktisch wie Bindings nur mit SWING API, richtig?

Ciao,
_

[Lin728]

@anda_skoa:
Ja genau!

[anda_skoa]

Hmm, Klassenhierachie würde wahrscheinlich auch noch gehen.
Man muss ja nicht unbedingt die Funktionalität in der selben Ebene implementieren.

Die Idee find ich gut!

Cool wäre natürlich, wenn damit programmierte und kompilierte Programm auch auf einer normalen JVM mit normalen SWING laufen würden, also ohne rekompilieren.

Jeder der eine entsprechened Laufzeitumgebung hat, würde automatisch in den Genuss der Verbesserungen kommen, aber die Applikation wäre auch sonst noch einsatzfähig.

Ciao,
_

[Lin728]

Hmm, freut mich, dass du meiner Idee was abgewinnen kannst!

Thx

[anda_skoa]

Ich denke Lizenztechnisch sollte das kein Problem sein.
Die KDELIBs sind ja auch LGPL.

Wahrscheinlich ist das mit der QPL abgedeckt.

Du kannst ja mal schaun, wie die QtJava Bindings Lizensiert sind.

Das mit den Packages ist blöd, daran hab ich nicht gedacht :(

D.h. man bräuchte dann das neue Toolkit nochmal mit SWING Backend.
Sollte mit einer einfache Bridge möglich sein, aso nur Methoden forwarden.

Schneller wirds dadurch aber sicher ned :p

Wie läuft denn das beim GNU Classpath?
Die müssen ja auch java. Packages machen, oder?

Ciao,
_

[Lin728]

So, bin jetzt durch die Apidocs gebrowst und hab mir einen überblick verschafft was die einzelnen Classen so machen

Was anderes:
In Java kann man ja jede gui-klasse ableiten und z.B. ihre paint-methode überschreiben. Ich hätte mir gedacht man könnte das so machen.
Jedes Widget ist in wirklichkeit von grund auf ein Canvas, erst wenn die interne paint-methode aufgerufen wird, wird das Canvas durch das native pedant ausgewechselt.
Also man hat einen "Pointer" der zuerst zum Canvas zeigt und erst von der paint-methode auf das echte widget gesetzt wird..
Wird diese Methode nun überschrieben, steht wie bei java üblich ein ganz normales canvas zur verfügung.
Was halt dann nicht lustig ist, ist das unterschiedliche Event-Handling...

Mfg

[anda_skoa]

Original geschrieben von ceisserer
So, bin jetzt durch die Apidocs gebrowst und hab mir einen überblick verschafft was die einzelnen Classen so machen, O.K., ich bin noch sehr weit unter in der Klassenhierachie (java.awt.Component) aber bis jetzt lässt sich das meiste eigentlich ohne große Verrenkungen programmieren.


Cool!


Jedoch bin ich mir nicht wirklich sicher, was ich nun nehmen soll. Die QT-Bindings haben den Nachteil, dass Sie riesig sind, und dass sie wahrscheinlich zu einem ziemlich großen memory-footprint führen würden (~20mB) falls man sie mit dem GCJ kompiliert.


Hmm, nicht kompiliert haben Qt Bindings und KDE Bindungs zusammen bei mir ca 12MB.
Nicht kompiliert heißt lib+jar



Außerdem ist GTK2 schneler als QT2 oder 3.

:)
wie misst man das?



Andererseits hat mittlerweile QT eine größere Verbreitung als GTK2, dafür ist die Windows-Portieung von der GTK-Version einfacher...

Warum ist die Windows Portierung einfacher?



Also falls noch wer irgendwelche Vorlieben hat, kann er sie jetzt posten, ich tendiere derzeit eher zu GTK2. Falls wer triftige Gründe dagegen vorbringen will, ich freu mich über jedes feedback!


Ich denke nicht, dass es triftige Gründe für etwas gibt, außer, mit was du dir leichter tust.
Das sollte immer der Hauptwahrgrund sein.



In Java kann man ja jede gui-klasse ableiten und z.B. ihre paint-methode überschreiben. Ich hätte mir gedacht man könnte das so machen.
Jedes Widget ist in wirklichkeit von grund auf ein Canvas, erst wenn die interne paint-methode aufgerufen wird, wird das Canvas durch das native pedant ausgewechselt.
Also man hat einen "Pointer" der zuerst zum Canvas zeigt und erst von der paint-methode auf das echte widget gesetzt wird..
Wird diese Methode nun überschrieben, steht wie bei java üblich ein ganz normales canvas zur verfügung.


Ich glaube, die meisten Components werden so benutzt wie sie sind, außer Panel und vielleicht noch Frame.

Ich kenne niemanden, der paint von JFileChooser überschreiben würde.



Was halt dann nicht lustig ist, ist das unterschiedliche Event-Handling...


Ist das wirklich so unterschiedlich?

Ich muss zugeben, dass ich noch nicht sehr viel mit SWING gearbeitet habe, aber die API ist ziemlich Qt ähnlich zumindest aus meiner Sicht als Qt Entwickler.

Bei Qt kommen zB Mouse Events über virtuelle Methoden des Widgets.
In so einer Methode die Methode aller gespeicherten MouseListener aufzurufen, dürfte nicht so schwer sein.

Ciao,
_

[Lin728]

Hi anda_skoa!



Hmm, nicht kompiliert haben Qt Bindings und KDE Bindungs zusammen bei mir ca 12MB.
Nicht kompiliert heißt lib+jar

Das meine ich. Jetzt sind aber lib+jar noch viel kleiner als lib+gcjlib.



Warum ist die Windows Portierung einfacher?

Für QT/Windows muss man eine Version von VCC6/7 haben, das ist lizenzrechtlich so festgelegt.
Bei GTK2 für Windows gibts Binaries die mit mingw erstellt werden.



Ich denke nicht, dass es triftige Gründe für etwas gibt, außer, mit was du dir leichter tust.
Das sollte immer der Hauptwahrgrund sein

Das haben sich die von Sun auch gedacht, als sie sich entschieden haben das AWT fallen zu lassen und nun alles lightweight zu machen.



Ich glaube, die meisten Components werden so benutzt wie sie sind, außer Panel und vielleicht noch Frame.
Ich kenne niemanden, der paint von JFileChooser überschreiben würde.

Stimmt schon, es geht nur drum zu schaun, dass man eventuell das Design so auslegt, dass man nachher kompatibel sein kann.
Ich habe z.B. keine Ahnung wie ich ein Panel berschreiben lassen könnte, wo doch im Panel andere Komponenten "wohnen".
Also ist der derzeitige Ansatz mist, ich kann doch nicht einen Button in ein Canvas reinschreiben.


Was denkst du, wäre es eventuell ein Fehler das design so auszulegen, dass man nicht ableiten kann?
Ich hab mir dass jetzt ziemlich genau durch den Kopf gehen lassen, aber mir fällt einfach nicht ein, wie es mit vertretbaren Aufwand möglich sein sollte, dies möglich zu machen.
Da reicht nämlich kein einfacher Api-Wrapper...

Mfg

[anda_skoa]

Original geschrieben von ceisserer

Das meine ich. Jetzt sind aber lib+jar noch viel kleiner als lib+gcjlib. Kannste vorstellen, was das fürn Speicherverbrauch bedeutet.

Hmm, wußte nicht, das da soviel dazukommt.
Aber die JVM braucht ja auch nicht wenig Speicher, un die fällt dan weg, oder?



Für QT/Windows muss man eine Version von VCC6/7 haben, das ist lizenzrechtlich so festgelegt.
Bei GTK2 für Windows gibts Binaries die mit mingw erstellt werden.

Falsche Ausganglage.
Der Entwickler der Qt Bindings braucht das, nicht du.



Stimmt schon, es geht nur drum zu schaun, dass man eventuell das Design so auslegt, dass man nachher kompatibel sein kann.
Ich habe z.B. keine Ahnung wie ich ein Panel berschreiben lassen könnte, wo doch im Panel andere Komponenten "wohnen".
Also ist der derzeitige Ansatz mist, ich kann doch nicht einen Button in ein Canvas reinschreiben.


Ich kann das nicht viel sagen, ich kenne leider das Design anderer Wrapper Libs nicht.

Normalerweise ist es so, dass die Basisimplementation die Kindkomponenten zeichnet.
Wenn du also die Zeichenmethode überschreibst, gibts keine Kindkomponentendarstellung, es sei denn, es wird die Basisimplementation aufgerufen.



Was denkst du, wäre es eventuell ein Fehler das design so auszulegen, dass man nicht ableiten kann?

Ich würde sagen, dass das vielleich in der ersten Iteration keine schlechte Idee ist.
Man bekommt schneller etwas benutzbares und die beteiligten Entwickler bekommen besser Vorstellung der Möglichkeiten.

Die "First Version must be perfect" Idee hat bisher noch jedem Projekt das Leben gekostet.

Bei sowas ist es auch jedenfall angebracht, den/die Entwickler der verwendeten Bindings zu Rate zu ziehen.
Eventuell hat der sogar eine bessere Idee, zum Beispiel, ob es möglich wäre, eine spezielle Form der Bindings zu benutzen, weil man ja im Gegensatz zu normale Bindings keine 100% API des echten Toolkits braucht.



Was ich mich dann halt frage ist, warum es dann überhaupt eine commerzielle Version von QT gibt?
Wenn sowieso jeder dagegen linken kann, was macht dass die kommerzielle noch für einen Sinn?


Das sind zwei verschiedene Formen des Linkens.
Beim Entwicklen brauchst du Header und Libs der Bibliothek in einer für deine Endlizenz passenden Lizenz.
Unter welcher Lizenz die Lib am Zielsystem ist, ist irrelevant, außer es wird eine bestimmte Lizenz ausgeschlossen, denn du als Entwickler kannst nicht bestimmten, welche Lib der Runtimelinker zu deiner Applikation laden wird.

Zum Beispiel die qtjava Bindings.
Ich rate jetzt mal, dass die unter LGPL stehen.
Sagen wir, der Bindings Maintainer kompiliert die Lib au seinem System mit der Qt unter GPL/QPL.

Für jemanden, der die Bindings benutzt, ist nur die LGPL ausschlaggebend, nicht welche Lizenz die Qt auf seinen System hat, schon gar nicht, die Qt auf dem System seiner Benutzer.



Danke für deine Geduld!


Kein Problem, ist ein cooles Projekt, dass du dir hier "antust".
Freut mich, wenn ich irgendwie helfen kann.

Ciao,
_

[Lin728]

Grüssi!




Hmm, wußte nicht, das da soviel dazukommt.

Nun, Bytecode ist viel kleiner als kompilierter code.
Aber im großen und ganzen wird der gcj sicher weniger Speicher beanspruchen als die sun-jvm.

Ach ja, ich werd mit qtjava doch noch mal genauer ansehen, wo doch so viele Leute dafür geshtimmt haben..

So

[anda_skoa]

Servus


Original geschrieben von ceisserer

Hmm, das mit dem Linken verstehe ich noch immer nicht ganz. So könnte beispielsweise eine Firma ein qt-basierendes toolkit bauen, müsste einmal eine developer-license kaufen und dürfte dann das Zeugs verscherbeln?


Nun, sie brauchen für jeden daran beteiligten Developer eine Lizenz, aber sonst stimmt das.
Bei CLX ist das ja so.



Also der der die Bindings macht, sollte schon eine kommerzielle Lizenz haben, wohingegen der binding-benützende nur eine Lizenz für die bindings braucht, sofern notwending?


Nicht ganz.
Der Bindingsentwickler braucht auch nur eine kommerzielle Lizenz, wenn er seine Bindings auch unter einer kommerziellen Lizenz haben will.
Du hast ihm geschrieben, dass du eine Sachen unter einer GPL Lizenz stehen werden.
Damit hast du kein Problem mit der GPL von Qt.



Warum hat er aber gesagt, ich darf die GPL-Lib nehmen zum Entwickeln (ich habe nix von einem zwischenlayer erwaähnt), wo doch die bindings selber (also der teil der beim Kompilieren auf die Header zugreift) nicht gpl sind??


Die Bindings sind doch auch unter eine GPL kompatiblen Lizenz, oder?



Also das ganze GNU-Zeugs kann ganz schön anstrengend sein ;-)

:)



Software ist gottseidank kein Gebäude, man kann ohne große Schäden mal herumprobieren.

Zumindest lassen sich Schäden durch ein CVS checkout sehr bequem rückgängig machen :)

Ciao,
_

[anda_skoa]

Hab heut folgende Ankündigung gelesen:
Kaffe, eine freie Implementierung einer Java Virtual Machine hat einen neuen developer release gemacht.
Ene der Neuerungen ist ein Qt basiertes AWT Backend.

genaueres hier:
http://www.kaffe.org/pipermail/kaffe-announce/2003/000019.html

Ciao,
_

[peschmae]

hoffentlich läuft das auch mit GCJ :)

obwohl die mittlerweile auch die ersten laufenden kleinen AWT-Progs haben

MfG Peschmä