Tangled up in Blue

I haven’t blogged much recently, but I put a lot of work in to Seed this weekend and thought I would discuss some of the changes.

New imports system
First I should note that the design of this is pretty much lifted from gjs, and the two implementations should be compatible. I do however think, it’s a very cool system, even if a bit unorthodox.

People who have used Seed would recognize that the two primary methods of importing things are
Seed.import_namespace("Gtk")
For importing libraries and native modules and
Seed.include("bla.js")
for importing files.

This however was pretty ridden with problems, notably:

• Importing GI namespaces had no sort of cache, so multiple files including eachother can’t all import the namespaces they need, one central file would have to import them all and the others rely on that
• No search path for native modules
• The including files, was merely evaluating the file in the context which was called, which could create a lot of scope issues, in particular when you have a lot of complex interdependencies in what files need from what.

So the new imports system works like this, and remedies most of these problems. There is a toplevel imports object, which itself has a “gi” property (the imports.gi object) which handles importing libraries handled by introspection, and has a pretty simple set of semantics, notably the first attempt to access imports.gi.NameSpace will return the module object for that library, and subsequent attempts will return the same object. You can set imports.gi.versions.Namespace to a value to force GI to require that version of the library, so importing a library might now look like.


imports.gi.Versions.Clutter = "0.8";
Clutter = imports.gi.Clutter;
Gtk = imports.gi.Gtk;


The exciting part is really the handling of native modules and files, there is an imports.searchPath property which is set to an array of directories used to search for files/modules. An attempt to access imports.name will now look for “name.*” in search path, and behave as follows:

• If the found file is a native module, import it and return the module object
• If the found file is a regular file, attempt to evaluate it as a JavaScript file in a new context, and return the global object for that context. Unless the file has already been imported, then return the global object from the last import
• If the found file is a folder, return a special object which works like the “imports” object for that folder

So, importing files is now much nicer, i.e.
BrowserView = imports.browser.BrowserView
and then you could access the toplevel contents of the file “browser/BrowserView.js”, through the BrowserView object. This has a lot of advantages, notably any file that needs anything in BrowserView can do this, without having to worry about scope, or overlap with other files that might include it.

All in all I think this is a really big improvement to the maintainability of large programs, and makes it feel like there is much more of a real module system. In addition this should make it pretty possible to port GNOME Shell to Seed, and this is something I will be looking in to.

OS module
There are a lot of low level unix functions not provided by GLib, which might still be useful under Seed, and to that account I’ve taken to reimplementing a large subset of the python “os” module, attempting to preserve semantics where it makes sense, for familiarity purposes. This should be nice for increasing the scope of where Seed is useful, but it’s really boring work…which should hopefully be finished over the next week or so.

Canvas
The canvas module has a pretty large subset of canvas implemented now, and properly handles saving/restoring state. I’m hoping to implement gradients and a few other missing things within the next few days.

DBus
I am still working on DBus bindings, this is slow work, and will be done eventually :P. A lot of work got done recently though, and hopefully should be ready to go in GIT soon.

New Release
After these changes, the goal is to put out a release within the next few days, as soon as someone can find time to update documentation, all the examples, etc…

On top of this there have been all the usual bugfixes, optimizations, and small features, so I definitely encourage anyone interested and using the last release to start investigating GIT. There will be a lot more reorganization of the builtin functions (on the Seed global object) over the next few days, with the goal of eliminating (or eliminating for most code) the requirement of this object, and I suppose this will break most code out there, but I think it’s definitely necessary changes for presenting a more “mature” interface in a sense.