Re: libseed-list js extensions for native modules

[Jonatan Liljedahl <lijon kymatica com>]

Also, it should work to add methods to SomeClass.prototype in native 
modules. Currently it does not:

imports.sandbox.Context.prototype.eval_file = function(fn) {
    var script = {};
    GLib.file_get_contents(fn,script);
    return this.eval(script.contents);
};

c = new imports.sandbox.Context;
c.eval_file(foobar);

TypeError Result of expression 'ctx.eval_file' [undefined] is not a 
function.

It does work for GI modules, as seen in extensions/Gtk.js

/Jonatan

Jonatan Liljedahl wrote:
> The gi_importer tries to import extensions/name.js by evaluating 
> "imports.extensions.name". It would be nice if this also worked for 
> native modules, I imagine it to be quite common that you write a module 
> with core parts in C and some high-level stuff in js.
>
> The question is, how should this be handled regarding searchpaths etc?
>
> If your module is installed in /usr/local/lib/seed, then you probably 
> installed the extension js in /usr/local/share/seed/extensions, and 
> imports.extensions would be the right thing.
>
> But what happens if your module is installed somewhere else? It should 
> probably start with the same dir as the native module, then go on with 
> imports.searchPath, and if the file is found call 
> seed_importer_handle_file() on it..
>
> BTW, what happens if you have 'extensions' folder in more than one 
> search path? will extensions.foo search for 'foo' in all of those or 
> only the first match for 'extensions'? Just doing a 'imports.extensions' 
> will of course create only one dir_importer for that folder, hiding 
> possible 'extensions' folders later in the searchpath. I don't know if 
> this is a good thing...
>
> /Jonatan
> _______________________________________________
> libseed-list mailing list
> libseed-list gnome org
> http://mail.gnome.org/mailman/listinfo/libseed-list