Konqueror is looking for a maintainer

For quite some time now (OK, many years...) I haven't had time for Konqueror.
KDE Frameworks 5 and Qt 5 have kept me quite busy.

It's time to face the facts: Konqueror needs a new maintainer.

This is a good time to publish the thoughts we had many years ago about a possible new GUI for Konqueror.

Kévin Ottens, Nuno Pinheiro and myself had a meeting (at some Akademy, many years ago) where we thought about how Konqueror's GUI could be improved to be cleaner and more intuitive, while keeping the idea of Konqueror being the universal navigator, i.e. the swiss-army knife that includes file management, web browsing, document viewing, and more. This is what makes it different from rekonq and dolphin, for instance.

So, if you're interested in Konqueror and you want to keep it alive, please consider taking over its development; whether the ideas below sound good to you or not. This is no obligation, just a brain-storming that could prove useful for a future redesign of Konqueror's UI.

The first task is much simpler anyway: it needs to be ported to KF 5 and Qt 5.

1) Definition of the target user group:

  • Users who prefer to stay within the same application as much as possible
    (which includes both those who don't like major changes, and those
    who prefer a single window over new windows and apps being started
    for every type of document)
  • All web users (from one webpage to many at the same time).
  • Heavy content consumers (local and remote)

2) Workflow diagrams

2.1) Navigation to a document in a known location
Pre-requisite: a "starting point" selector is available

  • Step 1: choosing a starting point
  • Step 2: navigating to that starting point in the main view
  • Step 3: when reaching the document, its contents are displayed, still in the main view.
  • Optional step 4: for edit the document, an easily accessible button is available.

2.2) File management during navigation
During step 2 above, the user might notice files that need renaming, deleting,
moving, etc. Moving and copying is especially interesting, we made a list of
the possible ways to do that, and kept:
Copy/Paste, Splitted views, Dropping on a tab, Dropping on a breadcrumb
while discarding the sidebar folder tree.

This also led to a new concept in addition, for the following workflow:

  • Step 1: Select files
  • Step 2: Trigger cut or copy action
  • Step 3: A "clipboard" window appears on the side of the current window,
    showing an icon for the copied files.
  • Optional step 4: drag more files to the clipboard, even from other
    locations, which creates more "groups of files" icons in the clipboard.
  • Step 5: Navigate to the target location
  • Step 6: Trigger the paste action to paste all the files from the clipboard,
    or drag individual groups of files from the clipboard to the intended

This has the advantage that no splitting or sidebar is necessary within konqueror.
The clipboard window (inspired by the concept of a shelf in NeXT) offers a temporary
area for holding the files while we are moving from the source location to the
target location within the main view.
Note that the clipboard would have a visible label "Copy" or "Move", depending
on the action in step 2 which made it appear. This makes it clear that the files
dropped in step 4 will also be copied or moved, and saves asking the user again
at every drop in step 4, as well as asking in the final drop in step 6.

This concept could even be made KDE-wide; whenever the user uses "copy" or "cut" in
an application, the clipboard window would appear (at a fixed location, in this idea,
not attached to the application window) and an icon for the copied or cut data would
appear in the clipboard window.
On the other hand it might be annoying when using a quick Ctrl+C Ctrl+V in a word
processor, so it should probably not appear automatically in most applications.
But for files it would be nice if it appeared automatically, because this makes the
feature very easy to discover, compared to a "Tools / Show Clipboard Window" that
nobody would use.
(Another issue is that the workspace-global window might appear on top of the
window where you wanted to copy or paste... this problem doesn't happen in the
initial idea of attaching to the konqueror window (a bit like a Mac slide panel
or whatever it's called). It could appear on whichever side there is room for it,
or the window could move to make room for it).

The nice thing is that this is actually very easy to implement, it fits exactly the
QMimeData/QClipboard concepts. But let's put this aside for now, it's a bit separate
from the main idea of this document. It was mostly a way to provide a solution for
the loss of sidebar folder tree, currently used by people who move files to other
directories. Meanwhile another solution for these users is to split and switch to
"tree view" mode, which konqueror would offer again (like the file dialog does,
and unlike dolphin). (However that's a tree of files and dirs, not a tree of dirs).

2.3) Previewing many files from the same directory

For fast multiple previews, konqueror currently has a very hidden but very nice
feature: split+link+lock. Since it's impossible to discover, these features would
be removed from the GUI, and instead a single action would be offered for these
three steps. A good name still has to be found, something like "Splitted Preview".
The workflow would be:

  • Step 1: Navigate to directory
  • Step 2: Trigger "Splitted preview" action.
    The window is split vertically, and the right view shows a single label
    like "click on files to preview them here".
  • Step 3: Click on a file in the left view
    The file is embedded into the right view.

Repeat step 3 as many times as needed.
This is a single-click preview, faster than waiting for tooltips or having to
navigate back after each file being opened.

For images especially we would like to also provide the following workflow:

  • Step 1: Navigate to directory
  • Step 2: Click on first image
    It appears embedded into the main view
  • Step 3: Click on "previous" or "next" buttons which appear on top of the

[Technically, since gwenview has this feature already, this is just a matter
of making it available in gwenview part]

Note that the first workflow is more generic since the user can use it to look
into text documents, html pages, pdfs, or anything else, not only images.

2.4) Internet search (not only google, but also wikipedia etc)

