List widgets are unusable and crashing

[ppelikan]

First of all, thank you for this great library!

ListView

When using the ListView widget with big amount of items, it renders the items randomly as shown below, index should go from 0 to 20000. When scrolling and selecting random items, the app prints a lot of Gtk-CRITICAL errors, and suddenly crashes.

(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_top: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_bottom: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_start: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_end: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_top: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_bottom: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_start: assertion 'GTK_IS_WIDGET (widget)' failed
(process:107203): Gtk-CRITICAL **: 19:47:09.427: gtk_widget_set_margin_end: assertion 'GTK_IS_WIDGET (widget)' failed

Steps to reproduce:

1. Build and run the included owl_listview_test.nim example
2. Scroll the list vigorously, and select random items.
3. Observe printed errors and see that items changed their order.
4. Continue stress testing, to see it eventually crash.

ListBox

When I try the same with ListBox, items are being properly shown, but it takes 100% CPU usage (from single core), and the whole app becomes unusable.

Included examples:

owl_list_widgets.zip

[can-lehmann]

Which Nim version are you using? Can you reproduce this when compiling with --gc:refc? Does it also occur in the unmodified ListView example?

[ppelikan]

$ nim --version
Nim Compiler Version 2.2.2 [Linux: amd64]
Compiled at 2025-02-06
Copyright (c) 2006-2025 by Andreas Rumpf

git hash: 6c34f62785263ad412f662f3e4e4bf8d8751d113
active boot switches: -d:release

With --gc:refc it fails to build:

/home/xxxx/.nimble/pkgs2/owlkettle-3.0.0-2319432a190a50ade29f85b1451099b08e71ab38/owlkettle/bindings/gtk.nim(419, 23) template/generic instantiation of `crossVersionDestructor` from here
/home/xxxx/.nimble/pkgs2/owlkettle-3.0.0-2319432a190a50ade29f85b1451099b08e71ab38/owlkettle/common.nim(120, 5) Error: signature for '=destroy' must be proc[T: object](x: var T)

---

Does it also occur in the unmodified ListView example?

I didn't manage to crash it yet (perhaps it would on some slower machine), but the order of indexes also seems to be mixed when scrolling and some instabilities also occur. Here are outputs I get from the original ListView example:

(process:132473): Gtk-WARNING **: 00:37:04.027: Duplicate item detected in list. Picking one randomly.
(process:132473): Gtk-WARNING **: 00:37:04.027: Duplicate item detected in list. Picking one randomly.
(process:132473): Gtk-WARNING **: 00:37:04.027: Duplicate item detected in list. Picking one randomly.
(process:132473): Gtk-WARNING **: 00:37:04.027: Duplicate item detected in list. Picking one randomly.
{794}
(process:132473): Gtk-WARNING **: 00:37:14.298: Broken accounting of active state for widget 0x58c355b48910(GtkGizmo)
(process:132473): Gtk-WARNING **: 00:37:14.298: Broken accounting of active state for widget 0x58c355b42e50(GtkGizmo)
(process:132473): Gtk-WARNING **: 00:37:14.298: Broken accounting of active state for widget 0x58c355d827b0(GtkLevelBar)
(process:132473): Gtk-WARNING **: 00:37:14.298: Broken accounting of active state for widget 0x58c355b43da0(GtkListItemWidget)
{969}
{703}
{451}
(process:132473): Gtk-WARNING **: 00:37:18.070: Broken accounting of active state for widget 0x58c355ed6790(GtkListItemWidget)

I've also seen some of them in my modified example, but cannot confirm which and when.

Both ListView and ListBox seem to serve identical functionalities, yet each malfunctions in very different way. Perhaps it's possible to fix one of them?