Dateiendung bei "Speichern unter"

[routeconverter]

(29.12.2011 12:30 PM)lundefugl Wrote:  Wahrscheinlich habe ich irgendwas falsch gemacht, da ich die Philosophie von Git noch nicht richtig verstanden habe. Es ist doch was komplett anderes als Subversion, CVS & Co.

Ja, es hat auch bei mir eine Weile gedauert, bis ich die Unterschiede von zentralen und verteilte Versionskontrollsysteme verstanden hatte. Lies eine paar git und github Tutorials, das macht Commits, Lokale und Remote Repositories, Push/Fetch/Pull/Rebase klarer. Falls Du Fragen hast, können wir auch gerne skypen.

(29.12.2011 12:30 PM)lundefugl Wrote:  Nachfolgend mal meine Ausgaben auf der Kommandozeile:

Quote:C:\work\routeconverter\RouteConverter>git branch --all
* lundefugl
master
remotes/origin/HEAD -> origin/master
remotes/origin/csv
remotes/origin/kml
remotes/origin/master

C:\work\routeconverter\RouteConverter>git push
fatal: remote error:
You can't push to git://github.com/cpesch/RouteConverter.git
Use git@github.com:cpesch/RouteConverter.git

Ok, was Du gemacht hast, ist einen lokalen Clone meines github Repositories anzulegen und darin den Branch lundefugl. Damit ich Deine Änderung fetchen kann, mußt Du Deinen lundefugl Branch in ein remote-Repository auf github pushen. Du brauchst also einen eigenen Clone auf github (oder anderswo) von meinen github-Repository.

Zu den Namen:

• Dein github User heißt dann lundefugl
• Dein github Clone Repository heißt dann RouteConverter (Hauptsache ist, daß github weiß, daß es von meinem geclont ist)
• Darin hast Du einen master-Branch, den man üblicherweise auf die Releases des geclonten Repositories aktualisiert
• Und den Branch mit den Änderungen für den Pull-Request nennt man üblicherweise nach dem Feature, z.B. fix-filechooser-bug-4711
  

Es ist kein Problem bei git, viele Branches zu haben. Und Du kannst den Clone von Deinem und meinem github-Repository in einem einzigen lokalen Repository haben. Anfangs total verwirrend, ich weiß, aber sehr praktisch.

[routeconverter]

(28.12.2011 06:56 PM)lundefugl Wrote:  ich hätte eine Lösung gefunden. Leider liefert getSelectedFile beim Save-Dialog im Gegensatz zum Open-Dialog Schrott zurück

Was genau meinst Du mit Schrott? Bei mir liefert getSelectedFile() immer null und getSelectedFiles() ein leeres Array - egal ob Öffnen oder Speichern-Dialog.

(28.12.2011 06:56 PM)lundefugl Wrote:  Ob das unter Linux/Mac auch funktioniert, kann ich mangels Testsystem nicht sagen.

Eigentlich sollten alle PLAFs auf javax.swing.plaf.basic basieren, oder? Dann könnten sich nur noch #getFileName/#setFileName anders verhalten.

[routeconverter]

So habe ich "gemessen"

[lundefugl]

Hallo Christian,

(30.12.2011 08:15 AM)routeconverter Wrote:  Was genau meinst Du mit Schrott? Bei mir liefert getSelectedFile() immer null und getSelectedFiles() ein leeres Array - egal ob Öffnen oder Speichern-Dialog.

Bei mir kommt meist der Folder zurück, in dem sich der Dialog befindet. Allerdings habe ich auch schon null bekommen und c:\ (ohne dort zu sein). Für mich war deshalb kein System erkennbar und das Ergebnis "Schrott". Das Array war bei mir auch immer leer.
Beim öffnen habe ich hingegen sinnvolle Ergebnisse bekommen. Hier löst auch der PropertyChangeListener mit "selection changed" korrekt aus.

Ich vermute mal, dass das wieder am Look&Feel liegt. Ich habe hier XP und das Classic-L&F auf dem Notebook. Solche L&F-abhängigen Effekte hatten wir leider schon oft in der Firma gesehen und dann das Verhalten auf allen offiziellen Zielplattformen ausgetestet.

(30.12.2011 08:15 AM)routeconverter Wrote:  Eigentlich sollten alle PLAFs auf javax.swing.plaf.basic basieren, oder?

Das ist eben die große Frage...
Am Dienstag habe ich die Möglichkeit auf einem Mac OS X und unter Ubuntu es zu testen. Windows 7 habe ich zu Hause, so dass ich dann für diese Systeme eine Aussage treffen kann.

Wenn es dort funktionieren würde, so könnte man ja mal ein Pre-PreRelease hier posten. Vielleicht finden sich ja Linux-User, die das auf ihren Distributionen und UIs kurz testen.

Ausserdem sollte eigentlich der Code so robust sein, dass er bei anderen UIs im schlimmsten Fall nichts macht. Man hätte zwar nicht ganz das bisherige Verhalen, aber auch keinen Absturz.

Gruß
Thomas

[lundefugl]

Hallo Christian,

die Tests sind leider nicht so gut ausgefallen.

Windows XP (32 bit) IE8 - funktioniert
Windows 7 (64 Bit) IE9 - funktioniert
Ubuntu (32 bit) mit SUN JRE 1.6.0.30 - funktioniert
Mac OS X - funktioniert nicht

Leider kommen beim Mac meine Diagnoseausgaben nicht, die ich für diesen Fall eingebaut hatte. Da werde ich morgen nochmal testen müssen.

Gruß
Thomas

[lundefugl]

Hallo Christian,

bei mir läuft es nun auch auf dem Mac. Die Erweiterung habe ich im Branch von mir eingecheckt und gepusht. Brauchst Du hierfür jetzt einen neuen Pull-Request ?

Was in meinen Augen nun noch aussteht, wäre ein Test mit OpenJDK. Da ich meine Testsysteme an der Stelle nicht verändern darf, kann ich es selbst nicht testen.

Gravierende Überraschungen erwarte ich nicht. Sollten die UIs dort wie beim Mac-UI nicht auf den Basis-Klassen basieren, so muss auch hier eine entsprechende Implementierung rein. Sofern Funktionsnamen und Parameter identisch sind, reicht evtl. sogar die Erweiterung der Mac-If-Abfrage um diese UI-Klassennamen.

Gruß
Thomas