faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: OT: acid test..
by Marc Driftmeyer on Thursday 28/Apr/2005, @23:24
|
Boo-f******-hoo.
I use Debian Linux with KDE 3.4, daily and have been using KDE the first day I installed Debian 4 years ago. I also use GNUstep which Debian does a fair job at making it interoperate with KDE.
Being that no one gives too shits to the wind about GNUstep or implementing native support for Objective-C and ObjC++ within KDE (Openstep is right there and you do have GNUstep to work with) it amazes me that KDE wants Apple to implement their version of KHTML to KDE's desires. Afterall, GCC 4.1 is supposed to have ObjC++ support.
As was written on that blog: KHTML was dying and the high profile Apple gives it with code blobs back to KDE only reminds me how dense people can be--there is no such thing as a free meal.
If KDE can't get enough coders together to duplicate the code blobs updates for KHTML so be it--its their failed responsibility to keep the project viable. Why doesn't Trolltech step up and produce a KHTML web browser engine for KDE? Or better yet, coordinate with Apple to help smooth the situation over? |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: OT: acid test..
by Luke Chatburn on Thursday 28/Apr/2005, @23:43
|
Erm... KHTML was dying? You really could have fooled me. I was using it in Konqui on the desktop, as was 50% or higher of the Linux user market and the KDE on BSD folks and many more. KHTML has been ported to numerous platforms, and indeed, provides web browsing to a number of other small OS projects.
With the current rate of growth in Linux and BSD use, it is entirely possible that more people have Konqui installed than Safari (or indeed OSX as a whole), or they will have within the next year (statistics on Linux use being vague as they are...).
If Apple writes ugly code that can't be merged without building extensive support harnesses, then maybe it is faster to reimplement that code. That's what Zack is saying, and no doubt, that is probably the intention of Apple, to be quite frank. Manpower resources of any project would have problems fixing this mess; it's not a reflection on the KHTML team strength.
Bottom line: The KHTML developers made nice software, LGPL'd it, Apple benefited (they got that free meal that you talked about) and decided not to play nicely with the developers of the nice modern rendering engine that they got *for free*.
They're a standard selfish company that is chasing profit and not goodwill. That's life and that's okay; but there is no need to blame the KHTML developers for Apple's failures.
|
[
Reply To This | View ]
|
Re: OT: acid test..
by Anonymous on Friday 29/Apr/2005, @01:29
|
> Why doesn't Trolltech step up and produce a KHTML web browser engine
An html engine? Because they work next door to Opera and know from cafeteria talk how hard work that is? :-)
|
[
Reply To This | View ]
|
Re: OT: acid test..
by Richard Dale on Friday 29/Apr/2005, @02:57
|
"Being that no one gives too shits to the wind about GNUstep or implementing native support for Objective-C and ObjC++ within KDE (Openstep is right there and you do have GNUstep to work with) it amazes me that KDE wants Apple to implement their version of KHTML to KDE's desires. Afterall, GCC 4.1 is supposed to have ObjC++ support."
Well, I care about Objective-C - all my work on bindings was funded by NeXTSTEP/Objective-C contracting.
I spent 6 months working on Qt/KDE bindings for C and Objective-C, but nobody much was interested, and I never quite got the KDE bindings to link properly, although the Qt-only one worked fine. I think it makes more sense to use GNUstep if you like Objective-C, and if you don't like C++ you can program KDE in ruby or python.
Until ObjC++ is part of gcc, it isn't really feasible. I learned that if you have to wrap a C++ api in C, and then once again in Objective-C, the whole thing is just too enormous. Once we can go straight to Objective-C via ObjC++ it will be a different matter. And use the Smoke library via -doesNotRecognizeSelector:, so there would be a lot less glue code with just one entry point from Objective-C to C++. You divert the entire api into a single -doesNotRecognizeSelector call, and do all the possible types of Objective-C <-> C++ marshalling in one place.
|
[
Reply To This | View ]
|
Re: OT: acid test..
by Derek Kite on Friday 29/Apr/2005, @08:31
|
To suggest that khtml is or was dying is a troll. It isn't and wasn't.
A little history here. Apple is doing the minimum it can to fulfil it's license operations. That is their privilege and right.
Apple announced Safari with much fanfare after working on it for around a year. They based their work on an earlier version of khtml, did their changes, integrating the improvements from the khtml team over that time. All in secret. Then they released the software, and as per lgpl, released the source code. Already at that point the code bases had diverged, some due to the removal of any Qt stuff, and over that year considerable progress had been made on khtml without Apple's contribution.
Many improvements were merged into khtml and that work continues. The merging consists of taking a tarball, figuring out the differences from the previous one, matching that to the changelog, factoring out the Apple specific api stuff, and then changing khtml. Repeated requests have been made to have access to the source management tree so that at least patches could be extracted for specific issues. But no.
Apple can do what it wants. Fine. They have essentially taken on the development and maintenance of a browser and html engine. Any of the economics of FOSS don't apply anymore here. They are on their own. Any goodwill that may have come from this decision is gone. The license responsabilities are an expense without any of the benefits.
Khtml development continues and will continue with or without Apple. Maybe they figured that eveyone using KDE would drop it for the vastly better MAC os, all the while kissing their feet with admiration and devotion, and continue to improve khtml for Apple's benefit. It hasn't happened that way. When it is no longer in Apple's interest to spend the money to maintain Safari, they will discontinue development. Apple is in a situation where the squeeze is coming from both sides. Microsoft is again taking interest in the browser. The free desktops are grabbing the Microsoft castoffs, or at least a percentage of them. The standard zero sum game of the software business is at play. I ran across an interesting comment the other day. Two three years ago at the Linux conferences most people were using Apple products. That is no longer the case due to the improvements in Linux and the desktops.
What Apple does is up to them. I really don't care for them or their products, and even less so seeing how they work with the free software community. I don't need to buy their stuff, and they have given me a reason why I shouldn't. The odd thing is that they would have benefitted from a little openness.
Derek
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
