Hi !
I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great.
Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ).
Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation?
http://winehq.org/news/?view=147#IWebBrowser%20Status
Some of the discussion is summed up there.
Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms.
Alexandre, what's the reasoning behind the no C++ rule?
On Fri, 2003-01-10 at 10:26, Juan Rey Saura wrote:
Hi !
I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great.
Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ).
Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation?
Thank you ! And excuse me! I was looking for some information about that in the mailing list archive and in the WineWeekly News but probably I did not pay enough attention.
Mike Hearn wrote:
http://winehq.org/news/?view=147#IWebBrowser%20Status
Some of the discussion is summed up there.
Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms.
Alexandre, what's the reasoning behind the no C++ rule?
On Fri, 2003-01-10 at 10:26, Juan Rey Saura wrote:
Hi !
I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great.
Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ).
Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation?
Mike asked me to e-mail a status report on my KHTML work, so here it is :)
I've been too busy lately (job hunting mostly, although I've also been sick and bedridden lately) to do any more work on it, and I was really waiting for Alexandre to comment on my question about C++ before going any further... I havn't seen a reply yet tho.
The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it.
It is currently quite MS html compatible, and my CHM viewer seems to have few problems rendering HtmlHelp pages using the KHTML/KJS functionality. Unlike Gecko, which is too 'standards compliant'... eg, it deliberatly doesn't implement any of the IE specific functionality.
The other issue I need to look into is where each part of IE functionality need to go. Implementing IWebBrowser is easy enough from my current work, however that is only the very top of the iceburg. The more important issue is to get all the various parts in the right dlls (shdocvw, shdoclc, jscript, ecetra). Many programs that embed IE use and/or subclass a large number of functions - mostly undocumented - from these dlls, as opposed to using IWebBrowser itself. There is also the problem of res:// inclusion of HTML templates embedded in shdocvw, ecetra.
This is, btw, another reason that gecko isn't very well suited. It would require a lot more work to butcher gecko (simply because of it's size and complexity) into these stub dlls, than it would to do so to KHTML/KJS. Either way, it's a lot of work that unfortunatly I don't have all that much time to do at the moment.
Hopefully my job hunting will calm down soon, and I will have time to clean up the code to a state where I can at least post it for other people to work on... then again, if it calms down it means I've FOUND a job... so it could work both ways :)
- Ender
On 10 Jan 2003, Mike Hearn wrote:
Date: 10 Jan 2003 10:39:01 +0000 From: Mike Hearn m.hearn@signal.qinetiq.com To: Juan Rey Saura juanrey@inicia.es Cc: Wine development mailing list wine-devel@winehq.com Subject: Re: Wine, Mozilla & IE ?
http://winehq.org/news/?view=147#IWebBrowser%20Status
Some of the discussion is summed up there.
Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms.
Alexandre, what's the reasoning behind the no C++ rule?
On Fri, 2003-01-10 at 10:26, Juan Rey Saura wrote:
Hi !
I've read in the list there is a project about compiling Mozilla under Wine, I think it would be great.
Several parts of wine need an IWebBrowser implemtation; CHM support, some applications... One implementation based on the khtml is in the works, but Mozilla does implement it yet ( see http://www.iol.ie/~locka/mozilla/mozilla.htm ).
Could Mozilla, under Wine or maybe native version, be used as a replacement for the IE IWebBrowser implementation?
-- Mike Hearn m.hearn@signal.qinetiq.com QinetiQ - Malvern Technology Center
On January 10, 2003 06:45 am, Ender wrote:
The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it.
Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff?
If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree.
There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).
Why don't look at the stuff Apple made for their khtml wrapper? They made two components to interact with khtml. One javascript wrapper (JavascriptCore) and another component containing some sort of QT wrapper called WebCore. The license of WebCore looks LGPL compatible (not 100% sure), so perhaps it is possible to reuse the stuff they made.
When khtml gets an update they can plug it in this framework and it should work. (theoraticly)
On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote:
On January 10, 2003 06:45 am, Ender wrote:
The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it.
Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff?
If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree.
There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).
Forgot to include an url to the safari developer page containing the usefull source code. I rechecked the license of the qt wrapper (kwq) and it looks a lot like a BSD license. It also seems possible to easily compile the wrapper to work on for example Linux. (only new makefiles are needed)
I hope this helps,
Roderick Colenbrander
On Friday 10 January 2003 21:57, Roderick Colenbrander wrote:
Why don't look at the stuff Apple made for their khtml wrapper? They made two components to interact with khtml. One javascript wrapper (JavascriptCore) and another component containing some sort of QT wrapper called WebCore. The license of WebCore looks LGPL compatible (not 100% sure), so perhaps it is possible to reuse the stuff they made.
When khtml gets an update they can plug it in this framework and it should work. (theoraticly)
On Friday 10 January 2003 20:03, Dimitrie O. Paun wrote:
On January 10, 2003 06:45 am, Ender wrote:
The current state of my local tree, besides being a mess, is that it has most QT dependencies removed. Currently it uses a lot of QT stub's around WinAPI functions that I wish to remove before doing much more work with it.
Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff?
If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree.
There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)).
On January 10, 2003 05:15 pm, Roderick Colenbrander wrote:
Forgot to include an url to the safari developer page containing the usefull source code.
Funny thing is, you forgot the second time as well... :)
Why do I allways forget attachments or urls? :( Here it is: http://developer.apple.com/darwin/projects/webcore/
(Not sure if it is still relevant for the rest of the thread.)
On Friday 10 January 2003 21:58, Dimitrie O. Paun wrote:
On January 10, 2003 05:15 pm, Roderick Colenbrander wrote:
Forgot to include an url to the safari developer page containing the usefull source code.
Funny thing is, you forgot the second time as well... :)
Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!?
I brought up this very same argument when I first took on the task of porting it over.. however I as basically outvoted with doing the implementation as more of a wrapper than a true port :P
off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset:
As it seem there is some effort going on to create a native Win32 KHTML port using Apple's WebCore wrapper system I think I will take a break on my current code and play with that a little. Personally I didn't want to have to take on the chore myself, but this whole Safari thing IS creating more intrest in non-X11/QT platforms... it definatly changes the playing field, and with the large speed and compatability merges from Safari lately my current tree is hopelessly out of date anyway :)
So I think I will play with that and work on the DLL layout and COM interfaces until something eventuates... I've decided it's worth waiting to see what direction KHTML takes (portability wise) now that it is being use in a 'real' non-KDE application. There's no point rushing into a WINE-specific implementation if something more closely tied to the upstream code is released meer weeks later.
Of course there still a small problem of having to seperate the code into MS compatible COM objects and DLLs... I will have to benchmark the speed impact of stubbing the MS dll's into khtml.dll/kjs.dll ecetra, instead of replicating the exports more natively.
Cheers, Ender
Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it?
Would we need to track it significantly? Most uses of the IE web control seem to be fairly predictable and not all that advanced. Most of the work going into KHTML is to allow it to act as a good general purpose web renderer, which isn't really relevant to wine.
Of course the odd bugfix and security issues might need to be backported, but as it's a fairly specific purpose fork that might not be as bad as it sounds.
KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!?
Hey, I don't suppose KHTML could form the basis of a rich edit control could it? I don't know if it supports editing at all. GTKHtml definately does, but obviously it uses gdk rather than the gdi (although gdk can use the gdi, which might come in useful for future theming work anyway).
-- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features
I dunno how hard it'd be to implement but it uses the Qt object model quite extensively which is a) complex and b) requires a preprocessor. Nothing impossible, but a lot of work.
That's another possibility of course, that you might wish to look into Ender. GTK-HTML doesn't get the same amount of press that KHTML does, but it's written in C and is actually a fairly capable embedded html renderer. It relies upon GTK/GDK which already has a port to Windows, the GNOME help system uses it for rendering afaik so it should be easier to integrate with Wine. Finally it supports editing, which might come in useful in future.
On January 13, 2003 05:47 am, Mike Hearn wrote:
Would we need to track it significantly?
Famous last words.
I think it would be a mistake to assume that we don't need to.
That's another possibility of course, that you might wish to look into Ender. GTK-HTML doesn't get the same amount of press that KHTML does, but it's written in C and is actually a fairly capable embedded html renderer. It relies upon GTK/GDK which already has a port to Windows, the GNOME help system uses it for rendering afaik so it should be easier to integrate with Wine. Finally it supports editing, which might come in useful in future.
There is actually two different HTML renderers that's used in GNOME gtkhtml and gtkhtml2
GtkHTML was originally a port of a very old version of KHTML to Gtk+. gtkhtml2 was written from scratch.
GtkHTML is used by evolution for both showing html (in html messages) and for editing, in the composer. I think there exist a browser somewhere which use this widget. But as far as i can say i don't think it renders web pages very good.
gtkhtml2 on the other hand is the library used by yelp, the GNOME 2 Help system which support css quite well. But no editing and is more or less unmaintained. At one point in the future it will be abandoned and GNOME will use GtkHTML in the help browser instead.
That's another possibility of course, that you might wish to look into Ender. GTK-HTML doesn't get the same amount of press that KHTML does, but it's written in C and is actually a fairly capable embedded html renderer. It relies upon GTK/GDK which already has a port to Windows, the GNOME help system uses it for rendering afaik so it should be easier to integrate with Wine. Finally it supports editing, which might come in useful in future.
GTK-HTML is far too basic for our needs. We need at least DHTML and JS support for any IWebBrowser/IE replacement to be useful.
- Ender
Basically Gecko is huge, roughly as big if not bigger than Wine itself. KHTML is understandable by one person. It's also more easily adapted to IEisms.
Alexandre, what's the reasoning behind the no C++ rule?
BTW: if someone follows the kfm-devel (Konqueror's) lists, then you can see that people are trying to compile it under windows...
http://lists.kde.org/?l=kfm-devel&r=1&w=2
Thanks, Hetz
Mike Hearn m.hearn@signal.qinetiq.com writes:
Alexandre, what's the reasoning behind the no C++ rule?
Some of the reasons are related to C++ itself: lack of standard ABI, large differences between compilers making it harder to write portable code. Other reasons would apply to any language: more complex build process, more external tool dependencies, harder to debug, developers need to be familiar with both languages, harder to copy code around, etc.
None of these are showstoppers, but it needs a *really* good reason to overcome all of them. So far I haven't heard anything convincing enough.
Alexandre Julliard wrote:
None of these are showstoppers, but it needs a *really* good reason to overcome all of them. So far I haven't heard anything convincing enough.
THE thing that makes me miss C++ the most is exception handling. C offers you, basically, three options:
1. Having to perform an "if" every other line and perform a *shudder* goto in case of error. 2. Have nested "if"s seven levels deep. 3. return from the middle of the function. 4. Worst yet, write insecure code.
1. produces the longest code. It is also the ugliest one, structured programming wise. 2. has solved the ugliness, at the expense of code readability. For performance reasons you have to place the branch most likely to happen as the "then" part of the if, leaving the error handling to the "else" part. This means that you have an operation, long long list of what to do in case it succeeds (this list includes nested "if"s, mind you), and then an "else" and a sigle line of error handling. These last lines are all bunched together for each nesting level, and by the time you read them you no longer have the opening condition on screen. 3. This one produces a very neat solution, except that it requires performing the shutdown procedure over and over again. With multiple resources allocated, the shutdown also gets progressively longer. 4. This is the simplest one, and very easy to understand. It is also very common. In a nutshell - this means that you don't check the results of the operations you perform, and therefor you don't clutter your code with error handling. I think I don't have to elaborate why this is bad.
Exceptions, on the other hand, give a clean solution to the entire problem. The source code looks almost like option 4 - on error checks are performed. The resulting machine language, however, looks almost like 1 - all resource cleanups in one place, and you jump there if necessary.
If the discussion goes forward, I can give an example of rewriting my latest patch to wineboot (currently using approach 1) with the other four approaches (2, 3, 4 and exceptions).
Shachar
Shachar Shemesh wrote:
THE thing that makes me miss C++ the most is exception handling. C offers you, basically, three options:
Having to perform an "if" every other line and perform a *shudder* goto in case of error.
Have nested "if"s seven levels deep.
return from the middle of the function.
Worst yet, write insecure code.
produces the longest code. It is also the ugliest one, structured
programming wise.
Actually, the Linux kernel uses this technique, and it doesn't always lead to longer code than, say, nested if's. It can actually be quite clean, and given that the use of 'goto' is restricted to a very narrow idiom, it's not all that hard to read.
Exceptions, on the other hand, give a clean solution to the entire problem. ...
Or at least seems to. It's *very* difficult to write C++ code that is threadsafe and exception safe at the same time.
If the discussion goes forward, I can give an example of rewriting my latest patch to wineboot (currently using approach 1) with the other four approaches (2, 3, 4 and exceptions).
I've enjoyed the bit of Wine work I've done, but I'm not sure I'd continue enjoying it if C++ began to be used inside the core of Wine. C++ is for applications, not operating systems. - Dan
Dan Kegel wrote:
Actually, the Linux kernel uses this technique, and it doesn't always lead to longer code than, say, nested if's. It can actually be quite clean, and given that the use of 'goto' is restricted to a very narrow idiom, it's not all that hard to read.
I use that for kernel programming too, sometimes.
Exceptions, on the other hand, give a clean solution to the entire problem. ...
Or at least seems to. It's *very* difficult to write C++ code that is threadsafe and exception safe at the same time.
I'll have to think about that one.
If the discussion goes forward, I can give an example of rewriting my latest patch to wineboot (currently using approach 1) with the other four approaches (2, 3, 4 and exceptions).
I've enjoyed the bit of Wine work I've done, but I'm not sure I'd continue enjoying it if C++ began to be used inside the core of Wine. C++ is for applications, not operating systems.
I don't think that inside the core is a good idea either (except in places where the "core" is a huge application, such as may happen if we integrate a web browser in). I was thinking about the peripherial apps, though.
- Dan
Shachar
-
Alexandre Julliard -
Dan Kegel -
Dimitrie O. Paun -
Ender -
Hetz Ben Hamo -
Johan Dahlin -
Juan Rey Saura -
Mike Hearn -
Roderick Colenbrander -
Shachar Shemesh