Ich sehe mit der neuesten Version ein sehr seltsames Problem unter Linux mit IcedTea 3.10.0 (basierend auf OpenJDK 8):

Bei der Synchronisierung von Konten, zumindest über FinTS und Chipkarte, bleibt die Synchronisierung - sogar initial, bevor die verfügbaren Kartenlesemethoden abgefragt werden - hängen. Warten bringt nichts. Was aber hilft, ist mit der Maus zu scrollen. Alleinige Mausbewegung nicht. Gescrollt habe ich jeweils die Synchronizationsliste im Hauptfenster, da sie am besten zu erreichen war. Andere Listen, wie die Kontoübersicht scheinen aber auch zu funktionieren. Fange ich nach der PIN-Eingabe nicht wieder an weiterzuscrollen, kommt im Log-Fenster keine weitere Ausgabe, bis der Vorgang irgendwann fehlerhaft abbricht. Scrolle ich jedoch fleißig wird fehlerfrei durchsynchronisiert. Wichtig scheint eine konstante Aktualisierung des Fensters zu sein - in Listen zu scrollen ist dabei die einfachste Methode. Keyboard-Input scheint nur insofern etwas zu bringen, dass es ein Eingabefeld öffnet und auch die aktuelle Position in der Liste aktualisiert, es ist aber schwieriger damit in kurzer Folge die nötige Menge an "Events" zu generieren, damit die Synchronisierung nicht ständig hängenbleibt.


Interessanterweise trifft dieses Problem mit Jameica 2.8.2 / Hibiscus 2.8.8 nicht auf. Dasselbe System, bis auf die ältere Jameica/Hibiscus-Version. (Getestet mit Backup des ~/.jameica-Verzeichnisses vor erstem Start mit neuer Version.)


Anscheinend bin ich der erste oder einzige, der dieses Verhalten bemerkt hat? Auf Windows und OS X habe ich nicht getestet.

Das ist ein GTK3-Problem. Hatten wir hier schonmal diskutiert: forum/topic.php?p=142755#real142755

Unter https://www.willuhn.de/wiki/do…nter_linux habe ich hierzu auch einen FAQ-Eintrag angelegt.

Mh, ja, nach Wechsel auf GTK2 läuft es wie gehabt ohne blödes Rumgescrolle.

Den Thread habe ich größtenteils ignoriert, weil ich keine Darstellungsfehler gesehen habe und das Programm an sich jetzt auch nicht wirklich gehangen hat, sondern sowohl nach Start als auch bei der Synchronisierung an sich gut interagierbar bleib. Nur die Kontensynchronisierung hing. Die Hibiscus-Startseite ist/war noch nie die Schnellste, aber das liegt eh nur an den vielen Elementen und Daten, die aus der Datenbank gelesen und verarbeitet werden müssen. Da gibt es für mich keinen großen Unterschied zwischen den Toolkit-Versionen. Die GTK3-Umstellung habe ich am Rand mitbekommen.

Na gut, wenn SWT die ganzen Events behandelt, dann kannst du dagegen eh nichts machen.

Für mich klingt es so, als ob Hibiscus auf die Log-Ausgabe synchronisieren, d.h. jeweils mit der Synchronisierung der Konten komplett warten würde, bis eine Zeile fertiggeschrieben ist. Auf den UI-Thread zu synchronisieren klingt aber irgendwie nach einer schlechten Idee, da dieser dann das Tempo angeben würde, obwohl andere Threads mit der Bearbeitung schneller fertig werden könnten. Die Log-Ausgabe ist so gesehen ja nur ein Zuckerl für den Benutzer. Würde man die blocken lassen und ignorieren (sofern dadurch keine Einträge verlorengehen), hätte es nur den Nachteil, dass die Nachrichten erst später angezeigt werden würden. Das ist doof, weil der User wissen müsste, dass er irgendwo scrollen muss, aber zumindest sollte in so einem Fall dann die Synchronisierung nicht komplett hängen. Spätestens nach einer erfolgreichen Synchronisierung wird das Hauptfenster ja sowieso aktualisiert und somit müssten auch die Log-Einträge zu sehen sein.

Vielleicht stelle ich mir das aber einfach zu einfach vor und der Knackpunkt liegt im Verlieren der nachfolgenden Datensätze, wenn man nicht auf das Schreiben des vorherigen gewartet hat.

Nein. Die Kommunikation mit der Bank und Logging passiert jeweils in einem extra Thread im Hintergrund. Lediglich das reine Anzeigen der Logausgaben in dem Progressfenster muss mit dem UI-Thread synchronisiert werden, da SWT (wie viele andere UI-Toolkits auch) nur auf dem Main-Thread Zugriff auf die UI gibt.

Wenn das ein Problem von Hibiscus/Jameica waere, dann wuerde es ja plattformuebergreifend auch bei GTK2, Windows und MacOS auftreten.



Es hat nichts mit irgendwelcher Synchronisierung zu tun sondern einfach damit, dass die GTK3-Version von SWT scheinbar noch nicht ganz fehlerfrei ist.