[Sugar-devel] Browse and the move to WebKit

[lkcl luke]

hi todd, thanks for responding here.

On Tue, Feb 21, 2012 at 11:41 PM, Todd Whiteman <toddw at activestate.com> wrote:

> PyXPCOM supports all XulRunner versions from 1.9.1 through to XulRunner 9.0
> - versions are tagged in hg here:
>    http://hg.mozilla.org/pyxpcom/tags

 ... but debian has *already* moved on beyond xulrunner 9.0.  the
opportunity to compile a version of xpcom and hulahop that can be
released at the same time as firefox - and uses the same shared
xulrunner library - has already gone.

> Komodo is the prime example of an application using PyXPCOM successfully,
> using versions 1.9.1, 2.0.0 and currently using 7.0.0 in Komodo 7.

 yes.... but it's maintained as an entirely separate version of
xulrunner, which is compiled for installation in a completely separate
location.  i.e. if you install komodo i believe you get something like
/usr/lib/komodo/xulrunner-7 *not* /usr/lib/xulrunner-7/{libraries}

 so yes this is a "solution" - have

> For Canvas DrawImage problem - it looks like PyXPCOM does not support the
> "optional_argc" IDL/xpcom setting. This should get a bug report it, as I'd
> imagine it's fixable in pyxpcom.

 yes.  i started looking at what would be involved - the optional_argc
is a flag that goes into the type library: flags get picked up by
pyxpcom and i did track down that yes, that bit of the flag is simply
completely ignore in pyxpcom.  however that shouldn't be a problem: it
*should* be possible to just specify all 9 args (in the DrawImage
case) but even there i am _still_ getting "error invalid" return
results.

 anyway this is OT... slightly... ok it's not quite OT, but it's
getting into detail.


>> On Tue, Feb 21, 2012 at 7:59 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>>  so, to summarise:
>>
>>  * python-xpcom not being part of mozilla-central is causing
>> python-xpcom to be "out of sync" (for example that massive PRBool ->
>> bool update)
>
>
> The Mozilla applications (Firefox, Thunderbird, ...) do not use the Pyxpcom
> code - so I don't think they should have to maintain it. The Mozilla code is
> changing fast nowadays,

 yes.  that's causing problems.  it's too fast for distributions to
keep up, and it's too fast for non-funded, non-full-time,
non-fully-paid-up-employee-supported projects to be able to cope with.

 it's worth reiterating that the OLPC team have got so sick of this
situation that the key developer responsible for the web browser
"activity" pulled the plug on mozilla-foundation-sponsored technology.

 to reiterate: mozilla foundation technology will *not* be present in,
nor will it ever be endorsed by, OLPC.


> and it shouldn't have to wait on smaller projects
> like Pyxpcom to become compatible.

smaller projects??  i'm not very impressed by the view that says that
"smaller projects" which utilise mozilla foundation technology are
quotes "unimportant".

where exactly should the line be drawn?  what qualifies as a "smaller
project", such that the mozilla foundation does not care one bit about
whether it works or does not work?

if someone would like to write an official explanation for posting on
the pyjamasdev mailing list, that the official position of the mozilla
foundation is that they are entirely on their own and, as python
programmers with no c and c++ experience whatsover they must download
tens of megabytes of source code and must learn to compile it
themselves _and_ maintain the release cycle on it, i'll be happy to
forward it on.  i ain't writing it.


> Pyxpcom has not been updated for Mozilla central (XulRunner 11+) yet. Komodo
> (ActiveState) has plans for continued Pyxpcom use, so I'm sure that it will
> get updated some time in the future. If anyone else has need of it sooner -
> they too can fix the Pyxpcom code and contribute the changes back... this is
> how Open Source projects work.

 yehhhs.... they could.... *if* they had the time and/or money to do
so, _and_ the skillset to tackle *more* technology areas than are
covered by *TEAMS* of full-time-funded people [the mozilla foundation
fully-paid-up employees].

 the skillset required to take this on really is larger than that
which even those people who normally contribute to mozilla are used
to.  not only do you have to know the xulrunner codebase, but also you
have to know python, you have to know GTK, you have to know how XPCOM
works, you have to have a vague understanding that it's similar to
microsoft COM.

 to expect the average programmer to be able to just... randomly take
that on "for fun" and "for free" is just.... nuts, todd!

 i mean... i can't quite believe what you're suggesting here [i'm
speaking rhetorically here, allow me a little leeway, ok? :) ]


>>  * python-xpcom is middleware so *cannot* have comprehensive tests
>
>
> Note that Pyxpcom does have its own set of tests to test the Python XPCOM
> functionality:
>    http://hg.mozilla.org/pyxpcom/file/3856dbd68d5d/xpcom/test
> so being middleware is not a testing problem.

 ok, the problem is this: xpcom's testing covers xpcom codepaths.  as
middleware, it tests the NPAPI and the XPCOM interfaces, right?  what
it *doesn't* test is the GTK widget *display* side, does it?

 is there a test in python-xpcom which tests for "GTK Mouse
Interaction", reacting to x-windows events?

 is there a test in python-xpcom which tests for "GTK Window Set Focus"?

 ... there isn't, is there?

 there _are_ however such tests in firefox (i presume!) - even if
they're run manually (or under selenium or somesuch).

 ... but there are *no* such tests for running
xulrunner-from-python-on-screen-as-a-gtk-application, are there?
because hulahop is an "external" application.

and that's where things go badly wrong, because as that bug i
mentioned earlier shows
(https://bugzilla.mozilla.org/show_bug.cgi?id=728645) there are
code-paths that are *not* being properly tested when xulrunner is
fired up inside firefox (that's one possible explanation), such that
an error doesn't show up.

so yes, damnit - if the mozilla foundation wants to do accelerated
release cycles, then yes, damnit they should actually help the other
projects out there, and not "leave them smashed in pieces by the
wayside".

as they're _not_ doing that, it's precisely why the OLPC team have
abandoned hulahop - which they wrote! - and are so pissed off with the
mozilla foundation that many of them - including the lead developer of
the web browser activity - have publicly stated that they refuse to
use mozilla foundation technology _period_, and have removed firefox
entirely from their machines.

 if that's the kind of message that the mozilla foundation would like
end-users of the OLPC software to receive (children in educational
environments) - that the people who wrote the software that they are
using DO NOT use firefox, then yes, please feel free to treat
python-xpcom and hulahop as "just a smaller project".

l.