Hi all, I'm just posting a quick update on my various WINE work for those intrested.
I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet).
Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :)
That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy.
Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes.
I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider:
- It is C++. So far, all of WINEs dlls are plain C. Is this really a rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's.
- It is somewhat big, several megabytes of new code. Hopefully I can chop it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out.
Cheers, Ender
On December 3, 2002 05:46 am, Ender wrote:
Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :)
I think you should submit it like this. IWebBrowser is a standard Win interface that we are going to support, so there's no reason for winhelp to make use of it. The fact that we don't have our own _implementation_ doesn't change a thing. They are perfectly separate issues.
And in any event, if HTML Help works with IE, it's better than nothing, as it gives people a chance of working with it, test it out, even submit patches against it. :)))
On Tue, Dec 03, 2002 at 04:46:00AM -0600, Ender wrote:
That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy.
Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes.
I just told Dirk (one of the people putting quite a lot of time into kde) about your work and he told be the following (translated from German):
lustiges Projekt: "de-QT'ing KHTML"...
erzähl ihm mal von kdenox - im prinzip kdelibs dropins mit limitierter funktionalität für khtml only.
[Tell him about kdenox - which is basically a kdelibs replacement with limited functionality for khtml only]
Ausserdem gibt es then Atheos port, der einfach die (wenigen) verwendeten Qt Klassen durch eigene Implementierung ersetzt und somit einen fast unmodifizierten khtml tree übernehmen kann.
[Then there is the Atheos port, which simply replaces the (few) used Qt classes by its own implemetation and is thus able to use an almost unmodified khtml tree]
Ciao Jörg -- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Hi,
Why not use Mozilla instead of KHTML? There exists an opensource activex control based on mozilla which is fully compatible with IWebBrowser. The only difference is that the name is MozillaBrowser. There's even a little tool that can convert a IWebBrowser app to a MozillaBrowser app by changing the CLSID. Likely this control can be somehow recompiled using winelib and native mozilla.
Check this page: http://www.iol.ie/~locka/mozilla/mozilla.htm
Roderick Colenbrander
On Tuesday 03 December 2002 11:46, Ender wrote:
Hi all, I'm just posting a quick update on my various WINE work for those intrested.
I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet).
Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :)
That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy.
Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes.
I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider:
- It is C++. So far, all of WINEs dlls are plain C. Is this really a
rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's.
- It is somewhat big, several megabytes of new code. Hopefully I can chop
it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out.
Cheers, Ender
Hi Roderick,
This was discussed about a month ago, so see the archives for more info. Basically there was a Gecko vs KHTML debate, with Ender (who is writing the code) eventually settling on KHTML for the following reasons:
- Simple - No XPCOM dependancies - Could be more easily hacked to add IE compatability (and was more IE compatible to start with) - Small, good for embedding, relatively fast (gecko embedding is huge) - Would be possible to include in the Wine CVS tree as opposed to Gecko which is probably almost as big as Wine itself.
There are obviously some pros for Mozilla as well, but the things that make Moz a good choice for a web browser don't apply so much to a good replacement for the WebBrowser control.
thanks -mike
On Wed, 2002-12-04 at 12:50, Roderick Colenbrander wrote:
Hi,
Why not use Mozilla instead of KHTML? There exists an opensource activex control based on mozilla which is fully compatible with IWebBrowser. The only difference is that the name is MozillaBrowser. There's even a little tool that can convert a IWebBrowser app to a MozillaBrowser app by changing the CLSID. Likely this control can be somehow recompiled using winelib and native mozilla.
Check this page: http://www.iol.ie/~locka/mozilla/mozilla.htm
Roderick Colenbrander
On Tuesday 03 December 2002 11:46, Ender wrote:
Hi all, I'm just posting a quick update on my various WINE work for those intrested.
I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet).
Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :)
That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy.
Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes.
I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider:
- It is C++. So far, all of WINEs dlls are plain C. Is this really a
rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's.
- It is somewhat big, several megabytes of new code. Hopefully I can chop
it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out.
Cheers, Ender
On Tuesday 03 December 2002 06:59 am, Mike Hearn wrote:
Hi Roderick,
This was discussed about a month ago, so see the archives for more info. Basically there was a Gecko vs KHTML debate, with Ender (who is writing the code) eventually settling on KHTML for the following reasons:
This is true, but I think that does not mean that the KHTML IWebBrowser implementors wouldn't welcome some competition....? As long as we're planning ahead, I for one, wouldn't mind both capabilities ;)
-
Dimitrie O. Paun -
Ender -
Greg Turner -
Joerg Mayer -
Mike Hearn -
Roderick Colenbrander