Recently we got a request asking how the listview_clocks.c demo would look in Nim languages.
Obviously none C implementations following closely the C code are not that easy, as the example uses the low level stuff like G_DEFINE_TYPE_WITH_CODE() macro to create a real new widget class, which in theory can become part of the GTK library and can be used from other programs them.
Generally when we write apps in high level languages we have not really the need to create real new widget classes, we just use and compose existing widgets.
First question related to gtk4-demo: What is the suggested method to split all the demos like listview_clocks.c into single, stand alone apps which we can use and test then separately? listview_clocks.c has no main() function, and it is not that obvious what else is missing to generate a single executable.
The other question is, if it really makes sense to support all the low level stuff to create true new widgets for high level bindings? For Nim it is generally possible, we can try to expand macros like G_DEFINE_TYPE_WITH_CODE() in single library function calls and then use as well. But I have the feeling that it makes not much sense. In the gintro Nim bindings we use proxy objects, we we can use, extend and subclass easily. Or we can use composition instead of inheritance, which is what Golang generally does. From a short look at the listview_clocks.c example the main reason to create a new gobject class is to be able to define new properties, which are then monitored for changes to drive the clocks. But of course there are other, simpler solutions available in high level languages. The gintro Nim bindings come with some simple, timer driven animation examples already, like a animated sine curve drawing or buttons that are counting down automatically.