Log message: Dimitrie O. Paun <dpaun@rogers.com mailto:dpaun@rogers.com?Subject=Re:%20lostwages/templates/en%20status_ui.template> * Work is ongoing on richedit * Audit of Syslink * We've done all we can on shdocvw.dll for now
...
- <td class="pct25">25%: implement shdocvw.dll</td> + <td class="pct100">100%: We forward to Mozilla, but more work is needed on Mozilla for compatibility.</td>
I completely disagree. We can do much more than there is done right now. shdocvw is more than WebBrowser control and we can inplement those areas, but WebBrowser needs a lot of work as well. Mozilla ActiveX Control seems not to be systematically developed and the compability we need is not their aim. We need an implementation of WebBrowser based on MSHTML, which will be possible when I finish my work on it. This way we'll be able to implement shdocvw correctly (eg. it'll be possible to implement Internet Explorer OLE Automation), but now it's far, far away from it and really far from 100% complete.
On Sun, 10 Apr 2005 20:43:44 +0200, Jacek Caban wrote:
We need an implementation of WebBrowser based on MSHTML, which will be possible when I finish my work on it. This way we'll be able to implement shdocvw correctly (eg. it'll be possible to implement Internet Explorer OLE Automation), but now it's far, far away from it and really far from 100% complete.
You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here.
thanks -mike
Mike Hearn wrote:
You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here.
Actually, I'd be interested to see how much of Gecko we'd need to import/port so that Wine could render HTML. It seems pretty obvious to me from my experiments with the Mozilla Active X control that nobody is using it as it is.
Mike
On Mon, 2005-04-11 at 23:33 +0900, Mike McCormack wrote:
Actually, I'd be interested to see how much of Gecko we'd need to import/port so that Wine could render HTML. It seems pretty obvious to me from my experiments with the Mozilla Active X control that nobody is using it as it is.
Yeah. We should probably just fix the mirroring stuff and get it enabled by default in WineHQ. Currently nobody is using it because it doesn't download anything, and then most apps seem to crash ...
Mike McCormack wrote:
Mike Hearn wrote:
You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here.
I don't touch engine code! I use Gecko's embeding API. The HTML rendering will never be compatibile at all, but that's not important in most cases. What we need is a compatibile API, that can be done using Gecko as HTML engine, everything else we have to implement ourself (eg. my curretnt implementation uses Gecko to download document, what also needs to be changed).
Actually, I'd be interested to see how much of Gecko we'd need to import/port so that Wine could render HTML. It seems pretty obvious to me from my experiments with the Mozilla Active X control that nobody is using it as it is.
Mike
You'll see this, I promise, but first I need to clean up code, what I do sending patches. If you mean how much of code do we need to port to Wine tree, andswer is that no code excepting creating our headers. Everything else is in shared library that can be loaded in runtime. My current implementation imports only 6 functions (and 3 of theme are to manipulate strings!). Everything else can be done using interfaces.
Jacek
Mike McCormack wrote:
Mike Hearn wrote:
You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here.
I don't touch the engine code! I use Gecko's embedding API. The HTML rendering will never be compatible at all, but that's not important in most cases. What we need is a compatible API, and that can be done using Gecko as HTML engine, everything else we have to implement ourself (eg. my current implementation uses Gecko to download document - that also needs to be changed).
Actually, I'd be interested to see how much of Gecko we'd need to import/port so that Wine could render HTML. It seems pretty obvious to me from my experiments with the Mozilla Active X control that nobody is using it as it is.
Mike
Soon you'll see - I promise:) If you mean how much of code do we need to port to Wine tree, the answer is that no code excepting creating our headers. Everything else is in a shared library that can be loaded at runtime. My current implementation imports only 6 functions (and 3 of theme are to manipulate strings!). Everything else can be done using interfaces.
Jacek
Hi Jacek,
I don't touch the engine code! I use Gecko's embedding API. The HTML rendering will never be compatible at all, but that's not important in most cases. What we need is a compatible API, and that can be done using Gecko as HTML engine, everything else we have to implement ourself (eg. my current implementation uses Gecko to download document - that also needs to be changed).
Perhaps the way forward is to get mshtml working with Gecko's embedding API, as you're doing, then switch shdocvw to use your implementation of mshtml. That will give us full control over all the relevant OLE interfaces, which are probably the things that will give us most trouble.
Soon you'll see - I promise:) If you mean how much of code do we need to port to Wine tree, the answer is that no code excepting creating our headers. Everything else is in a shared library that can be loaded at runtime. My current implementation imports only 6 functions (and 3 of theme are to manipulate strings!). Everything else can be done using interfaces.
Cool! Looking forward to that. Once you get it going, post what you have, and somebody can start working on shdocvw.
Mike
On Apr 11, 2005 3:42 PM, Mike Hearn mh@codeweavers.com wrote:
On Sun, 10 Apr 2005 20:43:44 +0200, Jacek Caban wrote:
We need an implementation of WebBrowser based on MSHTML, which will be possible when I finish my work on it. This way we'll be able to implement shdocvw correctly (eg. it'll be possible to implement Internet Explorer OLE Automation), but now it's far, far away from it and really far from 100% complete.
You're right, but I hope you are not writing a rendering engine from scratch! That would be madness. We really need to adapt Gecko to improve its MSHTML compatibility here.
I'm not entirely sure here what kind of compatibility you are talking. But for actual page rendering gecko will never be mshtml compatible. MSHTML is an incorrect implantation of the W3 standards and mozilla is not recreating it.
This is no problem as long as exact IE replication is not needed (ie. for simple display inside other applications). But for web designing where people want to see IE behaviour you will never want a different engine.
So we should always allow native shdocvw to keep IE to show the same behaviour. As implanting shdocvw ourselves is not going to work.
Paul
On Mon, 2005-04-11 at 17:37 +0200, Paul van Schayck wrote:
I'm not entirely sure here what kind of compatibility you are talking. But for actual page rendering gecko will never be mshtml compatible. MSHTML is an incorrect implantation of the W3 standards and mozilla is not recreating it.
But they already do. For instance, they implement some document.all compatibility. I suspect they'd be willing to accept build-time #ifdef TRIDENT_COMPATIBLE patches. If not, then we'd have to fork it.
This is no problem as long as exact IE replication is not needed (ie. for simple display inside other applications). But for web designing where people want to see IE behaviour you will never want a different engine.
Sure, for people doing web pages they'll always want native behaviour. The need to reimplement MSHTML (Trident) is for:
- Apps that embed it, like the HTML Help system - Web apps that need IE compatible feature sets
thanks -mike
On Sun, Apr 10, 2005 at 08:43:44PM +0200, Jacek Caban wrote:
I completely disagree. We can do much more than there is done right now. shdocvw is more than WebBrowser control and we can inplement those areas, but WebBrowser needs a lot of work as well. Mozilla ActiveX Control seems not to be systematically developed and the compability we need is not their aim. We need an implementation of WebBrowser based on MSHTML, which will be possible when I finish my work on it. This way we'll be able to implement shdocvw correctly (eg. it'll be possible to implement Internet Explorer OLE Automation), but now it's far, far away from it and really far from 100% complete.
This is a good discussion for WineConf. But sure, in the meantime feel free to submit a patch for this entry that better reflect your plans.
In any event, I think such a significant effort probably deserves a bit bigger space somewhere else, but it will have to wait a bit until we can figure out where exactly.
-
Dimitrie O. Paun -
Jacek Caban -
Mike Hearn -
Mike McCormack -
Paul van Schayck