Hi everyone, I have been choosing between nym and kotlin for a very long time and chose nim to write the application gui (ERP system) I have experience working with GTK in Vala and C#. And I was surprised to see this line
I am absolutely new to nim and I have yet to learn the syntax, but as far as I understand this is a signal for the GC to release an array of CountButton objects.
I have not seen manual memory management required other than C/C++ before. Is this just an outdated example, or is it really necessary? If necessary, why is this not done at the binding level, GObject was developed with simple integration with GC in mind. https://developer.gnome.org/gobject/stable/gobject-memory.html
That example shows subclassing widgets while using ARC memory management.
In that case you have to declare your own destructor, as explained in the README.
Generally you have not to care for memory management with gintro, that example is the exception, but it is still automatic memory management. It is not that hard to write a few destructors when you use ARC and subclassing. Maybe there is even a more elegant solution for this case, but I was not able to see one, and I did not wanted to bother the Nim devs that time, as we have really not that many gintro users still, and core devs may be busy with more important stuff.
As you may know I generally recommend to beginners not to use gintro, but well when you have some GTK experience it may be OK.
I understand correctly that these 3 lines are needed with both GC and ARC, and only when the class is inherited?
Are there any plans to use GIR?
only when the class is inherited?
Yes, as I told you here and in the README, it is necessary only when you subclass widgets and when you use ARC at the same time. And as I wrote in the README, for most widgets that are created at program startup once and that lives until the program terminates, we may just ignore the destructor need, creating a destructor gives us no benefit in such case. Only for widgets that are permanently created and destroyed a destructor is really necessary.
The difficulty with ARC is, that currently destructors have to be defined in the same module as the ref object is defined. And as subclassed objects are created in a user module, the destructor have to be created there too. Maybe we could simplify that with a macro?
Are there any plans to use GIR?
GIR means gobject-introspection, and that is what gintro uses for creating the bindings.
I gave a few remarks about the bindings in the box titled "The GTK Nim Bindings" in
It’s great to see you exploring Nim and Kotlin for your ERP system’s GUI. Nim’s approach to memory management can indeed be quite different from what you're used to with GTK in Vala and C#.
Regarding your question about manual memory management in Nim: Nim uses a garbage collector (GC) by default, but it does offer the flexibility to manage memory manually when needed. This can sometimes be surprising if you're accustomed to languages where memory management is more abstracted away.
In your case, it seems like you’re dealing with some lower-level aspects of integration, which might require a bit of manual intervention. While Nim does support GC, certain bindings or integrations might require you to handle memory management explicitly to ensure proper resource handling, especially when interfacing with libraries developed with different memory management models in mind.