On Wed, May 24, 2000 at 10:22:26AM -0700, David Ascher wrote:

There are two levels of integration of other scripting languages, one easier than the other. We'll be tackling the ability to make XPCOM components in Python and Perl first. This doesn't allow the use of those languages in a XUL file, however, as that requires architectural changes to the Mozilla core. We will be working with Netscape to solve that problem as well, but not in the short term. Nevertheless, I think you'll be pleased to see what can be accomplished with Python and Perl components...

Stop it, you have me drooling already! I take it Python will not loose it's ability to import other Python modules. A decent XML-Parser at last! -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------

Hi Michael --

Would you please expand on the "make XPCOM components" task.

I could, but you ask all the right questions, so I can just answer those.

By this are you adding new components, written in Python, that will be accessible through the XPCOM interface?

Yes.

Would these components be constructed in Python from components interfaces that are accessible through the XPCOM interface?

Yes.

If this isn't the case then is does this simply mean that Python can be used to assemble chrome using existing XPCOM components.

It is the case, so "no". I read that last sentence as "can you use Python to assemble existing components [written in e.g. C++]". While that is _a part_ of the capability we're talking about, we are also talking about the ability to have Python components act invisibly to the rest of Mozilla as full-fledged XPCOM components (much like existing C++ components currently). This is not unlike what one can do in PythonCOM currently in the Windows world.

Are you doing this by wrapping the the interface to the XPCOM Type Library or will you be parsing the XPIDL files directly. (Another interesting approach is the way the ORBit-Python project reads CORBA IDL files at run time and links directly to an ORBit ORB.)

The former.

By this do you mean that in the following XUL the value of "oncommand" cannot be python code?

<menuitem value="Mozilla Help" oncommand="window.openDialog('chrome://help/content/help.xul', '_blank', 'chrome,all,dialog=no')" />

Correct.

or are you talking about not being able to embed Python instead of javascript as in the following:

<script language="javascript"> function doCMD(el) { v = el.getAttribute("value") if (v == "New") alert('New clicked') elsif (v == "Open") alert('Open clicked') else alert('Close clicked') } </script> ... <menu class="menu" value="File" oncommand="doCMD(event.target)"> <menupopup> <menuitem oncommand="alert('New item alert')" value="New" /> <menuitem value="Open" /> <menuitem oncommand="alert('Close handler')" value="Close" /> </menupopup> </menu>

That too. Both of those (really the same feature) require considerable changes to the parser and to the DOM model, as documented in e.g. http://www.mozilla.org/scriptable/agnostic.html. Again, that is part of our long-term plan.

Instead of using XUL to write the <menuitem...> definition from the first example or the <menu...> definition in the second example will it be possible to write the equivolent of the XUL completely in Python? That is, will the planned interface make it possible to build an XPCOM component based application, such as the Mozilla browser, entirely in Python.

In the long term, yes -- but not in the short term. In the short term you'll have to use some JS in XUL files, although it will be able to reference and call and manipulate components written in Python outside of the XUL.

An interface between the Glade IDE and Mozilla has recently been checked into Sourceforge. The documentation on MozGlade is weak. The freshmeat announcment http://freshmeat.net/appindex/2000/05/16/958529719.html hints at the goal. The project looks like it might intersect with the goals of the Komono IDE project.

I'll look into it, thanks for the pointer.

Will there be a mailing list for the project?

We're still working out how to proceed with respect to working with folks outside of the company. I expect much of the discussion will take place on existing Mozilla newsgroups.

What is your best guess on when the "make XPCOM components" capability will be available for testing from the Mozilla CVS?

Sorry, I'm unable to give a best guess at this point with any meat behind it, especially when it involves integration with the main Mozilla tree, over which we have no control. While it's not a direct answer to your question, we are collecting email addresses of those who want to be notified when Komodo is ready (http://www.activestate.com/Products/Komodo.html). I hope the above is helpful. -- David Ascher PS: Wouldn't it make sense to trim the main Zope mailing list from this thread? I see it as being Mozilla-centric, not Zope-centric.