|
osdir.com mailing list archive |
|
Subject: RE: XPCOM, XUL and wxPython... - msg#00003List: mozilla.devel.xpcom.python> XPCOM component - that could then be bound to a new XUL element. > So much for my naive view :-) Actually, there was an effort to "xpcom-ify" the plugin API. I've no idea of the progress of that, but once complete, that would be exactly what is offered. [Indeed, http://www.mozilla.org/projects/plugins/ implies that such a facility is avilable now - but I've never looked at it] > Since a plugin requires C anyway using wxWidgets directly, It need not use wxWidgets directly. It would be perfectly reasonable to have the C code delegate immediately to .py code, and have that code use wxPython. That way the C layer can be used for *any* Python implemented plugin and no programmer other than the author of that C layer would need to use C. Indeed, if the plugin API was xpcom-ified, that is exactly what happens - its just that xpcom does the delegation magic for you and *noone* needs write any more C code :) Mark Thread at a glance:
Previous Message by Date: click to view message previewRe: XPCOM, XUL and wxPython...>From my 10,000 foot level I thought you could define a "visual" XPCOM component - that could then be bound to a new XUL element. So much for my naive view :-) Since a plugin requires C anyway using wxWidgets directly, and bypassing wxPython, would be the way to go. I was hoping to avoid C/C++ altogether. Still, interesting possibilities. thanks for the info. Jim Mark Hammond wrote: I'm wondering if it would be possible to wrap a wxPython control and call it from XUL. Similar to how ActiveState Komodo wraps Scintilla as an XPCOM. Having the ability to script any wxPython control via XUL would be a big advantage IMHO - especially if you could bypass the C++ layer (wxWidgets) and do it all in Python. Komodo has a "plugin" around scintilla - as far as I know, plugins are the only way of using a "native" window inside Moz. I see no reason that a plugin couldn't be written which targets Wx - although last time I looked, plugins still needed to be implemented in C (but such C could could easily delegate to Python) Mark Next Message by Date: click to view message previewcompiling xulrunner with python supportHello all, I'm trying to compie xulrunner with python support (both python/dom, python/xpcom) with no results. I use a linux (debian), gcc-4.0, here is my .mozconfig : mk_add_options MOZ_CO_PROJECT=xulrunner ac_add_options --enable-application=xulrunner ac_add_options --enable-default-toolkit=gtk2 ac_add_options --enable-xft ac_add_options --enable-extensions=python/xpcom,python/dom,default ac_add_options --disable-optimize ac_add_options --disable-debug mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/xulrunner I tried to build xulrunner with the release 1.8.0.1 and the HEAD, did work with python/xpcom but fail with python/dom extension. So I checked out the DOM_AGNOSTIC2_BRANCH and tried again... link failed with a lot of : XRemoteClient_standalone.o:(.gnu.linkonce.d._ZTV14nsRemoteClient[vtable for nsRemoteClient]+0x8): référence indéfinie vers « __cxa_pure_virtual » I added manually -lsupc++ option to the linker, and then while compiling libpydom.so I get : /usr/bin/ld: nsPyContext.o(.text+0x1374): unresolvable R_386_GOTOFF relocation against symbol `PyCode_Type' I Just don't undestand this error and google is not my friend this time. Any idea ? -- _____________ Maric Michaud _____________ Aristote - www.aristote.info 3 place des tapis 69004 Lyon Tel: +33 426 880 097 Previous Message by Thread: click to view message previewRe: XPCOM, XUL and wxPython...>From my 10,000 foot level I thought you could define a "visual" XPCOM component - that could then be bound to a new XUL element. So much for my naive view :-) Since a plugin requires C anyway using wxWidgets directly, and bypassing wxPython, would be the way to go. I was hoping to avoid C/C++ altogether. Still, interesting possibilities. thanks for the info. Jim Mark Hammond wrote: I'm wondering if it would be possible to wrap a wxPython control and call it from XUL. Similar to how ActiveState Komodo wraps Scintilla as an XPCOM. Having the ability to script any wxPython control via XUL would be a big advantage IMHO - especially if you could bypass the C++ layer (wxWidgets) and do it all in Python. Komodo has a "plugin" around scintilla - as far as I know, plugins are the only way of using a "native" window inside Moz. I see no reason that a plugin couldn't be written which targets Wx - although last time I looked, plugins still needed to be implemented in C (but such C could could easily delegate to Python) Mark Next Message by Thread: click to view message previewcompiling xulrunner with python supportHello all, I'm trying to compie xulrunner with python support (both python/dom, python/xpcom) with no results. I use a linux (debian), gcc-4.0, here is my .mozconfig : mk_add_options MOZ_CO_PROJECT=xulrunner ac_add_options --enable-application=xulrunner ac_add_options --enable-default-toolkit=gtk2 ac_add_options --enable-xft ac_add_options --enable-extensions=python/xpcom,python/dom,default ac_add_options --disable-optimize ac_add_options --disable-debug mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/xulrunner I tried to build xulrunner with the release 1.8.0.1 and the HEAD, did work with python/xpcom but fail with python/dom extension. So I checked out the DOM_AGNOSTIC2_BRANCH and tried again... link failed with a lot of : XRemoteClient_standalone.o:(.gnu.linkonce.d._ZTV14nsRemoteClient[vtable for nsRemoteClient]+0x8): référence indéfinie vers « __cxa_pure_virtual » I added manually -lsupc++ option to the linker, and then while compiling libpydom.so I get : /usr/bin/ld: nsPyContext.o(.text+0x1374): unresolvable R_386_GOTOFF relocation against symbol `PyCode_Type' I Just don't undestand this error and google is not my friend this time. Any idea ? -- _____________ Maric Michaud _____________ Aristote - www.aristote.info 3 place des tapis 69004 Lyon Tel: +33 426 880 097 Loading Comments...
|
|
