Sure.
You may have missed the discussion in this forum and the IRC logs?
Only very few people do really want to use GTK -- do you seriously want it?
Most is available already at github, because some people asked to put it there. That includes latest glib, gobject, gdk_pixbuf, pango and cairo. I think that these are really fine now, but comments are welcome. The main modules GDK3 and and GTK3 are currently only on my homepage and my local disk -- I started already to do the small fixes needed for the new naming scheme and the latest GTK 3.15.3. I should be able to provide it in a few days if there is interest. Without interest it may take 2 weeks.
Most is available already at github, because some people asked to put it there
can you please provide a link?
OK, I have finally shipped the initially release of GTK3 wrapper:
https://github.com/StefanSalewski/nim-gtk3
Only minimal tested on Linux yet, library names for windows or mac are only a guess. I think it looks fine, but some improvements are still necessary, i.e. cleaner callback support, default proc parameters and such. Tomorrow I will try to finish GtkSourceView, then we can try Aporia for GTK3. (latest Atk and large GIO wrapper is still missing from the GTK collection -- I guess and hope that is not a big problem. Making these is still some work, and motivation is better when Aporia-GTK3 is working...)
Following test works for me currently: (if someone really should be interested in testing -- you should use all the GTK related wrappers from my github page, not try with the onces shipped with Nim 0.10.2. And you may have to manually create some links to the modules. There is no nimble support currently. )
import gtk3, glib, gobject
# templates like these should be moved to gtk3 module later...
template radio_button_new*(): expr =
new_from_widget(cast[RadioButton](0))
template radio_button_new_with_label*(label: cstring): expr =
new_with_label_from_widget(cast[RadioButton](0), label)
template radio_button_new_with_mnemonic*(label: cstring): expr =
new_with_mnemonic_from_widget(cast[PRadioButton](0), label)
template radio_button_new*(w: RadioButton): expr =
new_from_widget(w)
proc destroy(widget: Widget, data: gpointer) {.cdecl.} = main_quit()
var
i: cint = 0
a: cstringArray = cast[cstringArray](nil)
gtk3.init(i, a) # we should find a smarter init()!
var window = gtk_window_new(WindowType.TOPLEVEL) # gtk_ proc prefix is deprecated, gives fine warning
discard g_signal_connect(window, "destroy", cast[GCallback](test.destroy), nil)
window.title = "Radio Buttons"
echo(window.title)
echo(window.get_title) # get_ is available also
window.border_width = 10
window.set_border_width(10) # set_ is available also
var
r1 = radio_button_new_with_label("Radio_Button 1")
r2: PRadioButton # old deprecated P prefix -- gives warning
r2 = new_with_label_from_widget(r1, "Radio_Button 2")
var
#r3 = gtk_radio_button_new_with_label_from_widget(r1, "Radio_Button 3") # polymorphism works not for deprecated symbols
box = box_new(Orientation.VERTICAL, 0)
box.pack_start(r1, GFALSE, GTRUE, 0) # maybe we should add default values
box.pack_start(r2, GFALSE, GTRUE, 0)
window.add(box)
window.show_all
gtk3.main()@Stefan_Salewski very good job, congrat
I have tested on my Linux and the demo work fine
I wanted to add this as lib on my nimble packages but I had some trouble because you have still some nimrod reference in some `.nimble` file
and also because you reference some future Nim 1.0 ;-) so I have create symbolic link as you do to compile and that work fine
by the way I have add that on my local json package list
{
"name": "nim-gdk3",
"url": "git://github.com/StefanSalewski/nim-gdk3.git",
"method": "git",
"tags": ["gtk3", "library", "wrapper"],
"description": "gtk3 for Nim",
"license": "MIT",
"web": "https://github.com/github.com/StefanSalewski/nim-gdk3"
},
{
"name": "nim-gtk3",
"url": "git://github.com/StefanSalewski/nim-gtk3.git",
"method": "git",
"tags": ["gtk3", "library", "wrapper"],
"description": "gtk3 for Nim",
"license": "MIT",
"web": "https://github.com/StefanSalewski/nim-gtk3"
},
{
"name": "nim-glib",
"url": "git://github.com/StefanSalewski/nim-glib.git",
"method": "git",
"tags": ["gtk3", "library", "wrapper"],
"description": "gtk3 for Nim",
"license": "MIT",
"web": "https:/github.com/StefanSalewski/nim-glib"
},
{
"name": "nim-gobject",
"url": "git://github.com/StefanSalewski/nim-gobject.git",
"method": "git",
"tags": ["gtk3", "library", "wrapper"],
"description": "gtk3 for Nim",
"license": "MIT",
"web": "https://github.com/StefanSalewski/nim-gobject"
} ,
{
"name": "nim-cairo",
"url": "git://github.com/StefanSalewski/nim-cairo.git",
"method": "git",
"tags": ["gtk3", "library", "wrapper"],
"description": "gtk3 for Nim",
"license": "MIT",
"web": "https://github.com/StefanSalewski/nim-cairo"
}
I have tested on my Linux and the demo work fine
Fine. I will fix the nimble files -- indeed a reference to old nimrod name should not exist. With the >= 1.0 requirement -- seems that I was too optimistic about the release of Nim 1.0. Maybe I should relax that to 0.10.2? Generally I have no Idea how my modules can coexist with the old GTK2 ones which may have the same name. I will care for that problem when Aporia_GTK3 is working and when really a few people should be interested in using GTK3 with NIm.
and yes that would be great to have Aporia with Gtk3
Have just uploaded GTK-Source-View:
https://github.com/StefanSalewski/nim-gtksourceview
The nimble files should be fixed also now -- Nim version required is relaxed to 0.10.2.
For gtksourceview it was necessary to export a few more symbols from GTK3 and other related modules, so for using gtksourceview you have to checkout the latest version.
Thanks for testing.
I may had a very similar problem for my first tests, it may be simple related to missing files (config or init files). Aporia has not much code for error checking currently. Unfortunately I can not really remember which files I had copied to make it run. Nim.lang was one, but there may have been other .
I will try to test soon, maybe I should put some error detection code into aporia.
[EDIT] I have just done some test...
rm -rf .config/Aporia
seems to be not a real problem, aporia can still start, but I get warnings like "(aporia:1053): GLib-GObject-CRITICAL : g_object_unref: assertion 'G_IS_OBJECT (object)' failed"
rm /usr/share/gtksourceview-3.0/language-specs/nim.lang
is a problem:
$ aporia/aporia Traceback (most recent call last) aporia.nim(2516) aporia aporia.nim(2442) initControls aporia.nim(2180) initTAndBP aporia.nim(2112) initsourceViewTabs aporia.nim(771) addTab system.nim(3034) failedAssertImpl system.nim(2238) raiseAssert Error: unhandled exception: win.nimLang != nil [AssertionError]
But it is different from your problem. I will look at the code tonight, maybe I will get an idea.
[EDIT2:]
I have done a short look at the code.
seems that
proc list_store_new*(n_columns: gint): ListStore {.varargs,
importc: "gtk_list_store_new", libgtk.}
is called and fails. Please exchange line 2166 in aporia.nim with
echo "Aporia.nim, calling listStoreNew()..."
echo "G_Type_String is: ", G_Type_String
var listStore = listStoreNew(6, G_Type_String, GTypeString, GTypeString,
GTypeString, GTypeString, GTypeString)
echo "Aporia.nim, called listStoreNew()"
assert(listStore != nil)
echo "Aporia.nim, checked result for nil"
and test again. I have not really an idea what may be wrong for you, but it should be at that location. For me output is
Aporia.nim, calling listStoreNew()... G_Type_String is: 64 Aporia.nim, called listStoreNew() Aporia.nim, checked result for nil
Do you have a 32 or 64 bit Linux OS, what is your Nim and C compiler version?
I use Linux 64bits, Nim 0.10.3, gcc 4.8.2
after some debug I have found where the problem is located in Aporia.nim (6167)
var listStore = listStoreNew(6, G_Type_String, GTypeString, GTypeString,
GTypeString, GTypeString, GTypeString)I don't know the purpose of this function nor where it is defined
but Aporia work if I change randomly to
var listStore = listStoreNew(4, G_TYPE_STRING, GTypeString, GTypeString, GTypeString)edit
hum sorry , just read your edit after this post
Re Edit
Very strange if I only add this line
echo "G_Type_String is: ", G_Type_Stringbefore the call of
var listStore = listStoreNew(6..it work and without (comment the line) .. it fail as if the echo with G_Type_String change anything (and btw the anwser is 64)
(tested 2 times)
Thanks, that is very interesting...
So the problem is indeed this function. It uses varargs, maybe it is related to that. My first idea was argument size, 32/64 bit, but as you have a 64 bit Linux too, that should be not the problem. Would be easier to discover when it would fail on my computer too. I will do some test and look at the generated C code in the next days. Should be easy to find and fix. Thanks for your support.
[EDIT]
From your observations, echo before proc call makes a difference, argument size may be indeed a problem. If you want to do more testing, something like int64(G_TYPE_STRING) for all the arguments may be a starting point, or int32? I have to read in the manual how varargs works in detail and what argument size is.
[EDIT2]
In nimcache/aporia_aporia.c I have
liststore = Dl_198658(((int) 6), 64, 64, 64, 64, 64, 64);
My feeling is, that that may be wrong. I think that it should read GTYPE (64) each, and GTYPE should be something like gulong or csize, which should be 8 byte. But the plain number 64 should be 4 byte. That is for AMD64. I have currently no idea where the problem may be located, I tried hard to define type GSIZE correctly in glib.nim or gobject.nim. There is a template in gobject.nim, maybe that will not provide size information?
template g_type_make_fundamental*(x: expr): expr = (GType(x shl G_TYPE_FUNDAMENTAL_SHIFT))
Or may this be wrong?
const
G_TYPE_FUNDAMENTAL_SHIFT* = 2
# when GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG or not defined(cplusplus):
when sizeof(csize) != sizeof(clong) or not defined(cpp):
type
GType* = csize
else:
type
GType* = gulong
template g_type_make_fundamental*(x: expr): expr =
(GType(x shl G_TYPE_FUNDAMENTAL_SHIFT))
const G_TYPE_STRING* = g_type_make_fundamental(16)
var listStore = listStoreNew(6, int64(G_Type_String), int32(GTypeString), gobject.GType(GTypeString),
GTypeString, GTypeString, GTypeString)
gives in the C code
liststore = Dl_198658(((int) 6), IL64(64), ((NI32) 64), 64, 64, 64, 64);
So int64 and int32 has an effect, but GType is fully ignored. That may indeed be a problem. But I have still no idea why and how to solve it best.
@Stefan
Yes I can confirm this call make thing work with no problem
var listStore = listStoreNew(6, int64(G_Type_String), int32(GTypeString), gobject.GType(GTypeString),
GTypeString, GTypeString, GTypeString)I have added the modules ATK and GIO to the GTK3 collection, so the set is nearly complete (guess there exist something small like GModule, and maybe Pixman and GIntrospection, which is still missing?) There are 10 modules total now, plus the Aporia-GTK3 for testing.
https://github.com/StefanSalewski?tab=repositories
Glib, Gobject and Cairo are unchanged, the other seven now import a few symbols from GIO and ATK. The problem with varargs should be fixed for latest Nim 0.10.3 now also (http://forum.nim-lang.org/t/920). For Mac I have changed gdk3 and gtk3 library names, someone told me. I have also fixed a few small bugs -- unfortunately testing all 10 modules with its dependencies and all target and backend options is some work. My main test object is Aporia-GTK3, which compiles fine for Linux and basically works, but is giving same GTK error messages in the console window. Unfortunately latest nimsuggest is not includes in my GTK3 version yet, maybe I will add it later. There is still no nimble support, you have to download all 10 modules manually and then create links from your working directory to the modules. I think there is no better way to make my modules coexist with the legacy gtk2 modules yet.
I have just added the first larger example to the GTK3 collection:
https://github.com/StefanSalewski/nim-gtksourceview/tree/master/test
Test_completion.nim is a translation of the C test-completion.c example of gtksourceview. It includes some non trivial code, including generation of new GObject types. For that, I have converted a necessary larger C macro to Nim and added that one to module gobject. That example uses gtk builder to read the user interface layout from a xml file. The example program uses only stupid text completion, I have not yet tried to add nimsuggest support.
I was surprised how well c2nim 0.97 translation of gtk c programs to Nim works, only a few manual fixes where necessary. Unfortunately due to bug https://github.com/Araq/Nim/issues/1762 some deprecated symbol names can result in strange compiler error messages. The executable size is 100k compared to 20k of the C original, compiled with gcc 4.9.2. I think that is not too bad, and clang may give even smaller executables.