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


Re: webkit in konqueror!
by jos poortvliet on Monday 10/Mar/2008, @03:30
They most likely decided to use QtWebKit because it is the native rendering engine for Mac OS X widgets so they are more likely to work.

And there are more developers and users for WebKit, and TT supports it. Once some technology moved from KDE to Qt, why support it ourselves any longer? Personally I don't see use for that, even though there are some minor differences between KHTML and WebKit...
  Related Links
 ·   Articles on Developer
 ·   Also by jos poortvliet
 ·   Contact author

Thread Threshold:

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

Re: webkit in konqueror!
by Sebastian Sauer on Monday 10/Mar/2008, @04:21
> why support it ourselves any longer?

and this is what I don't understand. Why do ppl who actually don't work on something believe that they are able to deny others to work on it too? Shouldn't such a decision be up to those who do the job? One of the great things KDE is about is to "be free" and afaik the "those who codes decides" rule is still valid. Also there is just no reason to go with A or B since we can have both and somehow that even matches the "free to choose" way I love so much in KDE.
[ Reply To This | View ]
Re: webkit in konqueror!
by Erunno on Monday 10/Mar/2008, @06:09
Since KHTML is part of kdelibs it will have to be supported until KDE 5 as far as I understand it. And the next major revision is years away so it's probably in the best interest of KDE to stay on the good side with the KHTML developers since their loss might not be easily replaced judging by the complexity of the KHTML codebase.
[ Reply To This | View ]
  • Re: webkit in konqueror!
    by Hank Miller on Monday 10/Mar/2008, @06:59
    Not really, if khtml development really dies, it wouldn't be that hard to make the kthml API just wrap the webkit API (which we get for free from QT). There would be some extra overhead to doing it this way, but not much - you can already choose webkit or khtml, so most of the time this wouldn't even be used as we can make the default webkit.

    What would be really interesting is to separate khtml out (like webkit was once separated from khtml), and get some of the gnome guys working on webkit into khtml. I'm not sure if this is possible, but it would be really interesting. If Apple decides to close up webkit just a little bit (I'm not sure if they can anymore) khtml might be the way to go. Perhaps we can even make khtml an alternative plugin for safari browsers.
    [ Reply To This | View ]
    • Re: webkit in konqueror!
      by Erunno on Monday 10/Mar/2008, @07:07
      I stand corrected then. But 'm curious if such a wrapper wouldn't break ABI compatability which is also guaranteed until KDE 5. I confess that my C++ knowledge is medicore at best when it comes to compiler voodoo.
      [ Reply To This | View ]
    • Re: webkit in konqueror!
      by SadEagle on Monday 10/Mar/2008, @07:19
      The QtWebKit API is only a tiny portion of what KHTML provides. And if it weren't, what makes you think anyone would do it? In fact, if people were actually willing to do work, instead of spreading FUD, you might have seen a libkhtml based on WebCore already.
      [ Reply To This | View ]
      • Re: webkit in konqueror!
        by Anon on Monday 10/Mar/2008, @07:36
        " In fact, if people were actually willing to do work, instead of spreading FUD, you might have seen a libkhtml based on WebCore already."

        Is this still possible in 4.x while maintaining BC? What kind of skill level would be required for someone interested, and roughly how much work would you say it was?
        [ Reply To This | View ]
        • Re: webkit in konqueror!
          by SadEagle on Monday 10/Mar/2008, @07:38
          For most classes, BC is trivial, for things like KHTMLPart it's not, but doable. The hard part, and the incredible tricky kind of work, is making it integrate properly. That means, for example, that a web page should still be able to embed, and script KMPlayer, that all the settings are followed, etc, that the KIO and KParts hooks are still in there, etc.
          [ Reply To This | View ]
          • Re: webkit in konqueror!
            by ac on Tuesday 11/Mar/2008, @12:41
            Perhaps it is even an advantage of WebKitQt that it does not use KIO with its excessive reliance on DBus-based IPC. I've got a notion that Konqueror feels exspecially sluggish (in comparison to other browsers) when it has initiated a lot of KIO Slaves.
            [ Reply To This | View ]
            • Re: webkit in konqueror!
              by SadEagle on Tuesday 11/Mar/2008, @13:15
              KIO doesn't use DBus for communications with an I/O slave.
              [ Reply To This | View ]
              • Re: webkit in konqueror!
                by ac on Wednesday 12/Mar/2008, @09:03
                Yes, in this case "socket-based IPC" would be more accurate. Nevertheless, if Konqueror's sluggish behavior on some sites is not caused by the rendering engine but by KIO, the KDE bindings of WebKit you are proposing (as opposed to pure Qt bindings in QtWebKit) would not be of much help.
                [ Reply To This | View ]
  • Re: webkit in konqueror!
    by Erunno on Monday 10/Mar/2008, @07:03
    I stand corrected then.
    [ Reply To This | View ]
Re: webkit in konqueror!
by D Kite on Tuesday 11/Mar/2008, @04:19
This is the strangest situation I have ever seen in a community project.

Someone demonstrably hostile to our interests has a neat shiny thing and we shun a community based project for one controlled by interests at best undefined (Nokia) to allow loading third party widgets into a single process user interface.

Derek
[ Reply To This | View ]
  • Re: webkit in konqueror!
    by S. on Tuesday 11/Mar/2008, @06:49
    > interests at best undefined (Nokia)

    and for the goals, it suffice to read the announcement at http://trolltech.com/webkit/webkit-announce to get a glimpse of the new corporate focus:

    "Announcing the Qt WebKit Integration

    Trolltech's Qt WebKit Integration brings Web 2.0 services to *mobile phones*
    Helps *mobile operators* and *handset manufacturers* enrich *phone* applications with live web content such as online maps, music stores and instant messaging" (emphasis mine)

    Quick, what is the missing keyword in this announcement? ;-(
    [ Reply To This | View ]
    • Re: webkit in konqueror!
      by D Kite on Tuesday 11/Mar/2008, @08:05
      Nokia worked on Webkit long before Trolltech was involved in it. Long before Apple 'opened up' development to the free software developers that created the original codebase.

      Nokia's interests towards KDE are undefined.

      Derek
      [ Reply To This | View ]
  • Yes! It is silly!
    by anon on Wednesday 12/Mar/2008, @19:23
    Unfortunately, there are some in the KDE-world who have decided for some arbitrary reason that a beta QtWebKit port is somehow better than what we already have. I say arbitrary, because they haven't done development work on either one.

    And also unfortunately, they are very good at propaganda.

    Users lose.
    [ Reply To This | View ]
  • Re: webkit in konqueror!
    by MsmiysOtaru on Thursday 13/Mar/2008, @13:22
    Put that way it really does sound outlandish. Unbelievable in fact.
    [ Reply To This | View ]

 
The Fine Print: The previous comments are owned by whomever posted them.
( Reply )
  "I can't describe the scene as this is a G-rated site, but think Pulp Fiction." -- Sirtaj Singh Kang
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 ]