Karten-Anzeige-Zoom einstellbar

[lundefugl]

Hallo Christian,

Der entsprechende API-Aufruf ist doch in JavaFX8WebViewMapView.

Aber der Java 7-Compiler hat nur die Java 7 Klassenbibliothek und die kennt WebView#setZoom() nicht.

Irgendwie sehe ich immer noch nicht das Problem.

Du kompilierst mit Java 8.

da hatte ich deinen Buildprozeß etwas anders verstanden gehabt (wohl auch, da Travis den letzten Pullrequest unter Java7 auf grün hatte).
Ich war davon ausgegangen, dass du alles - bis auf JavaFX8WebViewMapView - mit Java 7 baust und dann zusätzlich nur JavaFX8WebViewMapView mit Java 8.
Zur Laufzeit wird die Klasse dann nur geladen, wenn man Java 8 ist, so dass man unter Java 7 nicht merkt, dass da etwas inkompatibles ist.

Außerdem dachte ich, dass du im IntelliJ IDEA (wie ich) mit Java 8 arbeitest und durch Travis nur die Java 7-Kompatibilität prüfen lässt.
Und wenn man wirklich mal im IntelliJ Java 7-Builds macht, dann setzt man die Klasse kurz auf "exclude".

Diese Annahmen waren eben falsch, so dass wir aneinander vorbeigeredet haben.


Was die Änderung angeht, so werde ich (hoffentlich am Sonntag) noch ein wenig testen. Ich möchte vorallem sicherstellen, dass es keine anderen Stellen gibt, die den Zoomfaktor auch berücksichtigen müssten. Speziell geht es mir um die Mausklicks. Ich weiß nicht, wie da die Koordinaten zurückkommen (in Pixeln oder schon von Google in GPS-Werten).
Für mich ist es so schon ausreichend, da ich auf dem Tablet nur die GPS-Logger-Aufzeichnungen sichten will.

Was das andere Problem mit der Listendarstellung angeht, so glaube ich nicht, dass das am Renderer liegt. Ich habe da das Look&Feel im Verdacht. Speziell die Bestimmung der Zellenhöhe. Für mich sieht es so aus, als ob diese zu klein wäre. Mal sehen, ob ich dafür auch noch Zeit finde.

Gruß
Thomas

[routeconverter]

Was die Änderung angeht, so werde ich (hoffentlich am Sonntag) noch ein wenig testen. Ich möchte vorallem sicherstellen, dass es keine anderen Stellen gibt, die den Zoomfaktor auch berücksichtigen müssten. Speziell geht es mir um die Mausklicks.

Das klingt gut.

Was das andere Problem mit der Listendarstellung angeht, so glaube ich nicht, dass das am Renderer liegt. Ich habe da das Look&Feel im Verdacht. Speziell die Bestimmung der Zellenhöhe. Für mich sieht es so aus, als ob diese zu klein wäre. Mal sehen, ob ich dafür auch noch Zeit finde.

Ich habe das auch unter manchen Linux Desktops schon gesehen.

[lundefugl]

Hallo Christian,

Was die Änderung angeht, so werde ich (hoffentlich am Sonntag) noch ein wenig testen. Ich möchte vorallem sicherstellen, dass es keine anderen Stellen gibt, die den Zoomfaktor auch berücksichtigen müssten. Speziell geht es mir um die Mausklicks.

Das klingt gut.

mit meiner Version habe ich noch verschiedene Dinge (neue Position hinzufügen, Selektion usw.) ausprobiert.
Dabei hat alles so funktioniert, wie ich es erwartet habe. Natürlich kann ich dir keine 100%ige Garantie geben, dass alle Funktionen des RC gehen (dafür kenn ich ja alle Möglichkeiten nicht einmal). Da es außerdem eine optionale Funktion ist, hätte ich gesagt, dess keine größeren Probleme zu erwarten sind.

Gruß
Thomas

[lundefugl]

Hallo Christian,

