jdmansour
commented
7 years ago 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 notifications@github.com 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 https://github.com/jdmansour/nim-smartgi/issues/2, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGt_rsajRKKQD7NADhfFL1Qy6s7GVB8ks5r40wMgaJpZM4NYWT8 .
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