auto generate consts from Clang #67
Conversation
allows to use GtkSourceBuffer Added pagenumber function for GtkNotebook
And fix path_at_pos on 64 bit systems
and replace GtkTextBuffer by GtkTextBufferI in text.jl (GtkSourceBuffer inherits from GtkTextBufferI)
List/Tree View Improvement / GtkToolbar / GtkScrolledWindow
Firstly, this interfaces allows us to pass around raw GList pointers without bothering to first box them (which should be nice for performance). Secondly, it creates a real GList type which can be instantiated to create (and gc-root) a real GList (which should be nice for usability enhancements, since we can now code the rest of the GList setter API against this)
|
The enums in gconst{2,3} are twice as many as they also include the constants in the glib namespace. It's probably the right thing to do right now, but if GLib.jl ever get split to it's own package I think we should separate the enums as well. As soon as GI.jl is able to generate cachable methods I will request to add it in METADATA. However there still is the issue of running it on windows, using the preferred winRPM packages. If I understand it correctly, it is openSUSE bulid service that provides the packages for winRPM.jl ( and one should send bulid script patches to) |
|
I have updated #62 for comparision, but most of the non-emum constants seem uninteresting, so I guess one could just append the few that could be useful manually to the clang version. |
|
@ihnorton sweet, i was unable to find that last night. that's perfect |
As an alternative to #62, which requires GI.jl (which is not available from METADATA), this looks at what we get from auto-generating constants via Clang.
Notably: generating the list of constants (non-enum) is very hard (so we don't do it yet). however, the list of enums that this generates is almost twice as long.