Was das andere Problem mit der Listendarstellung angeht, so glaube ich nicht, dass das am Renderer liegt. Ich habe da das Look&Feel im Verdacht. Speziell die Bestimmung der Zellenhöhe. Für mich sieht es so aus, als ob diese zu klein wäre. Mal sehen, ob ich dafür auch noch Zeit finde.

Ich habe das auch unter manchen Linux Desktops schon gesehen.

wie erwartet ist die Default-Höhe der Zelle einfach Schrott auf dem Tablet.

Die Default-Zellhöhe ist bei mir auf einem Desktop-System und auf dem Tablet immer 16.
Auf dem Desktop ist die Höhe, die der Renderer benötigt 20. Auf dem Tablet hingegen 32.
Setzt man nun die RowHeight auf 28, dann sieht es auch auf dem Tablet gut aus.

Die effektive Renderer-Höhe habe ich dadurch bestimmt, dass ich über alle Spalten iteriert habe und jede mal einen Dummy-Wert hab rendern lassen. Von der zurückerhaltenen Component hab ich dann aus der Pref-Size die Höhe genommen (der größte Wert - außer der Foto-Spalte gewinnt).

Es gibt in meinen Augen nun 2 Varianten:
1. man gibt die Default-Zellenhöhe über die versteckten Optionen vor
2. man bestimmt sich die Höhe, die der Renderer benötigt und setzt diese (abzüglich der 4) als Zellhöhe (die 4 könnte man ggf. über die versteckten Optionen noch konfigurierbar machen, falls es mal Probleme bereitet)
Das könnte man evtl. im JTableHelper für alle Tables machen, aber da müsste man dann irgendwie noch die Testwerte fürs Rendering rein bekommen.

Und noch eine Frage am Rand. Was hat es mit der Foto-Spalte auf sich ? Die hab ich noch nie gesehen (das Feature ist wohl an mir vorbeigegangen). Kann man damit Fotos geocodieren ? Ich hab dafür immer noch ein anderes Tool im Einsatz...

Gruß
Thomas

[routeconverter]

mit meiner Version habe ich noch verschiedene Dinge (neue Position hinzufügen, Selektion usw.) ausprobiert.
Dabei hat alles so funktioniert, wie ich es erwartet habe. Natürlich kann ich dir keine 100%ige Garantie geben, dass alle Funktionen des RC gehen (dafür kenn ich ja alle Möglichkeiten nicht einmal). Da es außerdem eine optionale Funktion ist, hätte ich gesagt, dess keine größeren Probleme zu erwarten sind.

Hallo Thomas,

danke fürs Testen. Ich habe eine neue Vorabversion hochgeladen, damit andere Nutzer die Chance haben, Fehler zu melden. Mal schauen, ob und was da so kommt.

[routeconverter]

wie erwartet ist die Default-Höhe der Zelle einfach Schrott auf dem Tablet.

In JTable#initializeLocalVars() kann man sehen, dass sie auf 16 gesetzt wird.

Die Default-Zellhöhe ist bei mir auf einem Desktop-System und auf dem Tablet immer 16.
Auf dem Desktop ist die Höhe, die der Renderer benötigt 20. Auf dem Tablet hingegen 32.

Also ist das der Fehler, oder? Wieso benötigt der Renderer so viel Platz.

Setzt man nun die RowHeight auf 28, dann sieht es auch auf dem Tablet gut aus.

Gibt es eine Chance herauszufinden, ob RouteConverter auf einem Tablet läuft?

2. man bestimmt sich die Höhe, die der Renderer benötigt und setzt diese (abzüglich der 4) als Zellhöhe (die 4 könnte man ggf. über die versteckten Optionen noch konfigurierbar machen, falls es mal Probleme bereitet)

Kann man das machen, während RouteConverter läuft? Also zur Laufzeit herausfinden?

Und noch eine Frage am Rand. Was hat es mit der Foto-Spalte auf sich ? Die hab ich noch nie gesehen (das Feature ist wohl an mir vorbeigegangen).

Wenn Du Bilder in die Version 2.18 wirfst, die Apache commons-imaging lesen kann, sucht RouteConverter nach Geotags. Und verändern können sollte man sie auch.

Kann man damit Fotos geocodieren ? Ich hab dafür immer noch ein anderes Tool im Einsatz...

