You can't even imagine how I hate that question. The truth is "most probably never". I just read the article on /. about Safari supporting the "all crack Acid2" test and people raving how great it is for KHTML. The truth is that KHTML will probably never get those patches. What's most probably going to happen is that one of us will simply reimplement it from scratch (and at the moment the reality is that if it's not going to be Allan or Germain it's not going to happen).
Code in Safari is hugely inconsistent and changes are always interdependent. There's basically no way of merging in one change without bringing a whole bunch of others in. And you know what? Don't even tell me about merging stuff like render_canvasimage.[h,cpp]. It outright uses OS X api's. We'll never be able to merge that in - someone will have to implement it. And what's going to happen when someone does? Some jackass on /. or some other equally stupid site will be praising Apple.
In the past when someone spent long hours implementing something in KHTML, they at least got a "thank you" from people using Konqueror. Now it's "well finally! It was working in Safari. khtml developers are lazy". Where's the fun in that?
Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.
And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist. Maybe for Apple - at the very least for their marketing people. Clear?
Syndicate Blogs
Interesting
Interesting discussion
Wellcome to "History gamers"
Thanks!
Just wanted to post my appreciation to you for your work!
You rule!
Just keep doing what you like
Hi Zack,
I read Ben's latest post (I commented there as well) and the brouhaha spilt over from it... it's sad, really sad.
I just wanted to say that real KDE users like me (I use KDE for my workstation at Yahoo!) really appreciate what you do and I just hope you keep doing KDE stuff because you like it.
Code quality and amazing architecture has made KDE what it is. I am so happy to see that hasn't changed
Thank you!
--
Swaroop
http://www.swaroopch.info
Feature Blind
@mine:
Yeah of course, get the new features without any thought of the future, become dependant on Apple, until they let you down, and then where will you be?
KHTML made more progress than I ever imagined. There was a time, when I thought, that KHTML will always be some key features short, then they somehow got a boost and now it is not perfect, but perfectly usable.
No, if Apple insists on making it impossible to use their updates, well then forget about them. KHTML is good as it is, The all important "Acid2"-Test is of no importance, because if Safari is the only browser to succeed in it, then that means, that the techniques used in there will not be part of the real web experience.
@Zack:
Don't get upset about this. You and the others did great work and I trust you much more to do the best for KHTML than I trust Apple. Intelligent people will see, that Safari would be nowhere without your work, and noone blames you for Apple's shortcomings.
Sven
Just give up...
I can understand your frustration about Apples behaviour. It's legal - but not fair.
On the other side: should Apple not use its own libraries and APIs? Should Apple test against KDE to ensure compability?
Did somebody expect that?
For Apple it would be wasted time to do so.
Because Apples resources on their KHTML branch seems to be bigger, let them make the work of implementing new features. And make a KDE-Webcore layer to make their work running on KDE.
I know, that IS a hard decision for those who invented the thing. But on the other side - why not rip-off Apple? Their KHTML branch is the de-facto standard in terms of installed user base, web conformance and speed. As a programmer I know that is not exactly the kind of "fun" as moving your own KHTML branch foreward. But its pragmatic at least.
This is not black and white
From /., a very well thought out reply to the blogger's rant:
Apple, they say, isn't playing friendly. They don't provide a CVS history, just the modified files where nobody can understand how and when things have changed.
First of all, anytime you fork off a large project like KHTML the source code bases will start to grow apart. When the new fork has a dedicated group of engineers updating it for their needs then it will quickly diverge to the point where it makes little sense to attempt to keep patches in lock step. In my career I can recall several times where this has happened, and it always seems to come as a surprise to the people maintaining the less active fork.
Apple doesn't use CVS as their normal source control system. To provide CVS documentation, Apple engineers would have to maintain a CVS database as well as maintain their patches in their standard internal SCS. This used to be perforce, I believe, and probably still is as switch a SCS is generally a royal PITA.
Because the sources have been diverging for several years, it's unrealistic to expect that the Safari patches will be directly applicable to KHTML, and I frankly doubt that even having the Safari patch documentation would help very much after several years of Apple patches. This probably isn't anything underhanded on Apple's part. It's just the way engineers work - they change the code to fit their needs, and rarely consider the impact on the old fork that they started from in the absence of an explicit mandate to stay compatible with the old fork. That level of compatibility would require the Apple folks to always have the current KHTML sources and be familiar with that source and particularly to understand the differences between the KHTML code and the Safari code.
Apple does provide the modified files, and usually this is a huge improvement on starting from scratch in implementing a new feature or fixing bugs. It does require the KHTML engineers to be able to read and understand the Safari code. To say that nobody can do that sounds a little strange.
It's quite likely that KHTML developers will have to write their own code to pass the acid2 test.
Well, yes. Should Apple engineers be expected to maintain the KHTML engine also? Apple's engineers are probably focused on their code base exclusively. The KHTML engineers are the right people to modify their own code base. Does anyone expect Apple engineers to be responsible for maintaining compatibility between Safari and KHTML? Apple makes changes, and they provide the changes files to the KHTML team. The rest is up to the KHTML folks if they want to extract the Apple code they want to use and put it into their code.
"On the other side: should Ap
"On the other side: should Apple not use its own libraries and APIs? Should Apple test against KDE to ensure compability? "
No, but they should not be putting Cocoa/Object C code in patches to KHTML. Writing an abstraction layer wouldn't be that hard and would be beneficial to everyone (including Apple) in the end.
Apple doesn't have to play nice, indeed it certainly does not benefit Apple from improving potential competition. Mr. Russin only wants people to know that Apple is contributing very little back to the KHTML community and shouldn't be given kudos for "saving" or "improving" KHTML. This sounds perfectly reasonable to me.
Apple is a company and no matter what Apple (or their users) claim about helping the "community", they rightly care for only one thing... the bottom line.
Thanks so much for a wonderful GUI and KHTML
I also registered just so I could tell you how much I appreciate what you do.
KDE is my favorite Linux GUI and always has been. There was a time when I wondered where Konqueror was going, but it truly has come a long way.
If Apple wants to be this way, and hold back or not be supportive, so be it. Personally, I think we all knew that would happen because of how they have handled themselves in the past. It was no big surprise. I think we were all hopeful that they would be better stewards, but as noted, it is allowed for in the (L)GPL. It may not be the nicest way to handle things, but it is something they can do. I guess, their idea of what a community is and is not, is just very different.
The KDE Team has done great things, and will continue to do so, because of their great commitment to a community who has truly appreciated what they do and because of their commitment to the project itself. From what I can see, the KDE Team takes great pleasure and pride in the work they do. But no one can work forever without positive feedback....so...
Thanks again and keep up the great work! It is very much appreciated!
LilBambi
KHTML was dead
1. KHTML was dead before Apple decided to adopt the project for Safari, don't forget that. The usual way had been a move to the gecko engine, this was already in preparation. There would be no KHTML today without Apple's committment.
2. Well, Linux users do not use Safari, therefore it is irrelevant what runs on Macs.
3. You say Apple uses native API. You can also think about implementing the Apple API, so that the code runs on Linux as well. Soemthing in between of Softpear and GNUSTEP. Everybody likes the APPLE engine, why not rebuild it. It's documented.
4. You shall communicate this loader, Apple is marketing sensitive.
Call a fork a fork
If KHTML is dead then I am the Queen of England
Look at the CVS of KHTML and you will see that it is alive. KHTML now support CSS shadow in better way that Webcore does, it support CSS numerotation too (the only browser with Opera).
Without Apple's committment, KHTML would be what it is today. The time spend to merge the few Apple patchs that can be merged would have been used for implementing other things or this things. So nothing new under the sunshine. With or without Apple things are the same.
Apple had made a KHTML fork. They don't collaborate on KHTML. The worst is that they keep the name "khtml" for proprietary CSS name (-khtml-*) and for the user-agent so now people only test websites int Safari pretending that it use KHTM engine. No ! Safari use Webcore and Webcore is not KHTML ! Webcore and KHTML differ in their implementations of CSS/(X)HTML. Webcore is sometimes better and sometimes worst than KHTML.