Document how to import using Cu.import or require

[jaredhirsch]

Hey there - I'm having some trouble figuring out how to import this code.

I can't just use Cu.import because the files assume ctypes is an available global.

I tried wrapping the subscript loader calls inside a jsm-style loader module, but this throws, because the individual files try to overwrite EXPORTED_SYMBOLS declared by the loader.

Currently using copy-pasted copies of the libs I need, with Cu.imports sprinkled in to resolve the global definition errors. Is there a better way?

[Noitidart]

Hey 68! Cu.import doesn't work because that expects a stand alone module. ostypes needs to be in the same scope. I do this by equivalent of <script src="blah"> which is Services.scriptloader.loadSubScript:

const {utils: Cu} = Components;
// var { Cu } = require('chrome'); // if you are using Addon SDK
Cu.import('resource://gre/modules/Services.jsm');

var GLOBAL_SCOPE = this;

function importOstypes() {
  Services.scriptloader.loadSubScript('chrome://myaddon/content/ostypes/cutils.jsm', GLOBAL_SCOPE);
  Services.scriptloader.loadSubScript('chrome://myaddon/content/ostypes/ctypes_math.jsm', GLOBAL_SCOPE);

  var os_name = Services.appinfo.OS.toLowerCase();
  switch (os_name) {
      case 'winnt':
      case 'winmo':
      case 'wince':
              Services.scriptloader.loadSubScript('chrome://myaddon/content/ostypes/ostypes_win.jsm', GLOBAL_SCOPE);
          break;
      case 'darwin':
              Services.scriptloader.loadSubScript('chrome://myaddon/content/ostypes/ostypes_darwn.jsm', GLOBAL_SCOPE);
          break;
      default:
          // we assume it is a GTK based system. All Linux/Unix systems are GTK for Firefox. Even on Qt based *nix systems.
          Services.scriptloader.loadSubScript('chrome://myaddon/content/ostypes/ostypes_x11.jsm', GLOBAL_SCOPE);
  }
}

[jaredhirsch]

@Noitidart Hey, thanks for the response :-)

I actually tried the function above in a JSM-style loader, but some of the ostypes files actually carry an EXPORTED_SYMBOLS global, which clobbered that global in my loader, causing it to throw. I thought the presence of EXPORTED_SYMBOLS might mean you were planning to move to a JSM-style module system, sounds like that's not the case.

I'll try wrapping that loader function in an SDK/CommonJS-style module instead of JSM-style and, if it works, I'll open a PR to add some hints to the Readme ^_^

[Noitidart]

Oh interesting. Excuse that please I haven't worked with common js modules yet or read on it. I would learn a ton about it from that possible PR! :)

[jaredhirsch]

Oh, you've worked with CommonJS modules--that's the module.exports / require API that you're likely familiar with from the FF SDK. More details here.

I spent half an hour on this earlier this evening, but ran into an unrelated bug. I'll try to get a PR out, most likely next week.

[Noitidart]

Ah yes! Terminology kills me haha. Thanks for the lesson! Anything that pops up please let me know if I can help.

Originally this was designed to run in ChromeWorker (off main thread) scope with importScripts and being fed from the main thread a value for GDK_TOOLKIT (as Services.appinfo.widgetToolkit isn't available in Workers). I had to bring it to the main thread as some platform APIs. Especially on mac, anything that deals with NSWindow has to be on main thread - http://stackoverflow.com/a/11900929/1828637 - callbacks that tell the API to look for the callback on the worker thread work but doing things like:

dispatch_sync(dispatch_get_main_queue(), ^{
    // Do your UI updates!
});

Doesn't work with js-ctypes due to a bug in Firefox. As the platform API expects to access it from the main thread, it causes firefox to crash. In C++ we can share between threads but not with ChromeWorkers/WebWorkers.