ListView from java List

[JFronny]

This is something for which java-gtk has a utility class.
Something similar for this library would be nice.

[JFronny]

I tried implementing this here, but obviously did something wrong, as the VM segfaults shortly after startup.
(It does work when I remove the list, so the rest of the UI likely isn't the cause)

[jwharm]

I added functionality to generate setters for callbacks, including an auto-generated type definition for the callback. This should simplify some of the code in your ListIndex class (no need to write the ...Calback types anymore).

I wanted to test your utility class, but I know almost nothing about the ListView API, so I don't know how to integrate the class into a small application. Do you have an easily reproducable example that I can use to find the cause of the segfault?

[JFronny]

I added my ListIndex to this branch with an example: https://github.com/jwharm/java-gi/tree/example-20
There seems to be an issue with the callback gen preventing me from doing more testing.
Sorry for accidentally pushing to main, btw. Maybe you can force-push the accidental commits out.

[jwharm]

I've tried to find out what is causing the crash, but cannot find it. There's a number of critical errors from GLib that the item-type property is set twice, but I cannot find why that is.

I'm wondering what the purpose of the ListIndex class is exactly. It is a ListModel but getItem returns a new ListIndex instance. Why would the model return an instance of itself? The original bailuk class also does this, but I don't understand the reason. Which makes it hard for me to reason about the way it works...

[jwharm]

On a positive note, most of the initial setup of the new ListIndex type (the class and interface declaration, installing the property) seems to work fine. I suspect the crash is caused somewhere in the interaction between the ListView and the ListIndex.

[jwharm]

I also tried to add implements ListModel on top of the ListIndex class, not because it's strictly neccessary, but because it should work, so why not.
It didn't work immediately because one method (I think it was getItem) has a wrong return type. I checked the GIR file and this method needed to be replaced with another one (specified with the shadowed-by attribute) that does have the correct signature. I added that to the GIR parser so that should be fixed now.

[jwharm]

I created a new listmodel implementation that can be used with any Java data structure. It is split into a ListIndexModel class and a ListIndexItem. See branch example-20-fixed.

The example works now, but only when I disable automatic reference counting for GObjects. (removed the call to g_object_unref in ObjectBase class.) It seems that the ListIndexItems get two Cleaners assigned and are subsequently unref'ed twice. I've temporarily disabled the call to g_object_unref and it works.

[jwharm]

I've fixed the reference counting issue with #29. The example ListView implementation has been merged into the main branch. I'm closing the issue.

[JFronny]

This implementation causes a NPE if the ListIndexModel size is 0.
To test this, you can just remove this line.

[jwharm]

This has been fixed with commit 5d53a58.

[JFronny]

I once again came across an issue with this: The java-gtk implementation allows re-setting the size to update elements of the list view.
I have updated the example class to demonstrate this: https://github.com/jwharm/java-gi/tree/regenerate
The effect is especially clear when removing the generateList call from the example constructor, since the Generate button will seem to do nothing.

[jwharm]

Thanks for the bug reports.

I forgot to emit the items-changed signal in setSize. It's fixed now in the regenerate branch.

Edit: merged the fix in main too.

[jwharm]

Fixed with commit 8e5650a