Konqueror is looking for a maintainer Submitted by Submitted by David Faure 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)

(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.

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.

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

location. 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".

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

It appears embedded into the main view Step 3: Click on "previous" or "next" buttons which appear on top of the

image. [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

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

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)

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. Mockup 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 }

* { 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

http://oversip.net/public/konqueror-mockup/ 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 ;)