YellowTAB is a German-based company developing an operating system called "Zeta". Based on the BeOS source code, for which they have obtained legal rights to use, it is meant to be the next-generation version of the now 3 years old BeOS r5. On their website they have just announced two new technologies for their OS, based on KHTML: "JavaScriptCore and WebCore are two technologies, ported from Apple's work on KHTML (the engine from Konqueror, a "modern Net+" for Linux's KDE), by YellowTab. These components will allow both developers and users to take advantage of the latest technology available, in their everyday Zeta usage."
Dot Categories:
Comments
When will the state of Safari 1.0 be merged into CVS HEAD? The last merge already seems so far away.
A lot of it already has been merged into HEAD. More by the time 3.2 comes around. To be frank, though, there seems to be an impression (mostly from Mac users) that Apple have done tonnes of work and the KHTML team have been sitting around on their rears. They've been doing a lot, and while Safari have a few speed-ups still left and a few CSS fixes, there are many feature improvements, bugfixes, CSS fixes and other changes in CVS which Apple haven't merged yet; probably far more than go the other way.
But it is a continuing process.
> there seems to be an impression (mostly from Mac users) that Apple have done tonnes of work and the KHTML team have been sitting around on their rears.
Is that a wonder when Apple has several developers working full-time on it while khtml was developed by less people and in their spare time? And I can't see nothing wrong when the original khtml authors (I don't think any of them did only khtml before) now work more on other parts of KDE as before and enjoy the features/fixes of Apple.
Remember that on the KDE side there is not a dozen of full time employees to improve khtml.. Actually this is what makes khtml so amazing...
It may be worth mentioning that what most Kde users are seeing is khtml before any Apple/Safari input. All safari stuff has been merged post 3.1.
I must say that 3.2 from cvs rocks. Fast, stable, rarely any site it has trouble with, banking works. The only thing I need yet is a way to listen to the hockey games.
http://nhl.com/intheslot/listen/radio/index.html
Derek
Won't mplayer (or kmplayer) work with that?
If I ever heard such a sentiment from a Mac user, here's what I'd probably say:
Apple got fully functioning HTML and JS engines when they adopted KHTML/KJS. Those large chunks of functioning code got there courtesy of the KHTML developers. During the original development spanning several years Apple did not contribute a thing to what has become one of the two best web browsers on UNIX, and one of the three best on any platform. Mac users should stop and think about that for a moment.
Apple is now involved in an Free Software project. If they represent the majority of man hours on the project, then they will probably end up putting in more code than others while doing so. This is the nature of Free Software development. Apple loses nothing in their product and only gains from whatever work others continue to do as well. It's a win-win situation for them. Mac users should stop and think about that for a moment.
The Free Software community (or at least large parts of it) have welcomed the arrival of Apple and its users. I know this Free Software thing is new to Mac users, and that many Mac users tend to hold Apple in high regard and the rest of the world in less regard, but it's high time they learned to appreciate the gifts from the Free Software community that help make their current platform what it is. It isn't an us-and-them thing, it's an us-and-us thing.
I think you forget that allot of mac users come from the linux/open source platform. Well, atleast the mac os x users who know what KDE and KHTML is. Other users are just happy that they have a stable platform and a speedy browser to replace IE. They even help the open source project, by clicking on that bug button, and generating bug reports. (it's just too easy not to)
hmm... but as far as I read safari started supporting the articles on www.iht.com way back in spring whereas current CVS-HEAD of kde3.2 still deosn't seem to support it.
What do you mean by that?
Just checked the site, and i can read the articles without any trouble (kde 3.1.3)
Rinse
It works in 3.2 HEAD. There was a problem a while ago, but I think it was solved when some of the css fixes went in. Don't remember for sure.
Derek
hmmm... still not here. and I am running cvs from about 14 days ago
When will KHTML be made independent of KDE and QT so that it is easier to use on other platforms like BeOS, OSX but also Windows and Syllabus?
KHTML/KJS and related technologies are already largely independent of KDE. Things like Webcore make it independent of Qt too.
What is Syllabus?
Actually, KJS is fully independent of Qt, but KHTML isn't.
so is it possible to compile KHTML itself ? without anything else, making a .so. and update our favorite konqueror browser with the latest khtml available ?
Sorry, Syllable.
It's the AtheOS fork, it uses KHTML in it's browser.
the users have been demanding it ...
yes, but then configure comes in and tells you 'I aint generating no frickin makefiles until I see some Qt and X libs installed'. It really should be moved out from KDELibs or you should be able to tell configure to generate makefiles even though X and Qt is missing.
It sucks trying to port things to a platform without Qt and X when you even can't generate the makefiles.
"It sucks trying to port things to a platform without Qt and X when you even can't generate the makefiles."
If you fail to solve this problem, you aren't going to be able to port the rest of the libraries. Creating a new configure.in is just a minor job, after all.
Yeah, then Mozilla's Gecko and KHTML will be the only browser code bases availble. Just think, OSS would eventually dominate the browser market (code base mareket anways). There would be a revolution of Browsers based on KHTML across all platforms. Excellent strategy to help break IE's strongehold.
> When will KHTML be made independent of KDE and QT...
I agree on this question, maybe all dependencies to qt in khtml should
be removed, and this in HEAD.
This way Apple and others could work directly on the branch
> This way Apple and others could work directly on the branch
I think you're misunderstanding the situation here.
Apple's KHTML is basically an old version of KHTML (from KDE 3.02) that has been updated with their own fixes. They interface it to Safari and OSX through Webcore and KWQ. They don't make any changes in KHTML itself since it is already pretty much independent of KDE. KHTML does require a very tiny subset of Qt, and as Apple has shown, it's much easier to make KHTML completely free of Qt than just write a simple wrapper that implements the Qt classes that KHTML needs. This is what KWQ does.
Apple's Team merged the KHTML of KDE_3_1_BRANCH into their version shortly after the first Safari Beta. And I wouldn't be surprised if they continue to do so for changes in KDE's HEAD too.
Is there a document describing which components of QT are needed so a wrapper can easily be created?
then we could really deform it!
I think it's a good idea, in that case al khtml based browsers will render sites the same
It is faster and more responsive, but it screws up on some websites more than 3.1 does. For example globeandmail.com misrenders horribly and glek.net doesn't render at all :(.
I wish somebody would fix glek.net, since it's the webste that I go to many times a day and I'm stuck using moz in kde.
I don't know if I think they should care about sites like this. According to the w3c validator globeandmail.com got 275 coding errors (http://validator.w3.org/check?uri=http%3A%2F%2Fwww.globeandmail.com), and the glek.net index file doesn't even properly declare what type of document it is (http://validator.w3.org/check?uri=http%3A%2F%2Fwww.glek.net%2F).
Hmm, I wouldn't mind some rendering problems with broken sites, but Konqueror could be a bit more tolerant. I've seen several sites lately showing up completly white. Unfortunately I didn't have the time for further test but it seams to be ralated to a missing doctype.
My point is, a broken page may look broken, but showing nothing at all isn't an option imho.
One way to archive this is a broken CSS link.
IIRC, not rendering anything when a site has its main stylesheet link broken was a bug Dirk fixed a few days ago; and IIRC it was actually related to some of the Apple stuff.
A few days ago? I should update my KDE then... That's what I like about KDE: You have to be really fast, or the bug you found is fixed before you can report it... *g*
Michael
glek.net: it may be unfortunate when the site does render in gecko and not in khtml, but please look at the html source, line 8:
That page is simply broken...
DUDE you rock!
Thank you. It was a silly mistake on my part :)
Taras
glek.net works perfectly here on KDE-3.1.2. I was over at www.osnews.com the other day, and you should seen how many individuals were bad mouthing KHTML claiming the Safari developers will be it's only succour. I was extremely irritated.
Regards,
Mystilleef
...and appreciate KHTML. I also use Linux and think it rocks to have the same rendering engine on my OS X box as my Linux box -- nice consistent web page display. Yah.
Khtml is wonderful and Konqueror rocks, but both it and mozilla have a long way to go before they can be used to replace IE.
I find that more and more sites appear broken on both these browsers these days.
For example, consider going to http://www.coldwellbanker.com/
(A real estate agent).
Most of the features of the site are completely broken in both Mozilla and Konqueror. So are many other widely used real-estate sites. I am shopping for a house nowadays and find that I have to boot into windows while doing most web searches.
I guess this must be due to some IE-specific technology that the open-source browsers do not support yet. Any idea what that is?
Thanks,
Magnus.
The code for the Coldwell Banker web page is simply broken.
If you write an application in C without proper syntax it won't compile. Just the same case here...
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.coldwellbanker.com%2F
The problem is that users don't see this. If the site renders on browser A but not browser B, the user will use browser A, regardless of the quality of browser B.
It's not just a matter of building the perfect rendering engine according to spec. It's a matter of building a rendering engine that works for the most sites possible. Arguing that the sites are broken and that's why they don't work doesn't get anywhere - the users will just go with the browser that they do work on.
Or a matter of mailing the webmasters and telling them their page doesn't follow standards, and if they did a bit of effort, it'd follow them and render in most mature browsers. Hint: more browsers = more visitors -> more clients.
Or a matter of mailing the webmasters and CC-ing some management types, saying that their "we're too sexy for standards" attitude has lost them your business. If you have a relationship with a company or organisation based on money (ie. your money keeping them in business), things can quickly get changed using this approach because the technology banter passes the suits by - they just lock onto the bit about the money.
"I guess this must be due to some IE-specific technology that the open-source browsers do not support yet. Any idea what that is?"
No, what's wrong is the web developers/designers who haven't gotten around to writing !correct! code so that sites will all work cross-browser. Web standards, baby!
Actually, of all the current generation browsers that are out, IE/Win is in last place as far as DOM1, DOM2, CSS1, CSS2, XML/XSL and PNG support. Microsoft needs to get with the program. Actually, so do web designers. GET WITH THE PROGRAM! THE WEB ISN'T ALL ABOUT IE!