This went off the pyxpcom list but I'm reposting here for the benefit
of anyone following or coming to this thread later:

>  On 5/10/07, Marco Pesenti Gritti <mpg@[...].com> wrote:
>  > Hello,
>  >
>  > so, Mark Hammond answer to the thread on the pyxpcom mailing list is
>  > *very* encouraging.
>  >
>  > http://aspn.activestate.com/ASPN/Mail/Message/pyxpcom/3474458
>  >
>  > I think we should really try it. The potential is big (being able to
>  > access the whole mozilla API directly from python open a tons of
>  > possibilities).
>  >
>  > Without having played with it a lot, my feeling is that the technology
>  > is mostly there. It just needs to be used and documented to get more
>  > mature and accessible.
>  >
>  > The first step is to get it building on the trunk. Bridging it to
>  > gtkmozembed looks trivial then.
>  >
>  > Anyone feels like giving this a try? I don't have a lot of time these
>  > days but I'd be glad to give some guidance. Getting this to work might
>  > provide an awesome piece of infrastructure to the project, without a lot
>  > effort!
>  >
>  > Marco
>  >
>  >
> 

On 5/10/07, edward baafi <edwardbaafi@[...].com>  wrote:
>  I'm giving it a try right now..
> 
>  If my builds fail, I probably won't get a chance to delve into the
>  patches until early next week..
> 
>  -Ed
> 
---------- Forwarded message ----------
From: edward baafi <edwardbaafi@[...].com> 
Date: May 11, 2007 12:41 AM
Subject: Re: Pyxpcom
To: Marco Pesenti Gritti <mpg@[...].com> 
Cc: sugar@[...].org, Ian Bicking <ianb@[...].com> 


Marco,

My first build attempt failed with "libpyxpcom.a: No such file or
directory" (I assume this is what stopped you also)

I fixed this by forcing linking with libpyxpcom.so by changing
"$(DIST)/lib/$(LIB_PREFIX)pyxpcom.$(LIB_SUFFIX) \" to
"$(DIST)/lib/libpyxpcom.so \" in
mozilla/extensions/python/dom/src/Makefile.in

Then it builds just fine!

I later found that the bug and patch you tried was for OSX:
https://bugzilla.mozilla.org/show_bug.cgi?id=375318

But the OSX bug links to the linux bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=355608

and there is a one line patch
(https://bugzilla.mozilla.org/attachment.cgi?id=253079) which should
accomplish the same thing I hardcoded above..

For consistency, my .mozconfig was:

mk_add_options MOZ_CO_PROJECT=xulrunner
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj-xulrunner-debug
ac_add_options --enable-application=xulrunner
ac_add_options --enable-extensions=python,default
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-xft
ac_add_options --disable-javaxpcom
ac_add_options --disable-tests
ac_add_options --disable-optimize
ac_add_options --enable-debug


Try that and you should build just fine..  I'm happy that you've
decided to do the right thing..  Remember that we can't judge Mark's
extensions based on the platform that he develops on top of..  I may
not like Windows but all of Mark and Thomas Heller's extensions make
it a breeze to work there (I'm just glad I don't have to build Vista)

Anyway, now that we've gotten building the trunk out of the way, can
you describe what you're trying to do with gtkmozembed?  There are a
lot of players involved (sugar services, xpcom, pyxpcom, gecko, gtk,
gtkmozembed, pygtk, the python gtkmozembed wrappers, nsiWebBrowser,
etc) and I don't have a clear picture of what you're trying to do

-Ed
_______________________________________________
pyxpcom mailing list
pyxpcom@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs