[sugar] [pyxpcom] PyXPCOM viability and OLPC

[Marco Pesenti Gritti]

On Wed, 2007-05-09 at 10:51 -0400, edward baafi wrote:
> > I looked a bit into this, it seem pretty simple in theory. Then I tried
> > to compile pyxpcom and it fails to build on the trunk:
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=375318
> >
> > The last patch there apply cleanly but doesn't solve the problem for me.
> > I didn't try the previous patches but bsmedberg think they are wrong
> > so...
> >
> > Pyxpcom looks pretty much unmaintained, which isn't promising :/
> 
> 
> To be fair, I think people are confusing the state of the mozilla
> beast with the state of pyxpcom..

Well, I'm used to deal with the mozilla beast...

> If pyxpcom doesn't build, it usually means that someone else has
> broken it..

Yeah but the fact that the maintainer didn't care about getting it fixed
for more than one month (the bug has been reported on 2007-03-25) is not
encouraging.

>  Remember, mozilla is a beast and major revisions need to
> land before we jump from Firefox2 (gecko1.8.1) to Firefox3
> (gecko1.9)..  I haven't built the trunk in a while.. I might have some
> time over the weekend to try to build it..  In the meantime:
> 
> 1) how are you trying to build pyxpcom: standalone, or as part of xulrunner?

Part of xulrunner.

> 2) If you're building as part of xulrunner, can you build xulrunner
> without pyxpcom? (this is a prerequisite)

Sure.

> 3)What does your build environment look like? Are you doing anything
> laptop.org specific?

Nothing particular no. I'm pretty sure you will get the same issue if
you try to build trunk.

> Some things to keep in mind:
> 
> 1) I'm a single developer who was able to navigate the mozilla beast
> to get some traction with xulrunner + pyxpcom on my own time.. This
> was early when people were having trouble just building xulrunner so
> this is definitely doable now, but you have to decide that you need
> this technology first and just dive in..

We *do* need the technology. We might not have resources to make it
work, though.

> 2) To decide that you need this technology, you only have to ask
> yourselves two questions:  a)Do we want a gecko based browser? b)are
> proper python bindings a must?
> 

Definite yes to both a) and b)

> 3) I think once you're able to build xulrunner + pyxpcom, you should
> really give some thought to using xul widgets as enabling them by
> default on the laptop allows people with web backgrounds to build
> compelling UIs.. This doesn't break sugar's "1 toolkit" rule as you
> can build xulrunner to use gtk/cairo:
> http://developer.mozilla.org/en/docs/Configuring_Build_Options#Graphics_Toolkit

xulrunner doesn't use gtk widgets (except for the toplevel window) even
if you build it with gtk support, it just try to emulate the theme.

It's hard to explain to someone which is not familiar with the Sugar UI
design but we will need a bunch of custom widgets to implement it. And
xulrunner does not provide those. Sure you could reimplement the
controls we need in xulrunner, and write xulrunner components to talk
with sugar presence service and...

The Sugar platform is pretty well defined at this point and we made the
conscious decision to *not* use xulrunner to build it a while ago.
Evolving two different platforms, one based on GNOME and one on
xulrunner would be a non sense.

Convergence between the GNOME platform and the mozilla.org one has been
discussed multiple times in the past. It would be awesome in principle
but it won't happen any time soon. The only practical approach is to use
embedding to bridge the two worlds.

Marco