KDE's Konqueror Is In Need Of A New Maintainer

[Sho_]

Epiphany is being well-maintained and evolving with WebKit2.

Konqueror has spent the past 5 years denying WebKit and being garbage.

Comparing these two is truly pathetic. Epiphany has corporate sponsorship and development. The WebKit 2 development port for GTK+ is current and GNOME is using its WebKit backend throughout GNOME 3.12+.

Sigh.

Folks, you don't even really know what Konqueror really is, and are spending a lot of effort fighting about this or that, none of which really applies.

Let's recap:

* The KDE application platform contains a component model framework known as KParts. KParts, together with related technologies like KXMLGUI, allow composing applications in interesting ways. For example, KParts is how Dolphin can embed a terminal emulator docker powered by Konsole, how Kontact embeds KMail and KOrganizer, and to provide a first example involving Konqueror, how Konqueror can display PDFs by embedding Okular.

* But it goes a little further than that. What Konqueror actually is is essentially a generic shell that loads KParts, which can be shown in various configurations, such as tabs or splits. Such configurations can be saved as profiles, and loaded later. Everything inside a Konqueror viewport is actually a KPart, usually addressed by an URL, and the KPart is chosen by the data type of the URL: A filesystem directory (using Dolphin's KPart as of KDE 4). A website (more on a moment). A PDF (Okular's KPart). A text file (Kate's KPart). Numerous others, and infinitely extensible.

* When comes specifically to viewing websites in Konqueror, there's two prominent KParts: The KHTML KPart, and the WebKit KPart (trivia: there used to be a Gecko KPart at one point, long ago). Obviously the WebKit KPart had "corporate sponsorship and development" as well, on multiple levels (the companies contributing to WebKit; the companies contributing to Qt's backend for WebKit; and in fact WebKit KPart development by way of Rekonq development, which was for a time corporate-sponsored as well).

* Konqueror is not the only user of these KParts. Apps like KHelpCenter and other use them as well.

Continueing to maintain/develop Konqueror is thus somewhat orthogonal to this whole web browser topic, and even file management - except for how the Konqueror shell (that is, say, the menu structure, the toolbar structure, general view management facilities) affects the user experience of either inside Konqueror.

Now, all this makes Konqueror a bit of an odd animal. The complexity of its UI is fairly high, and task-specific UIs like Dolphin and Rekonq have overall proven move popular with users, is I think fair to say. On the hand, Konqueror still has its loyal fans. There's nothing quite like it anywhere else, and for some very specific use cases and work flows, it's tremendously powerful. Say, having a split arrangement that allows you to drag files from one split into a viewer in another split, and saving that arrangement as a profile for later reuse. It's advanced, it's niche - but then neither of those are evils per se.

[ssokolow]

I have to agree with Sho_.

In KDE 3.5.x, I did the vast majority of my work with Konqueror being used as a generic splittable, tabbable, KIO-backed KPart harness.

The ability to edit things in KatePart 4.x would have have made that 99% of my work if Konqueror 4.x's army of papercut bugs didn't exist. As is, that's one of the main things that drove me to LXDE when Trinity demonstrated that they lacked the manpower to update the KDE 3.x codebase to follow more modern FreeDesktop integration standards.

If I trusted my time-management abilities at all, I'd try my hand at fixing up Konqueror for 5.x and getting used to C++ along the way.

[AndrewGray]

Later konq

I am in agreement with the other comments. Ditch Konq. I have been using KDE for years now (recent XFCE convert). Dolphin is my favorite file manager and Filezilla can take care of the rest. Bring Dolphin cross-plat

[Sho_]

To follow on from what I wrote earlier, keep in mind that it implies Konqueror hasn't actually been a resource drain on anybody. As David writes in his blog post Konqueror-the-actual-application hasn't really seen much change in a long time, and as I tried to explain, the KPart components it loads are essentially all maintained elsewhere. That Konqueror allows one to view directories hasn't been a resource drain on Dolphin, for example, since Konqueror actually uses Dolphin's technology to show directories. Not even the KHTML KPart that has been the point of so much discussion here is actually a part of the Konqueror codebase that's the topic of David's blog post.

What I expect to happen is that some of those die-hard fans who rely on Konqueror's unique abilities will come out of the woodworks and keep it working. Those who had no interest in Konqueror lately likely will continue to find it uninteresting. Not much fuss, overall.

[Daktyl198]

Sigh...

That's... kind of awesome. I never knew that (I just figured it was a web browser/file manager combined). That definitely makes it seem like it could come back as something awesome if somebody actually took the time to bring it up to date (KF5, QT5, updated interface, etc). I know I would definitely try it out at the very least.

[liam]

This should be ditched. Along with Epiphany. Developer should be focusing on things actually going to be useful for end user. Just because it was in KDE4 or previous, no need for it in KDE5 era. Planned and new eco system should be made for KDE5

And rekonq! A browser is really hard to make, and we already have two great open source ones. If you want native-ish qt, create a qt backend to FF's toolkit (https://bugzilla.mozilla.org/show_bug.cgi?id=451129). From that metabug it looks like most of the work if done for qt5.

[magika]

And rekonq! A browser is really hard to make, and we already have two great open source ones. If you want native-ish qt, create a qt backend to FF's toolkit (https://bugzilla.mozilla.org/show_bug.cgi?id=451129). From that metabug it looks like most of the work if done for qt5.

What should I do if I dont like FF?

[Daktyl198]

And rekonq! A browser is really hard to make, and we already have two great open source ones. If you want native-ish qt, create a qt backend to FF's toolkit (https://bugzilla.mozilla.org/show_bug.cgi?id=451129). From that metabug it looks like most of the work if done for qt5.

"30581 commits behind mozilla:master"
Last commit: Feb 19th

I think it's safe to say they gave up. I would REALLY love a native Qt backend to Firefox though (even though I use a GTK desktop)

[liam]

What should I do if I dont like FF?

And what if you don't like webkit (including blink) based browsers either?

It probably depends on the reasons you don't like it.

[liam]

"30581 commits behind mozilla:master"
Last commit: Feb 19th

I think it's safe to say they gave up. I would REALLY love a native Qt backend to Firefox though (even though I use a GTK desktop)

Did you see the file date of the bug? It was six years ago. It needs a maintainer. It shouldn't be that hard as gtk3 is coming along nicely without any full time maintainers.
All of this assumes, of course, a desire for alternate browsers. If people are happy with safari-lite based webkit browsers (epiphany, and rekonq I think), that's fine.