Mozilla, XUL and the snake

[Jakub Fast]

Hi,

Does anybody know how far you can get nowadays with trying to use Python
as the script language for XUL instead of JS? Is it possible (even
theoretically) to write full-fledged applications on the Mozilla
platform with python only?

In a parallel vein, anybody know what the architecture of Komodo is?

Thanks for any pointers, information, etc

Kuba

PS. Yes, I have seen the recently-publicized wishlist for Mozilla 2 and
I have tried to run MozPython in M1.7 or F0.9, and failed miserably. I
have been trying to dig through the Mozilla docs to find anything I
could infer this information from, but it seems that the amount of
mozilla docs that "might contain some hidden clues" piling up in front
of me is neverending...

 

[deelan]

Hi,

Does anybody know how far you can get nowadays with trying to use Python
as the script language for XUL instead of JS? Is it possible (even
theoretically) to write full-fledged applications on the Mozilla
platform with python only?

yeah, theoretically is it possible by using PyXPCOM:
<http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXPCOM/>

the author of mozpython offers binaries of
pyxpcom, cuz is damn tricky to compile the package:

<http://www.thomas-schilz.de/MozPython/downloads/>

HTH,
deelan

 

[Jakub Fast]

yeah, theoretically is it possible by using PyXPCOM:
<http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXPCOM/>

Isn't using JavaScript the only way to call XPCOM objects from XUL? I
was aware of PyXPCOM, I was just wondering whether it was possible to
get rid of JavaScript altogether...

Kuba

 

[Jon Perez]

It might be a good idea if a Python module were created that
supported XUL (whether based on the Mozilla, Luxor, Microsoft XAML
dialect or its own, presumably improved and more pythonic, one)
for GUI creation that was directly importable ala Tkinter or PyGtk.
This will probably run on top of (in order of preference):

a) straight Xlib (in the case of *nix) and Win32 GDI calls (and
in Longhorn and beyond, Avalon subsystem calls) so as to cut
the proverbial gordian knot of layers.

b) [Py]Gtk or [Py]Qt

c) Tkinter (with all those layers, this might result in a UI
that responds even more slowly than Mozilla)

Further, we might even want to do away with, or have an alternative
Python syntax, for XUL in the spirit of the XUL Compact Syntax
(see http://xul.sourceforge.net/compact.html )

For me, it all depends on how difficult it is to get Python to
integrate with XPCOM/Mozilla gracefully the way Javascript already
does today. (Seeing as how Blackwood - Java<-->Mozilla integration -
has stalled, is JNI to blame or would the difficulties also apply
to Python<-->Mozilla integration?)

[ If it cannot be made to work as simply and straightforward as
calling Javascript today (via onXXXevent='' attributes), then
I don't see much of an advantage with this approach. Otoh, if
it can be made so, then MozPy (and PyMoz - turns out there is
such a thing!) would truly rock as in addition to XUL scripting,
we would actually be able to create DHTML/DOM pages which we
can client-side script via Python instead of the much hated
Javascript. ]

We would rather not reinvent wheels... In fact, if you think about
it, XPCOM is a platform with a widget set/layout engine (with
NSPR - Netscape Portable Runtime - as the OS functionality layer)
that's a reinvention of what Gtk and Qt already do (and to a big
extent Python, with all of its modules, is its own platform too!)!
The difference with Mozilla vs Gtk/Qt is that it doesn't seem that
they are offering their widget set for 'imperative' use (i.e. use
programming language calls to create widgets), rather it's totally
declarative (via XUL).

 

[Lars Heuer]

Hi Jakub,

Isn't using JavaScript the only way to call XPCOM objects from XUL? I

No, pyXPCOM does it, too.

was aware of PyXPCOM, I was just wondering whether it was possible to
get rid of JavaScript altogether...

Currently you'll have to use JavaScript to let the XUL forms react to
user's input etc., it's not possible to replace JavaScript with Python
(currently).

Best regards,
Lars