Unification and Orthogonalisation: Part 3, HTML-Engines and Web Browsing

Hi!

In this blog-post I want to share some thoughts about HTML-rendering-engines and web browsers in KDE. There seem to be some problems, some may be easier solved with KDE5 (breaking some API may help).

Does there have to be a KDE-browsing-experience?

When looking at browser-statistics for my blog, most people seem to use Firefox or Chrome/Chromium, using Konqueror or Rekonq is kinda exotic, browser statistics may be wrong (I am sometimes using “faked” user agent string if websites do not like Konqueror), but I evena know many KDE-users personally using Konqueror or Chromium. But I think KDE-browsers actually have potantial. Everybody is annoyed about Gtk+-file-selection-dialogues, but there are also real features provided by KDE, in some areas Rekonq provides unique interface, Konqueror can satisfy many wishes for flexibility. I am not that happy with Firefox and Chromium (quoting Martin Gräßlin “it is broken” (client side decoration ;))). KDE-web browsing should not be dropped, and certainly nobody is planning to do that.

Rendering engines

We should be honest about KHTML: We have to admit that the JavaScript support is poor and technically not up-to-date. Many websites are not working, even KDE-related ones, popular sites like Blogspot etc. KHTML is certainly not yet dead because kdewebkit is not yet a working alternative, it is lacking behind regarding KDE-integration (KDE style widgets are a must-have), and it cannot yet be considered to be stable, too. But there is one thing which would be definitely nice: a common interface. KDE is able to attract plugin-developers (see Plasma), it has great technical capabilities (KPluginFactory etc.), but they would have to be used. If there would be a unified way to access both KHTML-KParts and WebKit-KParts, it would make it more reliable for people wanting to write a plugin and of course it would be better for every user if KHTML-plugins could be used with WebKit in Konqueror. API could be unified with KDE 5, but there is still a lot time left, maybe an alternative should be found.

Konqueror and Rekonq

That has to be said: Rekonq started as a “hey, I will try to build a web browser” project, today it is the default web browser in Kubuntu and provides e.g. the awesome address-bar. It is now a more serious project, so why is it not integrated into KDE technology? Konqueror is excessively using KParts and KXmlGui, I think it would have been no problem to implement Rekonq’s user interface elements as plugins and using Konqueror’s infrastructure. Not only Konqueror would benefit, but it would provide built-in plugin system, PDF viewing, split view, synchronously displaying HTML and modifying via FTP etc. I am sure some performance optamisations could be done for KParts/Konqueror, too, without breaking everything. Now we have got two independent web browsers. Even with Dolphin it is a problem, the promised integration did not become true, the useful dockers (e.g. for Nepomuk), address bar etc. are not available in Konqueror, which is using its own sidebar unaffected by Dolphin. But for Rekonq it is even worse because Rekonq does not even try to integrate into KParts.

It would be nice if there would be a single, unified web browser with a reliable rendering/JavaScript engine using all the great technology KDE supplies – especially all the flexibility provided by kdeui.

Regards
A loyal Konqueror user

