Re: libseed-list js extensions for native modules




 --- On 29/Jun/2010, Jonatan Liljedahl wrote: 
> Ok, so the 'extensions' folder would only be for gi_importer, but native 
> modules should be able to have a .js wrapper in the same dir, like 
> libseed_sandbox.so and libseed_sandbox.js?
> 
> Then the importer should be changed to first look for libseed_NAME.so 
> before NAME.js, and if a .so module was found then also try to eval 
> libseed_NAME.js in the same dir. 

Yeap sounds right.

it seems hard to eval the script with 
> the modules namespace as the global object (even impossible?), but 
> perhaps one could eval the script with 'this' set to the native module 
> namespace, or set it in some other global variable, maybe even named 
> after the modulename?

Not sure why this is needed? The Gobject libs do not need to do this, was there some reason why modules should?

Regards
Alan


> 
> // libseed_sandbox.js
> this.Context.prototype.eval_file = function(fn) {
>      var script = {};
>      GLib.file_get_contents(fn,script);
>      return this.eval(script.contents);
> };
> 
> (then comes the problem with adding stuff to a native module class 
> prototype, next mail...)
> 
> /Jonatan
> 
> Alan Knowles wrote:
> > It would make sens that it should be able to include the higher level
> > wrapper, I think it should only support including the js file from
> > the same path as the extension though, to avoid to much confusion
> > about where the wrapper was.
> > 
> > I think the current arrangement for using the searchPath for
> > extension finding is probably the best behaviour - closed to
> > expected.
> > 
> > Regards Alan
> > 
> > --- On 21/Jun/2010, 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
> > 
> > _______________________________________________ libseed-list mailing
> > list libseed-list gnome org 
> > http://mail.gnome.org/mailman/listinfo/libseed-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]