Do you still work on GI for Nim?

[StefanSalewski]

Well, github indicates some activity again, after a long break...

Indeed I was nearly sure that you lost interest in GTK3, maybe even in Nim.

You know my c2nim bindings for GTK 3,20. Early this year I started with GI myself -- that was the time I looked at your project -- was never able to compile it, and understanding your code was not that easy.

So I started from scratch -- first goal was understanding GI at all and generating low level bindings similar to c2nim. Result was

https://github.com/StefanSalewski/nim-gi

Last weekend I started working on it again. Have already done some fixes, and renamed all the low level types with a 00 postfix for now, so that the clean symbols like "Button" are available for the high level data types. My main inspiration for high level is Araqs LibUI, but that seems to be tiny. And his approach with two modules, a low level one and a high level one does not work well for GTK3. Unfortunately no one is really interested in GTK3 -- so I hesitate to ask questions in Nim Forum or IRC. For GTK people situation is not better -- GI is nearly unmaintained, I noticed many bugs, and finally found the GI buglist with hundreds of entries.

Well, you did great work with GI already, I will look at it again. When it should compile again it is much easier to inspect -- I have my own editor with good nimsuggest support:
https://github.com/ngtk3/NEd

[jdmansour]

Hi Stefan, sorry, I initially missed your mail. Yeah, I played around with Nim again recently. The problem is that I don't really have time to work on it due to my job and familiy. Also, I initially started it as part of a "little" project (a Simplenote compatible notes app), I think before I saw your wrappers, and it turns out that small project was a lot more complicated than I thought, so I lost motivation at some point :-). About nim-smartgi, yes the code is very cluttered. I experimented a lot and did not clean it up. I fixed it up so it compiles with Nim 0.14, but I'm not sure I've committed all changes yet. To be honest, I'm not sure my approach works in the end. The problem I have is with the inheritance hierarchy. I have the Gtk structs, like TButton, TWidget, ..., and then have a kind of smart pointer (I think I called it GSmartPtr[T]) to them which is a generic class. Then I alias Button = GSmartPtr[TButton]. This works pretty well, and I can do tricks like define APIs with FloatingPtr[T], and when that is first converted to GSmartPtr[T] I can transfer ownership. The problem arises when I want to call parent class methods. E.g. gtk_widget_show on a GtkButton. I define `def show(Widget widget)`, but to make it available I need a converter Button -> Widget. Unfortunately, that means I need to add hundreds of converters, which makes compillation very slow. I remember you had a conversation with Araq on the forums about this. Do you have the same problem? I wonder it there is a solution to it. Some ideas: - It would be great if generic types can be made covariant (I think that is the right term), e.g. if TButton is a subclass of TWidget, then GtkSmartPtr[TButton] should be treated as a subclass of GtkSmartPtr[TWidget]. I don't think that is going to happen though. - Make fake objects Button, Widget, that just wrap pointers, and inherit from each other (and have no relation to the structs) About your efforts with GI, that sounds great. In principle I've found the introspection libraries to be pretty good (they are what Python, Vala use), but ironically girepository itself has broken bindings :-P so you can't use it on itself. If there is one part of my code that might be useful for you, then it is the part that wrapps girepository API. I also like the trick where I implemented class methods, so you can call Gdk.Display.getDefault() :-). As I said, I don't really have time, at least in the next 1-2 months. I'll try to clean up and commit what I have, maybe it is of use. Afterwards, maybe we can try to work on this together. cheers, Jason PS: Your name sounds German, is that right? I speak German too :-)

…

On Fri, May 12, 2017 at 1:57 AM, StefanSalewski ***@***.***> wrote: Well, github indicates some activity again, after a long break... Indeed I was nearly sure that you lost interest in GTK3, maybe even in Nim. You know my c2nim bindings for GTK 3,20. Early this year I started with GI myself -- that was the time I looked at your project -- was never able to compile it, and understanding your code was not that easy. So I started from scratch -- first goal was understanding GI at all and generating low level bindings similar to c2nim. Result was https://github.com/StefanSalewski/nim-gi Last weekend I started working on it again. Have already done some fixes, and renamed all the low level types with a 00 postfix for now, so that the clean symbols like "Button" are available for the high level data types. My main inspiration for high level is Araqs LibUI, but that seems to be tiny. And his approach with two modules, a low level one and a high level one does not work well for GTK3. Unfortunately no one is really interested in GTK3 -- so I hesitate to ask questions in Nim Forum or IRC. For GTK people situation is not better -- GI is nearly unmaintained, I noticed many bugs, and finally found the GI buglist with hundreds of entries. Well, you did great work with GI already, I will look at it again. When it should compile again it is much easier to inspect -- I have my own editor with good nimsuggest support: https://github.com/ngtk3/NEd — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGt_rsajRKKQD7NADhfFL1Qy6s7GVB8ks5r40wMgaJpZM4NYWT8> .

[StefanSalewski]

PS: Your name sounds German, is that right?

Yes, and I have some background in physics too, see ssalewski.de :-)

With the converters that is a known problem, Araq do not like converters too much at all. Currently I do not know if we really need many converters for GTK3. My initially idea was indeed using a lot of converters, but then Araq suggested the idea of delegates, which he has dropped again. Time is of course a problem for me also, and motivation is not that great, because I don't think that many people will ever use the high level Nim GTK bindings. But the gobject introspection worked really not bad, and the high level interface stuff is a good playground to learn more about Nim's macros. So I think I will continue the project. I know that you have already real high level callback support working, that is really nice. I still have to think about that a bit, and I still have to read some more about the goobject side, i.e. the toggle references as described in https://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html

Best regards,

Stefan Salewski

[StefanSalewski]

My high level Nim bindings are now online:

https://github.com/StefanSalewski/gintro

The first tests seems to work well, and I wrote a very basic tutorial in the github README. I was able to fully avoid converters, but to provide type safe signal connect too. Of course there is still much testing and improving necessary.