[KDE Dot News]
 faq
 flatforty
 contribute
 subscribe
 configure
 search
 rdf

 main
 parent


OT: acid test..
by Anonymous on Thursday 28/Apr/2005, @09:37
These patches anywhere near konqui yet?

http://weblogs.mozillazine.org/hyatt/
  Related Links
 ·   Articles on Interviews
 ·   Also by Anonymous
 ·   Contact author

Thread Threshold:

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: OT: acid test..
by Anonymous on Thursday 28/Apr/2005, @10:57
http://www.kdedevelopers.org/node/view/1001
[ Reply To This | View ]
  • Re: OT: acid test..
    by Anonymous on Thursday 28/Apr/2005, @11:40
    Thanks Zack for clearing this up. That makes me remember not to buy any Apple products now, or in the future.
    [ Reply To This | View ]
    • Re: OT: acid test..
      by Anonymous on Friday 06/May/2005, @06:11
      Why? Because they forked the KHTML code?

      What would you have them do, slow development of WebKit to suit the KHTML developers?
      [ Reply To This | View ]
      • Re: OT: acid test..
        by cm on Friday 06/May/2005, @07:21
        > What would you have them do, slow development of WebKit to suit the KHTML developers?

        No, to the contrary. Speed up the development of KHTML for both sides by combining development workforces and by maintaining a common system-independent version in a common public CVS. The system-dependent part (KWQ and whatever else they may have added) could have been maintained wherever Apple wanted it to reside.
        [ Reply To This | View ]
  • This is a little disturbing
    by foobie on Thursday 28/Apr/2005, @13:07
    Seems like we just talked about this a little while ago (
    http://dot.kde.org/1097096753/1097113373/ ).

    I know that Apple is complying with the letter of the law on this one... but perhaps we can bring some attention to this and maybe it will make apple play fair.

    One thing we can do is make some noise, it's probably too late now though (too much forking???).

    I'll try to <A href="http://panela.blog-city.com">blog</A> about this tonight.
    [ Reply To This | View ]
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?
[ Reply To This | View ]
  • 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 )

  "I switch between vi and xemacs quite a lot. I'm happy with both." -- Simon Hausmann
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.
[ home | post article | flat forty | subscribe | search | rdf ]