Das geht komfortabel nur mit TimeAlbum Pro, das ich zusammen mit Columbus entwickelt habe.

[lundefugl]

wie erwartet ist die Default-Höhe der Zelle einfach Schrott auf dem Tablet.

In JTable#initializeLocalVars() kann man sehen, dass sie auf 16 gesetzt wird.

Wie kommen die auf fixe 16 ?

Die Default-Zellhöhe ist bei mir auf einem Desktop-System und auf dem Tablet immer 16.
Auf dem Desktop ist die Höhe, die der Renderer benötigt 20. Auf dem Tablet hingegen 32.

Also ist das der Fehler, oder? Wieso benötigt der Renderer so viel Platz.

Nein, der Renderer ist korrekt. Auf dem Tablet sind (scheinbar) die Pixel kleiner als bei einem "normalen" Monitor, so dass man mehr Pixel benötigt, um eine gewisse lesbare Schriftgröße zu bekommen.
Eine Reduktion der Schriftgröße wäre fatal, da man dann nichts lesen kann. Man muss die Zeilenhöhe auf den Wert des Renderers erhöhen.

Gibt es eine Chance herauszufinden, ob RouteConverter auf einem Tablet läuft?

Ich glaube kaum. Es ist ein ganz normales WIndows 10 Home, bei dem lediglich die Anzeigeeinstellungen auf 150% stehen. (ansonsten kann man auch die Windows-Dialoge, Menüs usw. nicht lesen)
Ich glaube auch nicht, dass es ein reines Tablet-Problem ist. Ich habe eine kleine Wohnzimmer-PC-Box, die den gleichen Effekt hat. Die steht auch auf 150% bei Windows, da man ansonsten auf die Entfernung zum Sofa nichts lesen könnte.

2. man bestimmt sich die Höhe, die der Renderer benötigt und setzt diese (abzüglich der 4) als Zellhöhe (die 4 könnte man ggf. über die versteckten Optionen noch konfigurierbar machen, falls es mal Probleme bereitet)

Kann man das machen, während RouteConverter läuft? Also zur Laufzeit herausfinden?

Das geht. Hab ich ja testweise gemacht. Einfach den Renderer von Hand mit einem gültigen Datenobjekt füttern (kann auch ein Dummy-Datenobjekt - wie bei meinem Test - sein, hauptsache er kann etwas rendern).
Heraus kommt dann eine "Component". Auf der kann man dann die Pref-Size bestimmen und hat die benötigte Größe. Diese kannst du dann setzen (machst du ja auch, wenn die Foto-Spalte aktiv ist bzw. deine Default 16). Warum die Zeilenhöhe um 4 kleiner sein muss, kann ich dir allerdings nicht genau sagen. Das muss aber scheinbar immer so sein.

Gruß
Thomas

[lundefugl]

Hallo Christian,

Ich habe eine neue Vorabversion hochgeladen, damit andere Nutzer die Chance haben, Fehler zu melden. Mal schauen, ob und was da so kommt.

deine Version funktioniert leider nicht. Die Option hat da keine Wirkung.

Hat es eigentlich einen Grund, dass du den Code zum Setzen der Skalierung in der Java7-Variante drin hast?
In der Java8-Klasse könnte man dann die Exception - falls es eine gibt - loggen.

Gruß
Thomas

[lundefugl]

Hallo Christian,

Ich habe eine neue Vorabversion hochgeladen, damit andere Nutzer die Chance haben, Fehler zu melden. Mal schauen, ob und was da so kommt.

deine Version funktioniert leider nicht. Die Option hat da keine Wirkung.

dafür gibt's wahrscheinlich eine einfache Erklärung. Die Version, die unter Prerelease zum download angeboten wird, ist vom 2.7. (Jar und Exe-Version).
Meine lokal gebaute Version von deinem Master-Branch scheint zu funktionieren.

Gruß
Thomas

[routeconverter]

Hat es eigentlich einen Grund, dass du den Code zum Setzen der Skalierung in der Java7-Variante drin hast?

Faulheit ;-)