Hello.
As Dimi suggested, I'm writing here a summary of my SoC project. I was working on MSHTML implementation. More about what is MSHTML is on the wiki: http://wiki.winehq.org/MozillaIntegration so I won't rewrite it here.
MSHTML generally works as HTML is displayed, but there is still a bit to do. The thing that blocks correct implementation is loading pages from stream. It prevents correct implementation of functions like stop or refresh. What I mean here is that the function Load gets IMoniker interface that should be used to load the page, but the current implementation just gets URL by GetDisplayName and lets Gecko load the page. Not only it is a hack, it limits the functionality so that only protocols supported by Gecko may be used - which definitely is not what we want. Among others HTML Help, because of this, can't work with current implementation, as it uses mk protocol. There is some code that allowed us to implement it correctly, but presently it's disabled. I gave more info about this in comment to the patch: http://www.winehq.org/pipermail/wine-patches/2005-August/020059.html Before I'll enable it again in CVS, I'd like to have a better URLMoniker implementation (most apps use it to pass IMoniker to the Load function but the current Load implementation hides bugs in it). First thing that needs to be done with URLMoniker is to switch it to use the pluggable protocol. That means rewriting most of URLMoniker, but, first of all, these protocols have to be correctly implemented. I have almost finished http implementation, so there remain https and ftp. That's what I'm going to work on in the nearest future, however now it can't go to the CVS before 0.9 release (correct me if I'm wrong). Other things that have to be done are:
- More functionality of MSHTML: there are leaks in its functionality. Although I don't think edit mode is something we should really care, there are things like refresh or stop.
- WebBrowser control implementation - when we have its true implementation, MSHTML will become truly useful and in most apps HTML pages should work out of box.
Thanks, Jacek
On Sun, 2005-10-02 at 15:25 +0200, Jacek Caban wrote:
As Dimi suggested, I'm writing here a summary of my SoC project.
Thanks for taking the time to do so -- it has been most informative.
- More functionality of MSHTML: there are leaks in its
functionality. Although I don't think edit mode is something we should really care, there are things like refresh or stop.
A detailed and explicit TODO listing all the known missing bits on the Wiki page would be golden.
- WebBrowser control implementation - when we have
its true implementation, MSHTML will become truly useful and in most apps HTML pages should work out of box.
Ditto for this one, with maybe a plan of attack (if you have one) and some effort estimate (if you know).
This is really cool stuff, keep up the good work!
Hello.
A detailed and explicit TODO listing all the known missing bits on the Wiki page would be golden.
Done, except for shdocvs as I don't have clean todo list for this one.
Ditto for this one, with maybe a plan of attack (if you have one) and some effort estimate (if you know).
I have been looking at it while writing MSHTML. I'd like to have shdocvw working with builtin urlmon and mshtml so we can get many important information from logs. Then we can just just run an application, see what it needs, write a test case and finally implement the function. I think this way is best for such cases.
Jacek
On Wed, 2005-10-05 at 22:38 +0200, Jacek Caban wrote:
Done, except for shdocvs as I don't have clean todo list for this one.
Great! This has been very helpful (at least for me) in understanding better where we are.
I have been looking at it while writing MSHTML. I'd like to have shdocvw working with builtin urlmon and mshtml so we can get many important information from logs.
What do we need to do to get there? What is shdocvw using now?
Dimi Paun wrote:
What do we need to do to get there? What is shdocvw using now?
Builtin MSHTML works fine with shdocvw. urlmon is a bit worse. It currently fails after BindToStorage call. I didn't try to get it working with current implementation as it's really just a hack and my tests show that it's very buggy. Switching to use pluggable protocol means rewriting it and I hope to get it working then.
shdocvw currently uses the Mozilla ActiveX control implementation of WebBrowser control. Some apps work fine with it, so we need to have them working with our own implementation before we can get rid of Mozilla ActiveX in shdocvw (and have only Gecko depended MSHTML). Meantime we can develop the WebBrowser version that is used when Mozilla ActiveX control is not available (it's just a stub now) to use MSHTML.
Jacek
-
Dimi Paun -
Jacek Caban