Hi,
Yesterday, Apple released their web browser - Safari. The license is LGPL and the code is based on KDE's KHTML rendering engine.
Whats the difference? now you don't need QT, so license wise - it's kosher ;)
Thanks, Hetz
On January 8, 2003 02:11 pm, Hetz Ben Hamo wrote:
Whats the difference? now you don't need QT, so license wise - it's kosher ;)
But I guess it's still C++, no? I'm not sure if Alexandre will accept C++ dlls...
On Wednesday 08 January 2003 22:27, Dimitrie O. Paun wrote:
On January 8, 2003 02:11 pm, Hetz Ben Hamo wrote:
Whats the difference? now you don't need QT, so license wise - it's kosher ;)
But I guess it's still C++, no? I'm not sure if Alexandre will accept C++ dlls...
Well, last time the talking here was that due to QT license, KHTML couldn't be used, and now with the Safari you don't need any QT (you can use other GUI kits around)...
As for C++ - well, anyone is welcome to look at mozilla code - I'm affraid that it looks like a big spaghetti, compared to (pretty neat) KHTML code ;)
Thanks, Hetz
On January 9, 2003 10:44 am, Hetz Ben Hamo wrote:
As for C++ - well, anyone is welcome to look at mozilla code - I'm affraid that it looks like a big spaghetti, compared to (pretty neat) KHTML code ;)
I'm not saying it's an unreasonable request. All I'm saying is that it would be a change in policy to accept C++ code in Wine. So you need to take it up with Alexandre :)
"Dimitrie O. Paun" dpaun@rogers.com writes:
I'm not saying it's an unreasonable request. All I'm saying is that it would be a change in policy to accept C++ code in Wine. So you need to take it up with Alexandre :)
I'd prefer to avoid C++, but if there's no other choice then of course we'll have to do it. I'm still hoping that we can find a way to avoid duplicating all that code inside Wine, C++ or not.
On January 9, 2003 12:14 pm, Alexandre Julliard wrote:
I'd prefer to avoid C++, but if there's no other choice then of course we'll have to do it. I'm still hoping that we can find a way to avoid duplicating all that code inside Wine, C++ or not.
Well, it seems the only worthy alternatives are Mozilla and KHTML, and they are both written in C++. I am 100% with you on the non-duplicating bit: even if we get something in the tree, it's not going to be maintained, and it will bitrot to fast for words. It would be a huge addition and burden to maintain for the Wine project.
Galeon does not include Mozilla -- it uses it. There's got to be a way to use KHTML in a similar manner. Even my first hand approximation (using the Win32 build of Mozilla) seems like a better option than duplicating code. If we get that working, I'm sure we can work with the Mozilla team to find a way of embedding the Linux version. Heck, Galeon does it!
But since I'm not doing that work ...
On Thu, Jan 09, 2003 at 11:21:18AM -0500, Dimitrie O. Paun wrote:
On January 9, 2003 12:14 pm, Alexandre Julliard wrote:
I'd prefer to avoid C++, but if there's no other choice then of course we'll have to do it. I'm still hoping that we can find a way to avoid duplicating all that code inside Wine, C++ or not.
Well, it seems the only worthy alternatives are Mozilla and KHTML, and they are both written in C++. I am 100% with you on the non-duplicating bit: even if we get something in the tree, it's not going to be maintained, and it will bitrot to fast for words. It would be a huge addition and burden to maintain for the Wine project.
Galeon does not include Mozilla -- it uses it. There's got to be a way to use KHTML in a similar manner. Even my first hand approximation (using the Win32 build of Mozilla) seems like a better option than duplicating code. If we get that working, I'm sure we can work with the Mozilla team to find a way of embedding the Linux version. Heck, Galeon does it!
Actually there already was a Konqueror / WINE integration already, called reaktivate. It replaced urlmon and provided a IWebBrowser interface.
Ciao, Marcus
On January 9, 2003 01:46 pm, Marcus Meissner wrote:
Actually there already was a Konqueror / WINE integration already, called reaktivate. It replaced urlmon and provided a IWebBrowser interface.
Sweet! This is exactly what I was hoping for. [...searching for it...] Here's the original announcement:
But this seems to be going what cxplugin does. We need the complement of that, don't we?
On Thu, Jan 09, 2003 at 12:28:38PM -0500, Dimitrie O. Paun wrote:
On January 9, 2003 01:46 pm, Marcus Meissner wrote:
Actually there already was a Konqueror / WINE integration already, called reaktivate. It replaced urlmon and provided a IWebBrowser interface.
Sweet! This is exactly what I was hoping for. [...searching for it...] Here's the original announcement:
But this seems to be going what cxplugin does. We need the complement of that, don't we?
Not sure, it might just work both ways. Will have to go back and check.
Ciao, Marcus
Well, last time the talking here was that due to QT license, KHTML couldn't be used, and now with the Safari you don't need any QT (you can use other GUI kits around)...
Actually Ender was de-Qting KHTML at some point, are you still around Ender? I haven't seen the code but I expect you can forget about Safari - iirc it's been integrated with Quartz which is of course a proprietary Apple system only. Seeing as they were ranting about speed, I doubt they'll have imposed the overhead of a graphics layer abstraction system.
About duplication - I think it's probably most likely that the best course would be to copy the KHTML source into the Wine tree, because I'd expect modifications would be needed in order to support all the IEisms that will crop up in regular usage of the WebBrowser control. KHTML out of the box won't, and never will support ActiveX, IE specific markup or any of the other proprietary stuff MS threw in for fun during the browser wars. The KDE team would rightly reject such patches from being integrated into upstream.
I don't know how much progress Ender made, it might be worth emailing him to find out.
thanks -mike