Hello,
I am interested to port the wine interface to the xulrunner back to mswindows to access the xulrunner via a IE compatible interface. So it would be easy to replace an embedded IE with the gecko-engine. After some code browsing I thing it will be some of the "DLLs", especially mshtml and shdocvw. I just wanted to hear from you an opinion about that project. What will be the main changes to the wine code - besides renaming of the dlls? Where do you see problems? Did somebody else worked on that or implemented it already?
Thanks
Thomas Kaltenbrunner
Hi Thomas,
On Mon, Jul 19, 2010 at 9:29 AM, Thomas Kaltenbrunner <tkaltenbrunner@opc.de
wrote:
Hello,
I am interested to port the wine interface to the xulrunner back to mswindows to access the xulrunner via a IE compatible interface. So it would be easy to replace an embedded IE with the gecko-engine. After some code browsing I thing it will be some of the "DLLs", especially mshtml and shdocvw. I just wanted to hear from you an opinion about that project. What will be the main changes to the wine code - besides renaming of the dlls? Where do you see problems? Did somebody else worked on that or implemented it already?
Jacek or one of the Wine IE maintainers will have to help answer this but it seems like if the dlls can currently be built with a Mingw build then it should 'just work' assuming you use something like a side by side assembly with the Wine dlls and a bundled Gecko as opposed to the Windows dlls.
Thanks
Hi Thomas,
On 7/19/10 3:29 PM, Thomas Kaltenbrunner wrote:
Hello,
I am interested to port the wine interface to the xulrunner back to mswindows to access the xulrunner via a IE compatible interface. So it would be easy to replace an embedded IE with the gecko-engine. After some code browsing I thing it will be some of the "DLLs", especially mshtml and shdocvw. I just wanted to hear from you an opinion about that project. What will be the main changes to the wine code - besides renaming of the dlls? Where do you see problems? Did somebody else worked on that or implemented it already?
The main problem is that what we need (and we need it because apps need it) doesn't belong to XULRunner. Wine's IE libs implementation needs an architecture compatible with MS implementation. We do ugly things with Gecko to make it work. For example we don't use necko for loading documents. We use urlmon.dll instead. An app may register its own protocol handlers, overwrite an existing handler or simply depend on us using wininet for http. We also allow using our jscript instead of Gecko JS. This is needed to allow scripts written for IE work as well as interaction between script and app. There are more smaller things we have to do because applications need them. I think none of them makes sense to be in XULRunner itself.
There was a project (no longer maintained AFAIK) in Mozilla called Mozilla ActiveX control. It was kind of a replacement for WebBrowser control - a high level part of IE embedding API. It can work for some simple applications, esp if they are prepared to use it. I think it's a good compromise between having anything like that in XULRunner and not having things that don't belong there.
In my opinion, if your goal is to make embedding Gecko easier, it would be better to work on Gecko embedding API itself. Currently, although it's easy to do simple HTML embedding, if you want to do anything more complicated, you have to go through semi-internal, not backward compatible interfaces. Some things like interacting with scripts from the pages are not possible at all (although recently introduced ctypes might have changed it). It's far from being nice for developers IMO. Mozilla is getting rid of backward compatibility for mozilla2 (Firefox 4). It will surely hurt apps using XULRunner for embedding, but it may be also good time to rethink the API to be more friendly.
Jacek
Hello Jacek,
first of all, thank you for this detailed explanation.
Am 19.07.2010 17:11, schrieb Jacek Caban:
Hi Thomas,
On 7/19/10 3:29 PM, Thomas Kaltenbrunner wrote:
Hello,
I am interested to port the wine interface to the xulrunner back to mswindows to access the xulrunner via a IE compatible interface. So it would be easy to replace an embedded IE with the gecko-engine. After some code browsing I thing it will be some of the "DLLs", especially mshtml and shdocvw. I just wanted to hear from you an opinion about that project. What will be the main changes to the wine code - besides renaming of the dlls? Where do you see problems? Did somebody else worked on that or implemented it already?
The main problem is that what we need (and we need it because apps need it) doesn't belong to XULRunner. Wine's IE libs implementation needs an architecture compatible with MS implementation. We do ugly things with Gecko to make it work. For example we don't use necko for loading documents. We use urlmon.dll instead. An app may register its own protocol handlers, overwrite an existing handler or simply depend on us using wininet for http. We also allow using our jscript instead of Gecko JS. This is needed to allow scripts written for IE work as well as interaction between script and app. There are more smaller things we have to do because applications need them. I think none of them makes sense to be in XULRunner itself.
There was a project (no longer maintained AFAIK) in Mozilla called Mozilla ActiveX control. It was kind of a replacement for WebBrowser control - a high level part of IE embedding API. It can work for some simple applications, esp if they are prepared to use it. I think it's a good compromise between having anything like that in XULRunner and not having things that don't belong there.
Yes. I tried it, but it did not work correctly - even with a more or less simple application. So am looking for a better implementation. I think wine must have a very good implementation.
In my opinion, if your goal is to make embedding Gecko easier, it would be better to work on Gecko embedding API itself. Currently, although it's easy to do simple HTML embedding, if you want to do anything more complicated, you have to go through semi-internal, not backward compatible interfaces. Some things like interacting with scripts from the pages are not possible at all (although recently introduced ctypes might have changed it). It's far from being nice for developers IMO. Mozilla is getting rid of backward compatibility for mozilla2 (Firefox 4). It will surely hurt apps using XULRunner for embedding, but it may be also good time to rethink the API to be more friendly.
I had already a look at the XULRunner api - but I did not find an easy starting point.
Thomas Kaltenbrunner
-
Jacek Caban -
Steven Edwards -
Thomas Kaltenbrunner