[DEV] kleine Codeänderung in Ewe

[pfeffer]

Hallo!

nun bin ich der Sache auf den Grund gegangen, warum der Track nicht ordentlich aktualisiert wird.
Ich kann leicht eine Lösung implementieren, die aber extrem ineffizient ist. SEHR viel effizienter wäre eine Lösung, bei der ich das Feld "bufferedImage" in Image.java als public definieren würde, um direkt dort die Änderungen hineinzuschreiben.
Allerdings müsste dazu die ewe.fx.Image.java neu kompiliert werden, was mir nicht gelingt. Kann das jemand? Oder kann mir jemand sagen, wie es gehen müsste? Oder wo ich eine Anleitung dazu finde?

Ein frohes und erfolgreiches neues Jahr!
Pfeffer.

 

[Bilbowolf]

Eine Anleitung sollte hier stehen: http://www.ewesoft.com/Downloads/Downloads.html#_Toc105819911


Eine andere Möglichkeit wäre natürlich die .Image zu kopieren und in den CacheWolf code zu übernehmen.

 

[pfeffer]

vielen danl für den Hinweis.
Das Problem lag an mehrerem:
a) aus irgendeinem Grund speichert mein Eciplse die Dateien nicht mehr ab, bevor er kompiliert :-(

b) Ein Fehler in dem Ewe-Quellcode: in ewe.zip.ZipOutputStream in der Methode finish() ist die Variable "enum" enthalten. "enum" ist als Variablennamen jedoch nicht zulässig, weil es ein Schlüsselwort ist. ich habe einfach aus "enum" "enumi" gemacht und jetz kann ich ewe selbt kompilieren EDIT: ich sehe gerade, anstatt diese Ersetzung zu machen kann man in Ecpilse auch unter /Window/Preferences/Java/Compiler das "Compiler Compliance level" auf 1.4 einstellen. Dadurch werden Veriablen mit dem Namen "enum" erlaubt (offenbar, weil "enum" in JGK 1.4 kein Schlüsselwort war).


Dann kann ich in den nächsten Tagen endlich die Track-Geschichte abschließen.

@BilboWolf: Zu Deinem Vorschlag, eine eigene Image-Klasse zu machen: Das geht nicht, weil ich die weiteren Ableitungen (mImage und AniImage auch verwende...). Deswegen bleibt noch die Frage zu klären, wie ich die geänderte Image.java bzw. Image.class ins SVN am besten einspeisen soll. - Irgendwelche Ideen?

Gruß,
Pfeffer.

 

[Kalli]

Die Klasse gehört ins lib-Verzeichnis. Entweder ersetzt Du die "defekte" Klasse ind den .jar und .zip (da wird mir allerdings etwas mulmig) oder Du machst ein eigenes Archiv, da kann man dann in Zukunft noch mehr Workarounds reinpacken. Das Archiv könnte man ewefix oder so nennen, die weiteren Pfade (Packages) bleiben wie beim Original. In deinem Beispiel würde dann nicht die Klasse ewe.fx.Image importiert sondern ewefix.fx.Image.

Es müssen dann natürlich noch die Scripte und -bat-Dateien um das neue Archiv ergänzt werden, Bilbowolf muss es bei seinen Buildscripts auch beachten, der Aufwand ist aber nicht so hoch.

Ich hoffe, das haut so hin

 

[pfeffer]

nun, irgendwie sind ja alle Varianten blöd.
a) Ich könnte nur die Image.java in ein Paket ewe-mod... packen. Das genügt aber nicht, weil in ewe abgeleitete Klassen mein mod verwenden sollen. Also müssten mindestens die abgeleiteten Klassen auch ins ewe-mod. Dies würde aber irgendwie ein Chaos erzeugen, weil dann gleichzeitig auf ewe.fx.Image und ewe-mod.fx.Image und die jeweils abgeleiteten Klassen zugegriffen werden kann. ---> blöd.

b) Wir verwenden komplett nur ewe-mod, das alle ewe-Klassen komplett enthält. Auch nicht so toll, weil dadurch Änderungen in ewe sehr erleichtert werden, wir aber möglichst wenige Änderungen in dem ewe-Code machen wollen, damit es leichter ist, auf eine neue ewe-Version umzusteigen.

c) ich tausche nur die entsprechenden .class und .java Dateien in den .zip und .jar-Archiven aus. Das ist ziemlich blöd, weil es leicht so aussieht, als handele es sich um die Originale von ewe.

Ich bin für Variante b), die wohl auch Deiner (Kallis) Präferenz entspricht.
Bei dieser Variante kommt noch die Frage hinzu (aber das ist vielleicht bloß eine Einstellungssache in Ecpilse), wie ewe-mod mit CacheWolf verbandelt werden soll. Man kann es als eigenes Projekt in Eclipse machen und bei CacheWolf angeben, dass CacheWolf von dem Projekt ewe-mod abhängig ist. Alternativ könnte man auch beides zusammen als 1 Projekt in Eclipse verwenden.

Darf ich die anderen Programmierer, insbesondere BilboWolf bitten, seine Meinung zu äußern?

Schöne Grüße,
Pfeffer.

 

[Kalli]

Ja, ist irgendwie alles blöd. Wenn man Variante b) macht, solltest Du auf alle Fälle deine Änderungen im Ewe-Support Forum posten. Dann besteht die Hoffnung, dass man in Zukunft ewe-mod nicht mehr benötigt, weil das Problem gefixt wurde und bei einer neuen Version von Ewe nicht mehr besteht. Ich würde bei b) ein eigenes Archiv machen, dann aber die Packagenamen beibehalten. Ist zwar aus Sicht von SVN nicht so toll, weil man ein komplettes Archiv verwaltet und nicht einzelne Dateien. In eclipse wird dann halt das neue Archiv mit in den Buildpath genommen.

Ich denke hierbei an die Leute, die sich "nur" per SVN die aktuellen Sachen auf den PC holen und sich mit Hilfe der Build-Scripts eine eigene Version bauen, also nicht selbst entwickeln und somit kein eclipse nutzen. Auch beim Bauen der BE und der Releases ist eclipse nicht mit im Spiel.

 

[MiK]

Ich denke nicht, dass dieser "Fix" ins offizielle Package wandern wird, da der direkte Zugriff wahrscheinlich absichtlich unterbunden wurde.

Die Frage ist, wie haben sich die EWE-Entwickler sonst diesen Zugriff vorgestellt. Aber das Hat Pfeffer wohl schon erfolglos versucht herauszufinden. Ich kenne mich dazu auch noch viel zu wenig mit der Sache aus. Und das wird wohl in den nächsten Wochen nicht besser werden :-(

Ciao

MiK

 

[pfeffer]

so, nach dem auch ich festgestellt habe, dass die ewe-klassen gar nicht im .ewe-File enthalten sein muessen und wenn sie enthalten sind, nicht verwendet werden... muesste ich eigentlich den Quellcode von ewe aendern, nicht nur den Java-Code.
Dazu habe ich dann doch keine Lust... und eine andere Loesung implementiert, die ohne Aenderungen in der ewe-VM auskommt und dennoch so performant wie moeglich ist... allerdings auch etwas komplex. SVN-Commit ist schon raus.

Gruss,
Pfeffer.