Pre-requisite: a "starting point" selector is available

  • Step 1: Choose starting point "web"
    Search form appears in main view
  • Step 2: Choose type of search (if different from the default one)
  • Step 3: Type search
  • Step 4: Resulting webpage appears in main view

2.5) Local document search using non-spatial criterias (nepomuk)

Pre-requisite: a "starting point" selector is available

  • Step 1: Choose starting point "local search"
    Search form appears in main view
  • Step 2: Fill in search form
  • Step 3: Results appear in main view

2.6) Search using time criteria (history)

Use case: I want to open again a location that I know I visited recently,
but I forgot the exact URL for it. E.g. after clicking on a link on irc.

Pre-requisite: a "starting point" selector is available

  • Step 1: Choose starting point "history".
    A list of recently visited locations appears in main view,
    sorted by time of last visit (most recent on top)
  • Step 2: Choose location (direct click, or using as-you-type filtering)
  • Step 3: Location is loaded in main view

General idea

It appears that all the navigation can be done in the main view, if "starting points"
are easily made available. The sidebar would therefore be removed. Most of its current
modules are covered above. The others do not appear to be useful.
We still have to check whether web sidebars still make sense or whether that
concept died.

The following four starting points would be used for navigation:

  • Places (basically: directories, local or remote)
  • Document search [how to say that in one word?]
  • Web
  • History

The current "Home" button would be replaced with four buttons, for these four starting points.
When clicking on one of them, the main view would show the corresponding part, so there is
room to make things look nice:

- "Places" would show large icons, for directories (somewhat similar to the
places model, but in two dimensions and with "groups" separated by a line, like the
grouped view in dolphin)

- "Document search" would be the opportunity for baloo to provide a
full form for searching.

- "Web" would show the web-search-lineedit (from the current konqueror), as
well as the list of bookmarks, with a lineedit filter.

- "History": as described before, list of recent locations ordered by time.


In konqueror.ui, you will find a konqueror window, shown in "wireframe" style so that nobody comments on colors and pixels, as recommended by Nuno.
Note how easily this can be done: just paste this line into the styleSheet property of the toplevel widget:
QLabel { border: none }\n * { border: 1px solid black; background: white }
This could probably be refined to remove some double borders, but it works good enough for now.

In this mockup window, you will find multiple tabs, to show the various things
one can do. First: one tab per "starting point": Places, Search, Web, History.
Then one tab per location where the user could end up, after some navigation:

  • a dolphinpart directory view ("dfaure")
  • a web page ("KDE - Experience Freedom!")
  • a PDF document ("foo.pdf"), using okularpart
  • an image ("image.jpg"), using gwenviewpart

The interesting part of this mockup is that the menu items in the main
konqueror menu and the toolbar buttons in the main toolbar always stay the same, whatever the
current part is. All the part-specific actions are shown in a toolbar
inside the part, with credits for the idea to a mockup which used to be but no longer exists.
Where the mockup currently uses an ugly combobox, it would
obviously be a toolbar button with a dropdown menu, like the right-most button in the
file dialog.
It's just that this can't be added in Qt Designer with the default set of widgets.

The button saying [View Properties] would only have the tool icon, like the
equivalent button in the file dialog.
For the other buttons, it is yet to be decided if they should have icon-only
or icon-and text, which is definitely more discoverable but takes more space.

The available actions for each part have been taken from the current parts mentioned above.
The case of okularpart is still a problem though, we didn't find out how to finish the
grouping of actions so that the toolbar isn't too crowded. However the concept seems to
work OK for the other parts, okularpart is really the worst one in terms of the number
of actions :)

Anyhow - if you want to help port Konqueror to KF5, this is a good opportunity to start getting to know its code.
If you're not sure you're ready for the big step of becoming maintainer, you can at least start with porting it and decide later.
Join kde-frameworks-devel (for KF5 porting questions or patches) and kfm-devel (for general konqueror / dolphin discussions) (but CC me, I stopped monitoring kfm-devel since the only activity was about dolphin...). If this blog leads to new developers, maybe we could create a konqueror-devel mailing-list finally ;)


the sidebar folder tree, the ability to quickly switch between hierarchy trees and interact with them, is the main reason i still use konqueror, dophins places are useless for that. I also usualy drag instead of cut /copy.
Turning konqueror into a dolphin with preview and webbrowser would be sad. And left me standed with 4.x.
Be careful defining target users for the supposed advaced tools or you get pretty looking Software that's useless. Most Users will use the simple tools and the advanced users rarely match one or two simple target users.

By Arne at Sat, 08/16/2014 - 21:37

First of all: I really like the ideas & mockup in this blog post :)
One thing however worries me. The term "Previewing" sounds like the "split+link+lock" feature is intended only for quick previews of files, while for me it is often the most efficient method to browse through multiple source files or search for information which is split around multiple pdfs.
Long story short: i think the kparts-toolbar should be shown only on demand (and maybe rather on the right side instead of on top) - otherwise it would use to much of the user interface and inhibit my workflow (and surely that of others as well).
As for developing konqueror: i am interested in contributing, but i don't think i can spend many ressources on it :/.

By tarbos at Sun, 08/17/2014 - 10:43

I'm interested in helping/getting involved with the port. Long-time enterprise app developer/architect/tech manager, using linux for a few years (now exclusively openSUSE Factory) and currently eating the KF5/Plasma5 dogfood (it's most excellent!). Not really interested in being a maintainer at this point, but who knows.

I have no dev experience in KDE, where is best to start? Right now, I'm set up with all of the GCC and Monodevelop and python tools from openSUSE Factory. I know enough C++ to get myself in a little trouble.

By Mike Noe at Sun, 08/17/2014 - 16:43

What's the status libkonq? That's used actively by quite a few other projects. is that still considered maintained?

By David Edmundson at Sun, 08/17/2014 - 20:26

Work has been ongoing to distribute the contents of libkonq over other frameworks (mostly kio so far), at least the parts anyone outside Konq (Dolphin, Folder View) uses. Progress is quite good. plasma-desktop's internal copy of libkonq provides a nice overview of what's left to be deduplicated, and has shrunken much lately. One day soon(?) it will be gone.

By eike hein at Sun, 08/17/2014 - 21:10

Sounds like fun, Lets do this!

By kusuriya at Mon, 08/18/2014 - 15:53

You must be on crack. You're announcing that konqueror is without maintainer, and think it's a good idea to post a brainstormed TODO list from years ago that amounts to a complete rewrite? What the hell. What konqueror needs is some critical bug fixing, throwing out the khtml backend, making the webkit backend not crash and freeze all the time, and fix other outstanding issues. Not rewrite everything and confuse the user with UI changes. Frankly, a user who wants that at this point would probably be better off to switch to a different software. Yep, you must be on crack.

I personally don't use konqueror for anything else than file browsing. Actually, I'm using firefox for github and a bunch of other sites, because konqueror is too slow for them. But I don't use the konqueror swiss army knife features, except for opening PDFs. I wish I could help the konqueror project, but I hate C++ and Qt to death, and I already have a healthy fork of a certain semi-dead open source project. I wish you good luck.

By A concerned user at Mon, 08/18/2014 - 19:52

Thank you for your nice words, which only contribute to my loss of motivation for maintaining Konqueror.

This blog is mostly resulting in user complaints or suggestions. Great. Exactly NOT the point.
The point was to find a new maintainer, and guess what - some suggested GUI changes (given that some users complain that the GUI is too crowded) might appeal more to a potential maintainer than just "there are 2000 bugs to fix"....

By David Faure at Tue, 08/19/2014 - 08:13

It's good that you're showing that you're open to larger changes, i.e. a new maintainer can probably really clean up stuff, instead of being forced to keep around old crap. But I don't think an old TODO list is very appealing. Rather, it's depressing. Nobody likes old TODO lists. They're basically a monument of previous failures, since the goals were never reached after all this years, and just lead to stalled development. Sorry if this sounds a bit harsh, but since you've already given up, why hold back.

A slightly more successful strategy might be giving regular contributors more access? Opening up to changes that were previously blocked. I don't know if you have such contributors, though. In fact I don't have any clue about konqueror or KDE development, so what I'm saying is probably rude and misguided, but comment sections allow for a dialogue, after all.

It's possible that I'm actually overestimating this situation, but to me it sure sounds like konqueror is to be abandonware from now on. Meaning this software is probably dead. A bit sad. I'll keep using it until more than 80% of all sites I regularly use are unusable. Farewell.


What did you expect?

By A concerned user at Tue, 08/19/2014 - 17:48

This is definitely not an old TODO list. The old TODO list is somewhere else, and mostly in bugzilla. Old TODO list are usually a long collection of bugs and unrelated things to fix.

This, however, is one coherent proposal for a new GUI, which we didn't publish at the time because we didn't want users to take it as a false promise - given that we weren't sure we'd have the time to implement it (looks like we were right....).

The contributors, if there were any, would have plenty of access; you're guessing wrong here, IMHO.

Dead: not necessarily. It has been dead for some time because I didn't face the fact that it needed a new maintainer.
If someone steps up, then it won't be dead, on the contrary, it will be more active than before.
This is exactly what happened to Dolphin. Peter stepped out, Frank stepped in, and Dolphin didn't die. The shout out by Peter for a new maintainer didn't mean Dolphin was abandonware, on the contrary, that's what saved it. I'm trying to do the same here.

> What did you expect?

One or more volunteers for working on Konqueror....

By David Faure at Tue, 08/19/2014 - 19:41