[Zope] RE: [Zope-Moz] Good news for Zope/Mozilla efforts!

[David Ascher]

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.