More on syntax checking vala - and a nice video
Fetching Resources from github in the App Builder and fake web servers
libvala testing code and extracting API from the vapis
App Builder - Database based Plugin builders for Web components.
Gtk3 introspection updates and Unusable Unity..
GtkDjs, daily builds, added libraries and much more..
To generate the Gtk bindings (and adding other features) for gtkDjs I use a code generator. This is pretty common to all the Gtk bindings. I worked on the PHP-GTK ones a long time ago, which in turn where based loosely off the Python bindings.
For GtkDjs, the starting point was the GtkD binding code. While the current code is still similar to it's parent, It has grown considerably since it's original birth. So In the vain of "if someone ever feels like helping out with the bindings", or wants to write and send me bindings for SQLite, Mysql, curl or libsoup etc. Here's the inside story of them.
The basic concept.
In essence, the bindings work using "generator scripts" called APILookup*.txt, which contain a series of either information, or instructions to do tasks.
Other than the overall configuration settings for the generator, or libraries, the core part of generating bindings is to create classes. In Gtk this is normally done by reading the HTML documentation for a specific Gtk Struct, and using that information to generate data about the Enums, Signals and Methods that are defined. This is all done by GtkClassParser.d
Finally after the File has been parsed, the Output classes "ClassOut, FuncOut, EnumOut, LibraryOut, PhobosOut, SignalOut" generate the code files in the src directory.
Unlike the original GtkD bindings GtkDjs does a double pass at generating each of the packages, as we use the first pass to calculate dependencies and inheritance, rather than relying on the list of imports in the APILookup files. This means that the APILookup*.txt files do not really have to list all the required imports.
More details on the APILookup files.
While I'm not going to explain all the possible commands available in the files, I will explain the concept and a few key ones. The file "GtkWrap.d" contains the parser, with a complete list of keywords and actions, it's a reasonably simple and obvious piece of code. I'm still adding new commands when I see them as necessary, and may even remove a few as some are pretty pointless or unused.. (like code: *** which is ignored but is usefull for reference on how GtkD did things).
The basic concept of the file is a list of data in the formats:
#for simple data
keyword : Value
# for building a list of key value pairs
keyword : key valuepair
#for long data - like code etc.
keyword : subject
......
keyword : end
#for long data - (older style)
keyword : start
......
keyword : end
Order is quite important, as the parser for the APIWrap is not forgiving and can easily go into infinite loops if you get the wrong or unknown keyword in the wrong place. Fortunately using the existing files as a basis for a new one should help out a bit.
The core APILookup.txt files contains a few key pieces of information
The individual Binding for the specific libraries (or packages as the tend to be called) are structured a little differently.
The generator code.
In order of how they are used.
The design differs a little from the original GtkD generator in that I separated the parsing of the documentation and the code generation into separate classes. I felt the original code was pretty huge and unwieldy done that way.
Anyway comment away if you have any further thoughts...
store.append(iter,parentIter);Getting a directory listing uses the new Phobos (or generic D binding backend) binding code.
store.set(iter, 0, "node title");
store.set(iter, 1, {directory: pdir + name + "/" });
var filelist = File.listdir("/home/alan");I did notice one little gotcha for the dmdscript backend, that it does not support the "in" comparison operator Soif ("fred" in myobject) {...}
becomes
if (myobject.hasOwnProperty("fred")) {....}
Talking of gotcha's I spent quite a long time getting the manual to work in IE. My little extjs tricks noted that comma's are a bit of a nightmare in IE, in that It doesnt like trailing comma's in lists of object properties. As typical with any Microsoft product, this is totally inconsistant with the behaviour for arrays, in which case it quite happily accepts trailing commans. Not only does it accept them, it adds an undefined element on the end of the array... - which broke my method list horribly in IE.
Otherwise getting it to work in IE basically consisted of using Ext.DomQuery rather than trying to use standard DOM calls which never seem to work as expected. Anyway comment away...
