After long time, I took again a look into my GTK3 wrapper, due to upcomming release 3.18
One of the most complicated constructs is this:
gtk+-3.17.6/gtk/gtktextattributes.h
struct _GtkTextAppearance
{
/*< public >*/
GdkColor bg_color; /* pixel is taken for underline color */
GdkColor fg_color; /* pixel is taken for strikethrough color */
/* super/subscript rise, can be negative */
gint rise;
guint underline : 4; /* PangoUnderline */
guint strikethrough : 1;
guint draw_bg : 1;
guint inside_selection : 1;
guint is_text : 1;
/* For the sad story of this bit of code, see
* https://bugzilla.gnome.org/show_bug.cgi?id=711158
*/
#ifdef __GI_SCANNER__
/* The scanner should only see the transparent union, so that its
* content does not vary across architectures.
*/
union {
GdkRGBA *rgba[2];
/*< private >*/
guint padding[4];
};
#else
GdkRGBA *rgba[2];
#if (defined(__SIZEOF_INT__) && defined(__SIZEOF_POINTER__)) && (__SIZEOF_INT__ == __SIZEOF_POINTER__)
/* unusable, just for ABI compat */
/*< private >*/
guint padding[2];
#endif
#endif
};
struct _GtkTextAttributes
{
/*< private >*/
guint refcount;
/*< public >*/
GtkTextAppearance appearance;
GtkJustification justification;
GtkTextDirection direction;
The problem is, that _GtkTextAppearance is used in _GtkTextAttributes, so exact struct size is important. I am not really sure currently how to process ((__SIZEOF_INT__ == __SIZEOF_POINTER__)) condition. For Nim that would be true, but what really matters is how C compiler on current architectur would evaluate that? My feeling is, that I should use the code in the union which may work for all architectures?
My bindings support GTK 3.15.xx, which is nearly the same as 3.16. About ten modules total, including cairo, pango. The bindings are in good shape, with some minor bugs. There is no garbage collector support currently, and not much effort to use higher level Nim constructs, for example GLib lists are not replaced by Nim sequences.
So Nim GTK3 code has a shape similar to C examples. I think that is not too bad. You may look at
https://github.com/StefanSalewski/nim-gtk3/tree/master/test/application10
or
https://github.com/StefanSalewski/nim-gtksourceview/blob/master/test/test_completion.nim
or my aporia conversion to see how the code may look. (Aporia is still a bit low level with too much addr and cast operators.) But I think generally it is not bad, GTK's ref counting is not bad for memory handling.
Of course higher level bindings would be possible, like it exists for Python, Go and others.
But the fact is: No one is currently using GTK3 for Nim, no one seems to like GTK, some seems to really hate it. Some months ago I did the fixes of the main GTK wrapper for GTK 3.18 locally and added the application 10 example. I still have to do similar fixes for the other 9 modules. That is some work -- the main reason is that latest c2nim output is a bit different from earlier versions, so I have to modiefy all my scripts a bit. 150 h of work estimated. Not too much, but maybe wasted time when no one wants to use it. I am not using it myself currently, I have two Ruby projects for which I consider porting to Nim (http://ssalewski.de/PetEd.html.en and http://ssalewski.de/Router.html.en) but of course that is some work, and maybe the effort is not justified.
So the progress of GTK3 for Nim depends on interest. Andreas recently did the wxWidgets wrapper, and someone did a Qt QML wrapper. Maybe there is more interest.
I think merging GTK2 and GTK3 is not possible, generally my GTK3 bundle covers full GTK2 range. Unfortunately there are name conflicts, I have nim-cairo for example, which also exists in official tree. For GC support https://github.com/nim-lang/Nim/issues/3448 may be interesting, but I can not implement that myself. Without that, adding GC support will need a lot of code. And that code would need testing, which is a problem when no one is using it :-)
OK, it seems it's best thing to try it out.
Of course higher level bindings would be possible, like it exists for Python, Go and others.
it would be nice indeed to take advantage of Nim's GC and other higher-level features!
But the fact is: No one is currently using GTK3 for Nim, no one seems to like GTK, some seems to really hate it.
Well, I use GTK3 desktop (GNOME) and would use Linux as native development platform, but still would like to be able to produce multi-platform app and GTK3 is a valid choice, especially considering linux as 'main' platform.
Not too much, but maybe wasted time when no one wants to use it. I am not using it myself currently...
When I was watching Araq's presentation at the Nim conference, he mentioned something like "Nim is good for everything..." which, he admitted might be a problem to attract users.
Considering that from the very beginning I did eliminate some languages like {C(++), Java} with several others like {Ada,Haskell,OCaml,D,Rust}, there are not so many choices left - GUI is not a market for Go and it seems that FPC/Lazarus is last resort if everything elsa fails. :-)
So the progress of GTK3 for Nim depends on interest. Andreas recently did the wxWidgets wrapper, and someone did a Qt QML wrapper. Maybe there is more interest.
I was not able to build wxNim although it could be an interesting option, but I'm not sure my skills are appropriate to make it more Nim-idiomatic etc. Otoh, I did play briefly with QML bindings, but I'm still not sure whether it's appropriate or good-enough for desktop apps. For mobile, probably no problem, but I'm skepctical about its usage on the desktop
I think merging GTK2 and GTK3 is not possible, generally my GTK3 bundle covers full GTK2 range.
Well, here I actually meant to join forces and combine the two projects into one instead of separate work on the two. ;)
So, I'll try to build GTK3 bindings and see how it goes, but it's a bit disheartening that even you yourself do not find usage for it. :-(
but it's a bit disheartening that even you yourself do not find usage for it
Main problem is spare time. Seven years ago I started with Ruby, after using languages like C, Modula, Oberon before. Ruby is a fine language, but I would prefer Nim today. But I have much Ruby code now, for example the electronic schematic editor has 6 k lines of code, for porting to Nim my estimation is 400 hours. Of course it would be fun, speed increase for cairo drawing would be nice. But for me the Ruby version is still fast enough, so my motivation spending that time is not that great currently.
Problem with GTK3 is, that it is nearly impossible to sell commercial GTK software for Windows and Mac. I do not intent that currently, but some people may do. And there is no support for mobile devices.
Do you have already some experience with GTK? Do you want to port existing applications, or write something new? And do you want to use that new GTK3 application style, which is usually used now with XML files defining the GUI layout? I have not much experience with the application style, but it is what the core developers use, while most existing tutorials for other languages use more the legacy GTK2 style. For Nim both styles work well.
If you have no experience with GTK already, then maybe wxWidgets or QML is the better choice for you. I think Andreas would be happy if someone uses his wxWidgets wrapper, similar for QML.
If you should decide to use GTK3, let me know when you have some hundred lines of gui code, that will motivate me to release GTK 3.20 bindings...
But for me the Ruby version is still fast enough, so my motivation spending that time is not that great currently.
Fair-enough. ;)
Problem with GTK3 is, that it is nearly impossible to sell commercial GTK software for Windows and Mac. I do not intent that currently, but some people may do. And there is no support for mobile devices.
That's all true, although I'm interested for open-source.
Do you have already some experience with GTK?
Not much.
Do you want to port existing applications, or write something new?
Something new.
If you have no experience with GTK already, then maybe wxWidgets or QML is the better choice for you.
Thank you for the hint.
I think Andreas would be happy if someone uses his wxWidgets wrapper, similar for QML.
Maybe I should try...just a little bit harder. ;)
If you should decide to use GTK3, let me know when you have some hundred lines of gui code, that will motivate me to release GTK 3.20 bindings...
All right...
I just did a stupid toy chess game...
http://ssalewski.de/tmp/toychess.png
Just to get some feeling for coding in Nim -- one motivation was, that I recently discovered that unicode chess fonts exists.
Well, I wrote it from scratch, last weekend move generation as in a precalculated way as known from gnuchess, a very basic board evaluation, and alpha beta pruning as sketched in wikepedia. And yesterday the GTK board with pango unicode pieces. Very basic still, but less then 300 lines of code, 100 kbyte executable size. Would have been much more source code and development time in C. My feeling is that development in Nim is really as fast as in Ruby, maybe even faster when I get more experience. And it is more fun -- chess in pure Ruby would be slow of course. Maybe I will put sources to github at some time -- but of course it is a pure toy project, there a hundreds of chess games available :-)
Some remarks for the case that someone may use the GTK3 3.15.xx wrappers from github: You dont have to run the generator scripts, they will not work with latest GTK3.20 and latest c2nim. Just take the .nim files, they should work for GTK 3.16 and never. And remember that you need all the wrappers from that reposity. Today someone tried with old Nimrod pango, which gave problems. For pango-cairo.nim you have to fix the library name from libpango to libpangocairo, see https://github.com/StefanSalewski/nim-gdk3/issues/4. Similar name change may be necessary for other pango related libraries.
Maybe I will put sources to github at some time -- but of course it is a pure toy project, there a hundreds of chess games available
You should still upload it on github, always good to have more Nim code examples.
@Stefan
Do you want help with porting examples or with nim-gtk3? I'd like to learn more about how gtk3 works, and I have some time. :)
Do you want help with porting examples or with nim-gtk3?
A difficult question. Do you know GTK3 and Nim well and really like GTK and want to really use it?
If not, it may make not much sense. Currently other people seems to be not really interested in GTK -- Dominik did Aporia, but lost interest, and I have to admit that there are some alternative GUI kits now. And we all know the problems of GTK.
For me personally the situation is a bit different, I have used GTK for many years, have at least one Ruby GTK app which I consider to port to Nim, and can currently see no real GUI alternative for me...
The ToDo list would be: Generate with latest c2nim for GTK 3.20 similar wrappers as the ones currently at github. That is not very much work, c2nim is much smarter now than a year ago, i.e. bitfielld and noforward pragma support. There are ten GTK3 related wrappers currently, my estimation is 150 h for that (for me). The only difficult part is converting many of the strange C macros to good Nim ones. I do not know much about Nim macros yet, I have tried to convert a few, which indeed work, but may be not really the best solution. And I hesitate to ask questions about that, there are more important task for the smart developers. Maybe we can wrap some more mudules, for example pixman, and some more. Then we can fine tuning symbol names, add better support for flags. Flags are currently enums, for some OR operation in often used in GTK, so we have to tune that. For that some experience with GTK is necessary, as well as testing.
When that is done, we may add GC support and more Nim like interfaces. For GC support we may wait until Andreas gives us better converter support or delegates. Without that we have to write much code. (You may know the gigantic C++, Ruby, Python, Go, ... wrappers. I hope we can avoid that much lines of code.) Finally, for Nim like interfaces we should write documentation and tutorials, which can be much work. The current plain C like interface is easy to use, we can directly follow C examples. Do you know Ruby GTK3 bindings? Really not bad, but with many differences to plain C interfaces, and the documentation is more about old GTK2, or missing. And there is no clean .nim wrapper file which you can grep. So I have spent many hours for some plain C-GTK3 to RUBY-GTK3 conversion. We really should avoid shiny high level interfaces without documentation.
