(again, bcc'ing mark and ian, also adding ben, because pyjamasdev's mailing list software, lamson, doesn't handle cc)
On Fri, Mar 2, 2012 at 1:04 PM, Jeffrey Van Voorst <[email protected]> wrote: > Given the deafening silence on the Activestate mailing list for pyxpcom, hey - be nice! :) activestate's work is not only technically bloody brilliant but also essential. > I am assuming pyxpcom either works almost flawlessly or no one uses it. ... you ready for a shock? it works almost flawlessly. there's _one_ flaw, which is a very poor substitute for the lack of coclasses: the "optional_arg" parameter. imagine in python, right, instead of having default arguments, you had to put the *number* of arguments... as one of the arguments. i'm putting the answer to the 2nd question you asked in here as well: > Is pyjamas desktop (when using hulahop or xulrunner) a user of pyxpcom or > does pyjd have its own glue/interface to xpcom? it's a user of pyxpcom. pyjamas/pyjd/hula.py's relevant first few lines: import hulahop # this is for storing the gecko stuff (cache, cookies, plugins etc.) gecko_path = os.environ.get('HOME', '.') gecko_path = os.path.join(gecko_path, ".pyjd") hulahop.startup(gecko_path) import xpcom from xpcom.nsError import * from xpcom import components from xpcom.components import interfaces the relationships are thus: * pyxpcom ("import xpcom") is the glue that links python to the NSAPI in libxul.so. * hulahop is the glue that links gtk to libxul.so *AND* allows access to the the xpcom interface. so it's actually hulahop that's the critical linkage, here: the pyjamas-desktop xulrunner port just... takes advantage of that. hulahop is what gtkmozembed _should_ have been (if gtkmozembed had ever been given python bindings). buuut, because gtkmozembed never grew python legs, and was restricted to the c/c++ world, it had all the problems associated with the fact that all the XPCOM IDL definitions, which are exposed via a *binary* interface which you then need to do a total recompile each and every time, and that's what all the fuss was about, and it's why the plug was pulled on gtkmozembed and pretty much all the embedded mozilla efforts. what they _didn't_ take into account was the fact that when you use lazy binding, like pyxpcom does, all the problems of changing binary interfaces just... disappear. you just do not care - period. pyxpcom does all its lookups purely by name (of the function or property). python most likely caches them (__getattr__ etc. etc.) this is what unfortunately the mozilla core team are just... completely unaware of. that it really does actually work, has been working since 2006, doesn't need _any_ development - at all. l.
