Robert Osfield wrote:
On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis <p...@science.uva.nl> wrote:
A question: I think I saw you mention somewhere that XUL 1.9 is not
supported, that 1.8 is the version to use. Is this correct?

Our gecko plugin is based on Ubrowser + XUL 1.8.x.  I exchange a
number of emails with Callum Prentice, the author of Ubrowser,  about
porting to to XUL 1.9 and he said that their are number of changes
between the two version that include removal of functionality UBrowser
relied upon, and the mozilla developer mailing lists were very
unhelpful in helper guide others trying to use the API and the lack of
docs meant that it would have been a lot of work to guess how to
proceed with a port.

Callum is now concentrating on Qt + WebKit integration that isn't yet
released but should be some time in the spring.  I guess it might
event be a part of Qt 4.5.  Callum has now moved on from looking at
the gecko side as it was just too hard to get working well.

I went for the gecko route purely because all the other solutions out
there required modifying webkit sources and compiling it's oneself.
There are at least  xulrunner 1.8 still available on some platforms
off the shelf.  This won't be a long term thing though... 1.9 is
replacing it...
Hmm, I haven't looked at webkit in detail but heard mostly good things about it, too bad it's not usable at this point yet.
I'm having some trouble getting 2.8 to compile on an FC10 system (after
having to hack the CMake XUL module, as it uses different pkg-config names
for the XUL packages). Specifically,
src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h,
which on the FC10 system, is located in a subdirectory widget/ of the XUL
include directory and therefore can't be found using the current include
directories set from the CMake module.

The gecko/CMakeLists.txt does have an entry for the widget subdirectory:

    ${XUL_INCLUDE_DIR}/widget
pkg-config libxul --cflags on this FC10 system reports:
-fshort-wchar -I/usr/include/xulrunner-sdk-1.9/stable -I/usr/include/nspr4

and so XUL_INCLUDE_DIR gets set to /usr/include/xulrunner-sdk-1.9/stable by CMake. However, the directories widget/ and such are not subdirecories of the stable/ dir but are siblings!

It seems that the files in stable/ are some sort of backwards-compatible 1.8 API, that are not present in the official 1.9 SDK.
Looking further into this it seems that that header (nsIBaseWindow.h) is
nowhere to be found in any of the 1.8 official distributions from Mozilla!
(e.g.
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/)

Forgot to mention that the header IS included in 1.9, but you probably guessed
Argggg.... building on shifting sand....
We perhaps should check wether there have been any successful builds of the gecko plugin against xulrunner 1.8.
I have a hunch everybody is using 1.9 these days :)
So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9?

We could try to port to 1.9, but... it could well take a while.
I think that we already use 1.9 everywhere, simply because the plugin shouldn't compile against 1.8 without errors. On an old FC4 system I *do* see the nsIBaseWindow.h header, but there it is part of mozilla-1.7.13. So it's quite a big jungle where those headers the gecko plugin uses comes from :-/
Did you not say that you got things working yesterday?  What haw
changed since then?
That I'm now compiling on a different system (FC10 instead of Gentoo).

I'm not very motivated to keep track and handle all different XUL installations out there. I guess on the long run porting to 1.9 (or taking another look at webkit) might be the best way forward.

Paul

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to