Hallo Olaf,

eine Sache, die mich schon länger bei Hibiscus stört ist das träge Neuladen der Umsatztabelle.

Wenn ich für die persönliche Buchhaltung die Umsätze mit Kommentaren versehe wie Bestellnummern und Tags, muss ich zwangsläufig mit Filtern arbeiten und auch öfters zwischen Filtern hin- und herwechseln.
Um das Nachladen der Tabelle zu beschleunigen arbeite ich bereits jahresweise, d.h. Zeitraum auf 1 Jahr begrenzt, zusätzliche Beschränkung auf eine Kontengruppe. Dennoch sind das hier immer noch 1385 Umsätze.
Wenn ich nun mit Suchbegriffen arbeite, d.h. mal einen SUchbegriff eingebe und wieder wegnehme, dann wird danach die Tabelle immer umständlich 2 mal aktualisiert. Man sieht die Zeilen einzeln eintrudeln und muss immer ca 10 Sekunden warten, bis man mit der Umsatztabelle weiterarbeiten kann.
Genaugenommen dauert das Filtern mit einem Suchwort "foo" nicht lange, die resultierenden 15 Umsätze sind in 1-2 Sekunden angezeigt. Nimmt man das Suchwort aber weg, dauert das ganze Aktualisieren manchmal 10 Sekunden. Es dauert auch nicht immer so lange, manchmal hat man die Ansicht direkt wieder. Ich weiß nicht genau, wann und warum es manchmal so lange dauert und kann es noch nicht genau nachstellen.
Glücklicherweise kam vor einiger Zeit das Feature, dass wenigstens die zuletzt markierte Zeile über Filteränderungen hinweg erhalten bleibt und ich dadurch schneller wieder dorthin finde, wo ich war. Zunächst wird zwar die Tabelle an den Anfang gescrollt, was unschön ist. Im Hintergrund ist die zuletzt markierte Zeile dennoch markiert und durch tippen der Hoch- oder Runter-Taste rollt die Tabelle dann auch wieder an die alte Stelle.

Gibt es generell eine Möglichkeit, Filter abzuspeichern oder zu bookmarken? Wir hatten schonmal die Diskussion, dass mehrere Tabs für die Umsatzliste derzeit nicht möglich sind.

Ich arbeite mit der standardmäßigen lokalen Datenbank H2DB auf einem i7-4790, 32GB Ram, NVMEe Platte. Linux mit openjdk-17.

Ich kann das nicht nachvollziehen. 1300 Umsätze laden bei mir quasi ohne Zeitverzögerung (vielleicht 1 Sekunde). Und ich verwende keine lokale H2-Datenbank sondern eine externe MySQL-Datenbank auf einem langsamen LAN-Server. Die lokale Datenbank sollte eigentlich deutlich schneller sein, weil die Daten da quasi im RAM gehalten werden.

Ich habe eine Vermutung. Ich gehe meist so vor, dass ich in die Zeile Suchbegriff gehe, Backspace gedrückt halte. Weil ich nicht genau weiß, wann er den Refresh triggert, meistens noch ein Return hinterher. Kann es sein, dass dadurch bei 6 Zeichen + Return 7 Refreshes getriggert werden, die alle nacheinander abgearbeitet werden müssen? Ich versuche nun immer, den Inhalt erst zu markieren, und dann einmal "Entf" zu drücken (ein Delete Button für das EditField des Suchbegriffes wäre sinnvoll). Das scheint auf den ersten Blick schneller zu gehen. Aber auch dann sieht man, dass die Liste stückweise gefüllt wird und in dieser Zeit die Scrollbar langsam kleiner wird.
Ich nutze relativ viel Content in der Notiz-Spalte, aber immer nur einzeilig ohne Umbrüche.

Ich weiß nicht, ob das Problem in der Java SWT liegt, oder ob man das besser implementieren könnte. Ich arbeite auch in anderen Applikationen wie dem Mail-Client Evolution (C, Gtk+) mit sehr großen Listen und Filtern. Da werden die Listen auch nicht langsam gefüllt, dass man dabei zuschauen kann.

Ich könnte anbieten, ein Screencast aufzunehmen oder du schaust mal remote drauf in einer Webkonferenz. Ist halt ein bisschen schwierig, das zu veröffentlichen, da es um viele Finanzen geht. Im Endeffekt würde man aber auch nur sehen, was ich beschreibe.

Das Verhalten des Suchfeldes hat sich mit Version 2.10.9 geändert. Siehe topic.php?p=164563#real164563 Die Suche startet jetzt nicht mehr nach EIngabe eines Zeichens in dem Feld sondern erst beim Klick auf "Aktualisieren".

Ich bin derzeit auf

Bei mir aktualisiert sich die Liste bereits nach Ändern des Suchbegriffes ohne Enter oder Aktualisieren.

Nach dem Nightly Update auf
hat sich etwas getan, nun muss man wirklich auf Enter drücken für das Aktualisieren, das scheint schneller zu gehen.