Open StefanSalewski opened 3 years ago
We need to experiment with creating as small or same example using Vala + Nim, and building on Meson.(Update, no we dont) Meson unfortunately does not support nim https://forum.nim-lang.org/t/7540, which in the future will complicate the creation of full-fledged applications(Which need to place their own shortcut and GSettings), but for now we can configure the nim build via custom target as it was done here
P.S. also Flatpak
I gave this issue a little bit of thoughts over the last couple of days. I have explored how the python
and javascript
solve the issue, only to find that the inner workings of the bindings on those two languages are implemented in C and C++ respectively. So they have naturaly access to the low level stuff inside the toolkit.
Then I have read how the GObject system works.
The macros used to generate and register new Objects can be written in code like in the previous link. You have to define two structures and provide members and function pointers in the structures. This represent the TypeInfo
struct in your bindings.
type
TypeInfo* {.pure, byRef.} = object
classSize*: uint16
baseInit*: BaseInitFunc
baseFinalize*: BaseFinalizeFunc
classInit*: ClassInitFunc
classFinalize*: ClassFinalizeFunc
classData*: pointer
instanceSize*: uint16
nPreallocs*: uint16
instanceInit*: InstanceInitFunc
valueTable*: ptr TypeValueTable00
and using the corresponding API to register the type
GType g_type_register_static (GType parent_type,
const gchar *type_name,
const GTypeInfo *info,
GTypeFlags flags);
GType g_type_register_fundamental (GType type_id,
const gchar *type_name,
const GTypeInfo *info,
const GTypeFundamentalInfo *finfo,
GTypeFlags flags);
But does this really worth it? I don't know. Theoretically its doable using nim
macros.
Nim or any other languages provide its own type system and object hierarchies/inheritance. This is besides the two memory management systems inside both worlds, which complicate things.
At the end I think you can use the bindings only to use the provided widgets/objects by the library, but creating another objects inside nim
and hooking those inside the type system of GObject
to be able to use it inside c would be a daunting task.
I think you are right. If the needs come to build custom objects, one might find it easier to create those in c
or better vala
and link it with the code in nim
.
I hear some tone of disrepair in your talk, that you probably want to abandon gintro
, I think it would be a great loss.
Thank you for your efforts.
Recently we get a question how we can port low level C code examples to gintro, like the listviewclocks.c example. See https://github.com/StefanSalewski/gintro/issues/134#issuecomment-852328853
Unfortunately gintro does not support yet all the low level stuff including the nested macros that are used in GTK to create new widgets or to subclass existing widgets on the gobject level with new properties.
Indeed this is not really needed for most apps. But as currently Nim supports linking C code, as described in
https://nim-lang.org/docs/backends.html#nim-code-calling-the-backend-c-invocation-example
we can just have a separate C file for our Nim app that does all the low level stuff. As an example we have just split the file https://gitlab.gnome.org/GNOME/gtk/-/blob/master/demos/gtk-demo/listview_clocks.c
into a C part and a Nim part:
For testing this we need the most recent gintro version which we can install with
nimble install gintro@#head
We build the app with these three commands:
Well that is not really nice of course. One ugly point is that we have to pass the full path to the dynamic link libraries when building. And the Nim code contains some ugly casts and some more ugly stuff. But when you have some Nim and GTK knowledge then you should be able to understand the code and maybe to improve it.
Of course we could try to convert the C part to Nim also. First step would be to expand the C macros like G_DECLARE_FINAL_TYPE() and recreate them in Nim. But finally the code would look not really cleaner. It is just the way how GTK creates widgets, and when we really have to create new widgets with new properties then we will have to write such low level code. I can not imagine a way to really abstract all this. Generally this is not necessary at all, and when you write a Nim GUI app with a few thousand lines of code, then it should be not a real problem when a few hundred lines are low level C code. The advantage of the C code is, that you can follow the C GTK examples straight.
FInally I have to admit that I do not understand the listview_clocks.c example yet, and I even have no idea for what it may be good. This issue is only intended to show how one can do it in principle.