38 Responses to “Unification and Orthogonalisation: Part 3, HTML-Engines and Web Browsing”

  1. damipereira Says:

    First, konqueror and rekonq are 2 completely different projects, rekonq is a web browser, and konqueror is a swiss knife, it can do a lot of stuff.
    These 2 projects can’t and shouldn’t be merged, the kde browsing experience can be got with rekonq, it should be default, and included in kde releases, konqueror should be left for what it’s good, being a swiss army knife, it’s really useful for lots of people (me myself find it a very good program), but it’s not the kind of thing you expect to find when looking for web browser.
    About kparts and kxmlgui, they are a good technology to build a swiss army knife application, because they are extremely flexible, but they are not good for a simple nice web browser like rekonq.
    As another subject, konqueror might benefit from kdewebkit, but this is all for the konqueror developers to decide.
    So in summary, rekonq should be default web browser, just as dolphin became default file browser, and be bundled in kde releases, distributions should install rekonq by default, and konqueror only if distributions thinks their user might make use of such app (konqueror itself is a very good app).

  2. Dion Says:

    I don’t use Konqueror or Rekonq, I tend to use Chrome primarily and Firefox as an increasingly rare backup.

    I personally feel it is a waste of our KDE communities resources to build yet another browser. Browser development has become something of an arms race. Particularly around rendering engines and Javascript engines.

    I would much rather see us work with Google and Mozilla to provide kpart based file save and open dialogs, menus and keyboard shortcut bindings for Chrome and Firefox (Thunderbird too but thats another story). Also maybe theme support so KDE themes are respected by the browser.

    The thing is, I don’t believe the general use case justifies much more than UI support so the app looks native under KDE.

    For some people, maybe the swiss army knife of Konqueror is something of a big deal. Perhaps because it can be hooked into the KDE Wallet? I don’t know, maybe some Konqueror power users can comment. I personally can’t see any real value added.

    Regards.
    D.

  3. Kevin Kofler Says:

    * Konqueror looks and feels like a KDE app (because that’s what it is), not like something from another planet. Firefox will never look and feel that integrated.
    * Konqueror uses standard KDE dialogs.
    * Konqueror’s menu structure is the standard KDE one.
    * Yes, Konqueror supports KWallet, which is important too.
    * Konqueror supports KIO (e.g. kio_gopher), KParts (e.g. the Okular KPart) etc.
    * Konqueror has many builtin features, Firefox requires a bazillion extensions to even get close.

  4. Lionel Chauvin Says:

    @ The User
    >I think it would have been no problem to implement Rekonq’s user interface elements as plugins and using Konqueror’s infrastructure.

    It seems nice but it is not so easy.

    New tab button
    How you will implement it as a plugin without konqueror itself?
    How it will work if konqueror has tabs with different kparts opened ?

    Awesome adress bar
    It contains icons of the status bar. How it would have worked with current konqueror’s status bar ?
    If you use konqueror as a web browser and as a file manager at the same time: how this bar must handle search queries ?

  5. hate-engine Says:

    javascript is evil. i’ve switched it off

  6. f6 Says:

    Is there an active development on konqueror? In the last years I didn’t recognize any new features in the last year. The bugzilla is full of unresolved bugs and a lot auf feature wishes.
    It’s hard to see which status konqueror has got in comparison to kde3 times. I hope that konqueror will not die slowly over the time. Maybe it would be a solutionen to have a GSoC project for konqueror. So someone gets familiar with the code and maybe he/she would stay at the konqueror project.
    BTW what happens to http://edulix.wordpress.com/2009/04/23/gsoc-konqueror-bookmarks-with-akonadi-and-nepomuk/ or the former plugins like rss in the sidebar or the imagegallery?

  7. fritz van tom Says:

    rekonq actually uses kparts.

  8. The User Says:

    konqueror should be left for what it’s good, being a swiss army knife
    But what should it be good for in the end? There is no decent file management and no decent HTML viewing support in Konqueror, the Dolphin integration does not work as it was claimed to do, and Rekonq integration does not work at all. So what should it be good for? Gopher? For most applications you would need good file management or good HTML viewing (e.g. FTP-client). Konqueror is depraving.

    About kparts and kxmlgui, they are a good technology to build a swiss army knife application, because they are extremely flexible, but they are not good for a simple nice web browser like rekonq.

    Rekonq is no longer a proof of concept, but it is going to be the KDE-web browser. Do you know what Firefox is using? XUL. And it is awesome, because there are great plugins, it can be scripted etc. Maybe Rekonq will finally add plugin support, it already embeds PDF. It reimplements a lot of small features, instead of thet it could use a flexible structure providing all that stuff, that would make much more sense.

    As another subject, konqueror might benefit from kdewebkit, but this is all for the konqueror developers to decide.

    Rekonq does not even use kwebkitpart. Konqueror benefits from nearly nothing of Rekonq.

    * Konqueror has many builtin features, Firefox requires a bazillion extensions to even get close.

    I guess there would be much nice extensions for Konqueror if it would not be treated as a step child you only use in very special situations. Sometimes I really miss something, but implementing it would probably only work for KHTML, not for WebKit.

    New tab button
    How you will implement it as a plugin without konqueror itself?

    How it will work if konqueror has tabs with different kparts opened?

    Konqueror already has a new tab button? How does it work in Rekonq if there is a PDF opened? What is your problem?

    Awesome adress bar
    It contains icons of the status bar. How it would have worked with current konqueror’s status bar?

    By hiding the status bar?

    If you use konqueror as a web browser and as a file manager at the same time: how this bar must handle search queries?

    Current Konqueror address bar can also handle search queries (btw. it is also a plugin). And why shouldn’t it depend on the profile used? I do not see a problem. There could be a Rekonq profile. Hiding status bar is not that complicate, in fact it would be very easy. It is a standard kdeui option to hide the status bar, but for some reason it is not in konqueror.rc. One line in konqueror.rc and you could hide the status bar.

  9. fritz van tom Says:

    and KXmlGuiWindow

  10. BajK Says:

    I really really really wanted to give Rekonq a try on my machine after new install.
    But it just sucks. There’s nothing you can do about it.
    It begins with webstandards support. It does not support text-shadow properly, box-shadow not at all. BUT it supports complicated CSS animations that aren’t even in the specs yet.
    It just feels weird. The address bar is a user experience fail in all cases. In Chromium I enter “pl” and it suggests “planetkde.org” and I hit enter. In rekonq it suggests “Search wikipedia for ‘pl’” (why the hell wikipedia?!) and planetkde.org is on 3rd or 4th position, so I need to utilize the arrow keys (or just enter the full address).
    Also, it has no bookmarks bar. It does have you might say, yes, but it just shows the normal bookmarks you have in your bookmarks list. EVERY Browser has a bookmarks bar that shows an INDEPENDENT set of bookmarks. Even Internet Explorer has had this for 15 years now. But Rekonq doesn’t. One K-O-Criteria.
    Another severe issue for me is that it does not support HTML5 video at all! I hate stupid flash and it just sucks (oh, and flash doesnt work right as well). This is why YouTube is the only video platform I regularily use since it supports HTML5 mode. But rekonq doesnt. Second K-O-Criteria.
    So we have: No proper CSS-Support, No HTML5-Video-Playback, no independent bookmarks bar and an annoying address bar.
    And you wonder why nobody uses it?
    (Oh and for Kubuntu: Canonical is known for installing shitty Beta applications by default. Goes for unfinished GStreamer, PulseAudio (now it is ok but when it was introduced it was the first thing to uninstall on fresh setup), etc etc
    (And why does this captcha not accept “Nineteen” as answer? I need to type “19″)

  11. The User Says:

    rekonq actually uses kparts.

    Yes, it uses it to display PDF, but it does not give anything back, it is not usable as KPart, the HTML pages are no KParts, thus they are not usable from Konqueror and they are not scriptable with KParts’ plugin system. Dolphin also uses KIO but it’s usually artificially limited to file://.

  12. TheBlackCat Says:

    Rekonq is getting plugins support, maybe in the next version. They are implementing a common html-based plugin system shared with chrome and perhaps other browsers (I think firefox is working on a similar plugin system).

    As for website rendering, that is completely controlled by webkit, but unfortunately the version shipped with the last version of Qt is out of data.

    And dolphin is not limited in the kio slaves it can use, it can use almost all of the kio slaves konqueror does (I don’t think it can use the sysinfo: kio slave).

  13. The User Says:

    And dolphin is not limited in the kio slaves it can use, it can use almost all of the kio slaves konqueror does (I don’t think it can use the sysinfo: kio slave).

    Of course it cannot use sysinfo, because it cannot display the content.

    Rekonq is getting plugins support, maybe in the next version. They are implementing a common html-based plugin system shared with chrome and perhaps other browsers (I think firefox is working on a similar plugin system).

    Once again, new redundancy, the awesome KParts-plugin-system is not used, and Konqueror will probably not even benefit… You want to tell me that this is good? When greatest KDE technology gets dropped?

  14. TheBlackCat Says:

    Isn’t kparts-plugin-system C++ based? That makes it impossible ship scripted plugins like firefox has. Plugins need to be installed then compiled, which makes them unsuitable for mass distribution of simple functionality like we see with firefox extensions. They are also much more complicated to program.

    If you want a lot of developers creating add-on functionality for your web browser, you simply cannot ask them to write an entirely new library from scratch. If you want users to use add-on functionality for your web browser, you can’t ask them to compile the source code.

    If konqueror has such a great plug-in system, where are there so few plugins for it available? It looks like there are already almost 11,500 google chrome plugins. On the other hand searching for konqueror on kde-apps.org returns about 440 results, only a small fraction of which are actually plugins for konqueror, and fewer still that are plugins for the browser part (there does not even appear to be a category for such plugins).

  15. Alejandro Nova Says:

    There’s something that could be done with Konqueror even without touching its source code.

    1. Enable tye addess bar to work like a search bar.
    2. Remove the search box in the upper right corner, make it optional.
    3. Switch to KDE Webkit as default.

    I did these 3 things, and now Konqueror is a real alternative for me. I still use it as the backup browser for Chromium or Firefox, but you get the idea.

  16. f6 Says:

    @TheBlackCat
    I think what The User want to say is that if there were an kpart of rekonq (like kfm from dolphin) konqueror could integrate it. So konqueror would benefit directly from the rekonq development. If rekonq would have an plugin system (from chrome) konqeuer would also have it.

  17. Kevin Colyer Says:

    I would like to add that for me Konqueror is (as someone else said) a Swiss Army knife. My key use is for Mediawiki editing, where it is superior to all other browsers because it has fabulous find and replace (regexps!), using a the kde text editor component. This is such a strength for me in this application… Also having tabs that can hold webpages and filesystem pages (not to mention fish:/ man:/ perldoc:/ etc. kioslaves) whilst I do that makes me very productive.

    OK for using Google web products and most other web browsing Chromium or Firefox is my tool of choice. But it is the versatility that I like the best. I tried the webkit part but it looses the text editing components. If it did not I may well never use Chromium or Firefox.

    I hope this gives insight into my usage. Personally, I have a preference, but there is so much wonderful and excellent free software at this point in time, I can only express my gratefulness to the devs for their work and allowing me the luxury of choice and preference!!!!

  18. Andrea Diamantini Says:

    IMHO, we are yet a “hey, I will try to build a web browser” project ;) There are just some other else trying.
    We are having fun doing it. And I think we’ll continue doing what we think is cool and important, with our own rules and schedules. In the same way (I think) you write in this blog and people read and comment here.

    Talking about your post, I’d like to understand what you’re intending with “why is it not integrated into KDE technology?” Is everything because of the kwebkitpart we don’t use?

  19. The User Says:

    Isn’t kparts-plugin-system C++ based?

    Yes, it is written in C++ and supports C++ plugins, but it also supports Ruby, Python and Perl plugins (I have tried it for Ruby and Python). It would be easy to extend it for JavaScript (thanks to jsmoke) and WebKit. How do you think Plasma addons work? That is in my opinion much more awesome technology then all those specialised QtScript/JavaScript plugin systems.

    If you want users to use add-on functionality for your web browser, you can’t ask them to compile the source code.

    Allowing compiled languages is a good thing, in my opinion JavaScript is an ugly programming language, others may like it, but some people prefer C++ or Python, why should they not be all allowed like in Plasma? Cf. my previous blog post for some information about the plugin system…

    If konqueror has such a great plug-in system, where are there so few plugins for it available?

    First of all, there may be bugs and missing features, thet may be true, but its idea is really nice and it has been successfully used for awesome applications/libraries like Plasma. There are multiple reasons: First of all the technology does not get propagated. There is no KHotNewStuff integration, lack of documentation, support by jsmoke is missing, WebKit is not fully supported for scripted languages, and if it would be, it would be a separate interface different from KHTML’s. Such a HTML based plugin system would probably be easy to integrate, too, using a plugin factory (cf. Plasma’s Google Gadgets support). And of course nobody writes plugins if Konqueror seems to be obsolete. And KDE’s userbase is smaller. :(

    1. Enable tye addess bar to work like a search bar.
    2. Remove the search box in the upper right corner, make it optional.
    3. Switch to KDE Webkit as default.

    1. Huh? You can use it as search bar, although it is not that neat as Rekonq’s, but also Rekonq’s could be made a plugin for Konqueror.
    2. I have removed it for my Konqueror, “just” had to modify konqueror.rc. Unfortunately the GUI configuration of tool bars seems not always to work.
    3. You can configure that in system settings

    I tried the webkit part but it looses the text editing components.

    Yes, kdewebkit should support KDE widgets, but I am not sure if that is easily implemantable.

    Talking about your post, I’d like to understand what you’re intending with “why is it not integrated into KDE technology?” Is everything because of the kwebkitpart we don’t use?

    No, of course that is a point, Rekonq WebPage and kwebkitpart should not be different classes, why isn’t it built as Konqueror profile? Cooler address bar? Create a new address bar plugin! Remove search bar? Just remove it from XML .rc-file! No status bar? XML file! Tab and history overview? Simple KParts! Plugins, KGet, PDF, bookmarks, adblock? Get it for free! You are reinventing the wheel for stuff which has been provided by kdeui in lot more flexible way since long time. You wanted to create a new web browse… you could have used Konqueror as a framework to create something completely new which is integrated into existing technology.

  20. M Says:

    Konqueror is the only browser having a “go up one level” button by default and the possibility to navigate with vi-keys. And yes, these are very relevant details for me, which contribute a lot to my browsing experience. And rekonq does not have (and will never have) a menu bar, which is part of the look&feel on some desktops.

  21. The User Says:

    @M
    I do not want to promote Firefox, but there is vimperator. ;)

  22. Andrea Diamantini Says:

    that was not the initial choice exactly to break with konqueror’s behavior. I was just trying (I’ll repeat another time) to implement a browser. Just one browser. Not a konqueror clone. And I’m quite sure that if I started to change until it becomes konqueror rekonq you’d be here to tell me that I had ruined konqueror :)
    Why in the hell “the default KDE browser” (as you called it) should be just a konqueror profile?

  23. The User Says:

    And I’m quite sure that if I started to change until it becomes konqueror rekonq you’d be here to tell me that I had ruined konqueror

    No, I would not, the Konqueror browsing experience is not that awesome all the time, if you would have built a sophisticated application using KXmlGui and KParts etc., I would be happy about such a great alternative, but obviously, if you had planned to do that, you would have started with reusing functionality from Konqueror. Konqueror itself is actually not that exciting, it is session and profile management, some settings interface, history, bookmarks and tabs. No especially awesome stuff. KParts is the exciting thing about it. Actually every web browser is a swiss army knife, and Konqueror is using some especially great technology that for. Saying there should be the swiss army knife Rekonq and the uglier, but more swiss army knife Konqueror does not make sense (that is not related to your statement, but to the “swiss army knife” argument).

    Why in the hell “the default KDE browser” (as you called it) should be just a konqueror profile?

    Because that would be quite a lot? What is great about Rekonq? Address bar, tab and history overview, and decent WebKit integration. Could such great stuff not be achieved within technology like KParts? It can, and in my opinion in a much better way (looking at Rekonq WebPage sourcecode: that is just ugly). Should the office suite implement its own UI elements? Would it be that bad if Rekonq would not have its own MainWindow class? I am just trying to make people aware that there is too much redundance and that awesome technology should not be just dropped. Porting to KParts platform may be a project idea.

    that was not the initial choice exactly to break with konqueror’s behavior.

    What do you mean? Which behaviour? I guess your initial motivation was in no way related to Konqueror?

    I was just trying (I’ll repeat another time) to implement a browser.

    Yes, nice. :) But now it is going to be the default etc. and one may think about better integration.

  24. Andrea Diamantini Says:

    What is actually clear IMHO is that you like a lot kparts, while I don’t. Basically, the main difference between rekonq and konqueror is: given a URL, rekonq tries to render it with webkit before. If it cannot, it tries to handle it with a kpart (but in a couple of cases, where I explicitely decided to not do it). So, in other words, full browsing experience (given webkit does it), “less” KDE integration.
    konqueror tries to detect its mimetype and to guess the right kpart to show the url content from the beginning. Full KDE integration (given kparts do it), “less browsing experience”.

  25. The User Says:

    “less browsing experience”

    Could you explain me why the dirty Rekonq WebPage implementation adds “browsing experience”? And do you think that it is good if Rekonq is reimplementing all stuff, even boring stuff like embedding Okular or storing history or activating Adblock, without code sharing, without new features, or sometimes with major disadvantages (i.e. new plugin system).

  26. John G Says:

    I change the default web browsing engine to WebKit in Konqueror and have little to no problems when browsing. Kparts helps me use KDE specific programs for files I encounter or download (which eliminates the need for specific plugins). I’m also using Adobe’s x86_64 beta of their Flash.plugin. Opera is my backup browser – which I rarely use.

  27. Dawit Alemayehu Says:

    I am the person that created kdewebkit and maintain kwebkitpart and you completely loose me on what you are advocating here. reKonq just like Dolphin was designed to address the needs of users that do not believe in the same mode of work as those of us that love and use Konqueror. They want separate applications for doing their file management and web browsing and reKonq fulfills that role. Saying reKonq developers should have created something that fits into Konqueror is no different than saying Chromium developers should have created something that fit into Firefox or better yet why even bother with a new browser.

    As far as sharing technology between reKonq and Konqueror, you seem to be under the impression that reKonq somehow does not use KDE technologies or at least does not do it well enough. The only difference between reKonq and konqueror is reKonq is not a KPart. Period. As such why should it use kwebkitpart ?? You do know that both kwebkitpart and reKonq use kdewebkit, right ? They both are integrate with KDE technologies in the exact same way through the use of kdewebkit. Perhaps you did not realize that kdewebkit is nothing more a wrapper library used to integrate QtWebkit with KDE technologies such as KIO, KCookiejar, KWalletmanager and embedded KParts ? Also labeling Dolphin’s and reKonq’s KIO support as artificial is just simply wrong. Dolphin was designed to support file management only and as a results only supports ioslaves that support listing, e.g. ftp, sftp, and smb. The reverse is true for reKonq ; so I do not understand your notion with that statement. If an application does not support each and every ioslave then it is only supporting KIO artificially ? Does every application need to be a universal browser like Konqueror ?

    Plugins are another topic you do not have the complete grasp of. First, you can create plugins that can be used by both khtml and kwebkitpart so long as you stick to using the KPart Extension classes provided in kdelibs/kparts. Few more extension classes were added by David and myself for KDE 4.6 so that the most essential plugins are ported to use these generic interfaces. That not only make them available to whatever kpart that supports the specific extension interface they rely on, but it also makes them more memory efficient by not linking against any rendering engine! More importantly however, the fact that the the khtml kpart plugins cannot be used by kwebkitpart is the plugins problem because they were designed to support only khtml, which at the time they were created was the only rendering engine around in KDE land. However, saying that KHTML plugins should be used by WebKit is really incomprehensible since Webkit is a completely separate project than KDE and KDE does not implement its own version of WebKit. As already stated above it uses QtWebKit through a thin integration wrapper library called kdewebkit.

    Last but not least, the reason a couple of users seem unimpressed by reKonq or any QtWebKit based browser has nothing to do with KDE or KDE application developers, but with QtWebKit upon which they rely. Almost all users use the QtWebKit that came bundled with Qt 4.7 which is based on webkit that is more than a year an half old! In webkit development that is almost a century ; so certain features that exist in the recent release of chromium are missing from these browsers. When the Qt folks start releasing the standalone versions of QtWebKit starting with the next 2.2 version, then people will find these browsers a whole lot more useful.

    What you should worry about is the fact that there are not anywhere near enough developers that participate in the development of these applications. I can tell you from my own experience that it is only I now that work and maintain kwebkitpart and for the most part kdewebkit. That is in addition to all the other stuff that I worked on that would have otherwise suffered from bit rot, many KIO bug fixes, proxy support in KIO, cookie handling, lots of things in the most used ioslaves (http, ftp). The same goes for Konqueror. If you take David away from it, there are no developers that volunteer to work on improving it. By comparison, QtWebKit has many more developers working on it and even that fails to compare with the number working on Firefox and Chromium. There is just no way to compare open source projects with paid developers against those that are purely volunteer driven ones. If anything that is what will doom the “browsing experience” or any other portion of the KDE project for that matter. Perhaps lack of drum beat from people like me also contribute to this since we do not blog about them as Aaron and the other developers do for plasma. But then again, I do not have any spare time to blog regularly.

  28. The User Says:

    If an application does not support each and every ioslave then it is only supporting KIO artificially ?

    Indeed, that sentence by me was nonsense.

    You do know that both kwebkitpart and reKonq use kdewebkit, right ?

    Yes.

    With “extension interface” you mean KParts::ReadOnlyPart and KParts::BrowserExtension? They are nice, but limited (e.g. you may want to access DOM in WebKit).

    More importantly however, the fact that the the khtml kpart plugins cannot be used by kwebkitpart is the plugins problem because they were designed to support only khtml, which at the time they were created was the only rendering engine around in KDE land.

    Partly, you cannot write a scripted plugin for kdewebkit, and that is not the plugin’s fault. And the more common interfaces the better it is. What I wanted to say: that certainly does not attract plugin developers, if there is a (future) Rekonq plugin system, and a KParts plugin system maybe needing multiple implementations for KHTML and WebKit.

    However, saying that KHTML plugins should be used by WebKit is really incomprehensible since Webkit is a completely separate project than KDE and KDE does not implement its own version of WebKit. As already stated above it uses QtWebKit through a thin integration wrapper library called kdewebkit.

    Sometimes I say “WebKit” and mean “WebKit in the context of Konqueror”, ie. “kdewebkit”. I thought the context would be obvious (even the selection in the view menu of Konqueror simply calls it WebKit ;)).

    More elaborated answer tomorrok, I am tired…

  29. Dawit Alemayehu Says:

    > With “extension interface” you mean KParts::ReadOnlyPart and
    > KParts::BrowserExtension? They are nice, but limited (e.g. you may want to
    > access DOM in WebKit

    Well that is no longer true. As of KDE 4.6 there is a KParts::HtmlExtension for that you can use to query the DOM through the CSS query language, KParts::TextExtension for retrieving text selection in plain or html format and KParts::FileInfoExtension for retrieving file information which is used by the kget plugin. More can be added as needed to support missing functionality other plugins might need, but the generic interfaces are much more plausible than the lonely KParts::BrowserExtension.

    Don’t get me wrong. There are lots of flaws in QtWebKit. For example, the point you brought up about wanting “KDE style widgets” is correct. Unfortunately QtWebKit by design does not use native widgets for HTML input elements such as buttons. Instead, it draws these controls. The unintended consequence of that of course is it prevents any “integration” for input elements. We cannot use native KDE input widgets such as KTextEdit and get spell check and form completion support for free. Of course, all of that would have been less of an issue, if only spell checking and form completion support were already in there.

    As far as scriptable plugins are concerned, I am waiting to see how the reKonq developers plan to implement the Chrome plugins. If they are successful, we can perhaps suck that into kdewebkit and make it available to everyone and anyone that uses kdewebkit. That would be a huge improvement over the current plugin mechanism we have in place. Again, all of this stuff probably comes down to human power, which we unfortunately do not have enough supply of.

  30. The User Says:

    Well that is no longer true.

    Good news. :) Nice that there are those kind of interfaces, thanks. I see, for Python there seems to be support, but not for Ruby, that is probably the reason I did not notice it.

    The unintended consequence of that of course is it prevents any “integration” for input elements.

    I supposed it would be hard. You do not see any proper way how it could be done?

    Again, all of this stuff probably comes down to human power, which we unfortunately do not have enough supply of.

    Not olny, also lack of technology reusage. If Rekonq would reuse KParts technology (not only for Okular integration), we would get HTML plugin integration, nice address bar etc. everywhere for free, and they would not have to reinvent the wheel for everything.

  31. Andrea Diamantini Says:

    Sorry, I don’t see the point of using kparts in rekonq and having our address bar in konqueror for free. Do you think konqueror addressbar is integrated in one browsing (k)part?

  32. The User Says:

    Redundance is bad, missing integration is bad. Konqueror would have benefited, and Rekonq would have benefited from history storage etc. I do not see your point why it should be good if Rekonq is doing everything their own, ungeneric way.

    Do you think konqueror addressbar is integrated in one browsing (k)part?

    What do you mean? What is the conceptual difference? Rekonq’s address bar is fancier etc., but they are both – address bars.

  33. Dawit A. Says:

    I supposed it would be hard. You do not see any proper way how it could be done?

    No. It was a design decision made upstream in QtWebKit and unless it is changed there, which I highly doubt, it will, then there is nothing that can be done about it.

    What do you mean? What is the conceptual difference? Rekonq’s address bar is fancier etc., but they are both – address bars.

    Ahhh… Konqueror’s address bar is hard coded into konqueror just like reKonq’s or any other application’s. Just because you can get “hide it” through its XMLGui configuration, does not mean you can replace it with something else. Unlike the searchbar, the location bar is not a optional plugin. It is a hard coded in Konqueror’s source code.

    Moreover, since the locationbar is part of Konqueror’s mainwindow and not the KPart widget, even if reKonq was somehow a KPart widget like kwebkitpart, the location bar that is part of its application window would still not be available in Konqueror. IOW, the locationbar is not something that is shared ; so your comments regarding that do not make sense either. In case this is not clear, Konqueror embeds the DolphinPart for file management handlig, but you never see Dolphin’s breadcrumb edit in Konqueror, do you ?

  34. The User Says:

    IOW, the locationbar is not something that is shared ; so your comments regarding that do not make sense either. In case this is not clear, Konqueror embeds the DolphinPart for file management handlig, but you never see Dolphin’s breadcrumb edit in Konqueror, do you ?

    I doubt it would be that difficult to make them exchangable, and that is not a good reason for all the redundance introduced by Rekonq (do not tell me Rekonq could store history better than Konqueror).

    And look at Rekonq’s WebPage source and tell me if it is dirty or not. Obvoiusly, it is, it uses distinction of cases where it is not necessary, where it just breaks the architecture of KParts, that is wrong API usage just to make it “an own browser” in my opinion. There is a reimplementation of Adblock, there is a reimplementation of history model, there is copied code, that should be good?

  35. Dawit A Says:

    I doubt it would be that difficult to make them exchangable, and that is not a good reason for all the redundance introduced by Rekonq (do not tell me Rekonq could store history better than Konqueror).

    That is exactly what I am saying. How Konqueror stores history is very specific to Konqueror. It does not share history with its own existing cousin Dolphin. Why would you expect any different from reKonq ? I do not get that. Konqueror is a universal viewer and as such has needs that are specific and apply only to it. If kwebkitpart did not share the history with khtml, I can understand why your comment makes sense. Otherwise, I do not understand what you expect reKonq to do about this. In fact, what kwebkitpart does to make it possible to emulate all of the settings of khtml is what should be considered a violation of such design. But there is nothing kwebkitpart can do short of linking against another rendering engine just to read configuration information.

    And look at Rekonq’s WebPage source and tell me if it is dirty or not. Obviously, it is, it uses distinction of cases where it is not necessary, where it just breaks the architecture of KParts, that is wrong API usage just to make it “an own browser” in my opinion.

    I have looked at reKonq’s re-implementation of KWebPage and I have no clue what you meant by it being “dirty”. And I most definitely do not understand how it breaks “the architecture of KParts” and the thing about wrong API usage?? If we take your argument on its face value, then the same thing can be said about both KWebPage in kdewebkit. It uses certain KPart components while it is not a KPart itself. Heck, you can also argue that the API wrapper should have been a part.

    There is a re-implementation of Adblock, there is a re-implementation of history model, there is copied code, that should be good?

    Portions of the adblock code is copied into kwebkitpart too. The reason for that is Adblock is not pure KPart plugin. Important portions of it are part of khtml’s code base. So how exactly are others apps or libraries supposed to do in that case short of linking against khtml ? Like I stated before, the problem of KPart plugin reuse mostly stems from the fact that all those plugins predate the availability of alternative rendering engines in KDE. As such no one took care to ensure they were abstracted well enough so they can used from other parts. This is what the additional KPart extensions that were added for KDE 4.6 meant to address. Regardless, reKonq becoming a KPart would not have solved either one of the points you are arguing about here.

  36. The User Says:

    I do not get that. Konqueror is a universal viewer and as such has needs that are specific and apply only to it.

    Okular is the universal viewer. And could you explain me, what is specific about its history data? If there as a separate Dolphin history storage that does not make it better, that makes it worse. Even if there are real differences, that does not justify the separate implementations, that would mean that there is not enough abstraction in the implementation.

    If we take your argument on its face value, then the same thing can be said about both KWebPage in kdewebkit. It uses certain KPart components while it is not a KPart itself.

    It does not use KPart to open PDF or anything like that. In that implementation there are two dispatches while the second one would have been enough.

    Like I stated before, the problem of KPart plugin reuse mostly stems from the fact that all those plugins predate the availability of alternative rendering engines in KDE. As such no one took care to ensure they were abstracted well enough so they can used from other parts.

    Copying is not a solution.

    Regardless, reKonq becoming a KPart would not have solved either one of the points you are arguing about here.

    I do not expect it to be a separate application at all. It should not be a KPart, that does not make sense, but it should be multiple KParts and GUI extensions.

  37. Dawit A. Says:

    Okular is the universal viewer. And could you explain me, what is specific about its history data? If there as a separate Dolphin history storage that does not make it better, that makes it worse. Even if there are real differences, that does not justify the separate implementations, that would mean that there is not enough abstraction in the implementation.

    #1. okular is not a universal viewer. It is a universal document viewer. There is a big difference there. Try opening a web page of a directory listing with okular and see what happens! Now tell me why web page addresses that do not point to a document or directory address would be of use to okular ?

    #2. I have no idea what you think history storage means here but the API to save the information is part of KPart ; so all KPart applications share it. However, how they save history information is completely left upto them. Guess what ? Most of them choose to save the information the way it makes sense to them. And hence the data can never be shared. Unless of course you are kwebkitpart and you go out of your way to emulate your grandfather.

    Anyways, reKonq will never be a KPart because that is what its developers chose. It is their right and since there are more than one successful browser in all the major platforms whether or not the browsing experience in KDE improves depends only on the amount of work that is put to improve said technology. Not the fallacy of combining projects into one to solve a problem. It won’t. The large part of the browsing experience remains in the rendering engines, and the most promising engine is an upstream project…

  38. The User Says:

    #1. okular is not a universal viewer. It is a universal document viewer.

    But Konqueror is not just a viewer. However, that is just about words. Could you explain me what that universal viewer should be good for if neither file browsing nor web browsing are state-of-the-art? It is still kinda useful, but it cannot be awesome although there would be the requirements to make it awesome within the same community using the same basic libraries etc.

    #2. I have no idea what you think history storage means here[…] Most of them choose to save the information the way it makes sense to them.

    rekonq/history/*
    kde-baseapps/konqueror/src/history*
    Tell me, what are the different needs? It is just about saving and displaying URLs. Even if there would be kinda different needs it would be a better solution to add some abstraction to fix that, but there is not, it is just the same, but Rekonq-devs wanted to have their own implementation. That is bad architecture and bad strategy.

    The large part of the browsing experience remains in the rendering engines, and the most promising engine is an upstream project…

    But it is not just about the rendering engine! It is about GUI, flexibility, plugins, and of course also clean code.

    Anyways, reKonq will never be a KPart because that is what its developers chose. It is their right[…]

    But it is bad, I am criticising that. Code reusage is good, rewriting boring code without architectural flaws is bad. Look at KDEPIM/Akonadi, look at Plasma, they are doing great jobs, they add abstraction, they allow code reusage and integration of their work from everywhere. KXmlGui and KParts where great inventions, too, but now they are ceasing, they are not used for new (partly) innovative projects, abstraction gets removed, reusage gets reduced. It is not about if they are allowed to do that, it is about what is good and what is bad.

Leave a Reply

XHTML: Use <blockquote cite="name"> for quotations, <pre lang="text    ∨ cpp-qt ∨ cpp ∨ bash ∨ other language"> for code, [latex] for formulas and <em> for em. Contact me if the comment does not get published, it may have accidentally been marked as spam.

Anti-Spam Quiz: