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 ;)


I can honestly say I've been using Konqueror as file manager and web browser for many years, with strong preferences over dolphin as a file manager. It just works the way I like my system to operate. I like the plugins and the feature set that accompany this component. One of the features I use frequently is to archive a web page (.war).

Without dragging on, the point being made is simple. Linux is about choice first and foremost. Just because a certain type of user doesn't value Konqueror, that does not mean that another type of user doesn't consider it valuable. My distro of choice comes with dolphin as the default manager and konqueror isn't even installed. It's one of the first things I change . I've been using Linux ever since the first inception of KDE, and I'm set in my ways. It's not that I'm against change, but not simply for the sake of change. It has to be a significant improvement or a necessity first.

I'm sure you didn't post this topic here to be drowned in a deluge of complaints. What should be obvious is that, if you're saying you haven't had time to pay attention to Konqueror, and you're saying that you're looking for a new maintainer, then complaining to you about what needs to be fixed is a rather mute issue. From experience, I know that projects of this magnitude find new maintainers; it's just a matter of time. While I'm skilled with Linux and fairly adept with shell scripting, I'm far from even a mediocre programmer, thus, I can't offer to take over the project. Abandonware is a little bit too much of a windows world term for my liking. The "Comix" project was abandoned, picked up, abandoned again, then picked up and rewritten from scratch by another developer into the "mComix" project.

I just wanted you to know your work on the project thus far has been appreciated, and deciding it's time to seek a new maintainer is the right choice to make. Two thumbs up!

By Rick at Sun, 08/31/2014 - 05:17

Thanks for the work you have put into this project! I have used konqueror a lot over the years and are very happy and thankful for the great software in the KDE ecosystem.

Now I have not used konqueror for any file management since dolphin appeared and for web browsing I often turn to other alternatives as well. I like the attempt to brain storm a new vision for konqueror as a "hand off", but I must ask one thing.

What is the state of webbrowsing in KDE these days? I kind of got the feeling Rekonq was some attempt to do a Konqueror-ng, was I mistaken about that?

By Andreas Davour at Tue, 08/19/2014 - 10:20

Rekonq is web-browsing only. And it shares the same web engine as konqueror anyway (kwebkit).

This still leaves room for the "universal viewer" konqueror (webbrowsing + file management + document viewing).

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

Thanks for clearing that up, dfaure!

By Andreas Davour at Tue, 08/19/2014 - 14:58

Thanks for all your work and efforts! I love Konqueror, which is by far my favourite KDE application. Although Dolphin has some nice features, I find it barely usable as a file manager: two panels is far from being enough for me (I seldom use less than three panels when I use Konqueror as a file manager). And why open a new application in order to read a document? Besides, I want to be able to read a PDF file (some manual, for instance) and browse a technical website on the same subject in the same tab. As far as I know, only Konqueror makes it possible. Yes, it is a wonderful programme!
When I have to use other browsers (mostly at work, or on friends’ computers), I find it almost unbearable not to be able to manage files in them — no wonder that so many people’s Download directory is such a mess! And Konqueror is so flexible and offers so many configuration possibilities. I love the web shortcuts, among many other things!
I miss a feature from Konqueror 3, though: the direct audio preview of sound files, which is very useful when you have to tag audio files ripped weeks or months before (CDDB is very bad for classical music, with many informations lacking and many being inaccurate, so I prefer not to use it).

I wish I could help, but unfortunately I am no developer, just some (happy) user.

By Thomas Savary at Tue, 08/19/2014 - 16:16

My experience with KDE would be significantly diminished without konqueror. It is the only browser I know that:
- seamlessly integrates with KDE themes
- can be minimal (i.e. toolbars, menubars, tabs etc. turned off)
- integrates with the file manager seamlessly (because it *is* the file manager)

rekonq is nice but nothing comes close to a window filled with the web page.

Unfortunately I cannot contribute as pick-a-lame-excuse :(.

By Colin Yates at Thu, 12/11/2014 - 16:19

What's the current status of the search for a new mantainer? I really love Konqueror and I would hate to see it disappear. If nobody else has offered to port it to KF5, I'm willing to attempt to do it (although I'm not sure my C++ skills are good enough). Of course, if someone else is already doing the port, I'm willing to help him.

Please, let me know how things currently stand.

By Stefano at Sun, 12/14/2014 - 09:47