Finally, the workflow, for human with or without “machine” support, did not really change! And I still find possible issues never reported before and outside AI monitoring or check passes…
Sure, AI’s answer sounds good and solution seems logical. I skiped now the threading experimentations, even indirectly tested with yield, stack, lists and gtk events. So, code should be more pythonic and modern, and there is no real features addition, except maybe more columns.
One issue is still pending. It is specific to GUI (Gtk TreeView model). No crash or error via CLI. It is on gtk window used for displaying the list of results. As a pseudo-sosa/kékulé numbering was expected, an experimental numbering for descendants or cousins has been tested. The main problem is to have a real number, not too complicated to understand at a glance. Maybe a positive one, not used by sosa/kékulé (so, not from 2 to infinite) and uniq. Maybe something around 0 to 1? To have a float value will crash the gtk model
self.model = ListModel(treeview, self.titles)
for entry, sort_key in batch:
self.model.add(entry, sort_key)
It is a design issue. So no more related to refactoring, polishing or cleanup, but still around performance and maybe threading with gtk window.
ps : there is also a cache issue, which is for re-using a list. This might display an incomplete list (signal, active person and database, etc.)