Introducing Dolphin 2.0

During the last months I've been working on Dolphin 2.0 which is planned to get released with the 4.8 release of KDE Applications. Dolphin 2.0 will get a new "view-engine" that will have several improvements in comparison to the current version.

Well, what means "view-engine" in the scope of Dolphin? The view-engine is responsible for showing the directory content as icons and text. In a very simplified form it can be seen as the sum of Dolphin's "icons mode", "details mode" and "columns mode".

The current version 1.7 of Dolphin is based on Qt's Interview Framework. Regarding the quality of the Interview Framework I'd like to quote a Qt developer from the Qt Labs Itemviews - The Next Generation  article:

"Not surprising. If you are using Qt, chances are you are using the item views. And if you are using the item views, you are likely to have an opinion about them. While using these classes you may have even form the opinion that they are not exactly the most shining example of Qt quality framework and API design. Let’s just say that there is room for improvement, lots of room! The symptoms are clear: the framework is generally too slow, unstable and the API is difficult to use. A clear case of overly complex design."

Having worked with the Interview Framework during the last four years I fully agree to this (... and probably would not have phrased it as friendly as in this quote ;-)). As an alternative for the Interview Framework a research project called Itemviews-NG has been created. After comparing Itemviews-NG with the view-engines-related code from libmeegotouch and Qt-Components it was clear that currently for Dolphin the Itemviews-NG would be the best choice. So the new view-engine for Dolphin 2.0 is build on a (very) modified subset of Itemviews-NG. In the longterm (probably with Qt 5) it is planned to integrate Qt-Quick but this affects only a non-critical minor part of the view-engine and has not high priority at the moment.

So much talk about the new base of the view-engine, but which benefits get the users of Dolphin by this?

Improved Performance

The new view-engine has been tested on a computer with a very slow hard-disk and developed with corner-cases in mind where the current view-engine had serious performance troubles. Now switching view-modes, zooming, resizing, ... is done with nearly no delay no matter how many items a directory has.

Unclipped Filenames

With Qt's Interview Framework having dynamic item-heights the way Dolphin required it was not possible. As workaround Dolphin used a fixed grid-size where the user could configure the maximum number of textlines. No matter which value has been used: Either the item-height got too large or the text got clipped like this:

Like most other filemanagers now also Dolphin is able to have dynamic item-sizes:

As a side-effect Dolphin 2.0 wastes less space and can show more items in parallel when using the same icon-size as the current Dolphin version.

Nonrectangular Item Boundaries

The Interview Framework only supports rectangular item boundaries. This means that moving the mouse above the position marked as red spot...

... results already in hovering the whole item:

The new view-engine provides optimized non-rectangular item boundaries:

So the hovering only takes place when the mouse pointer is above the the icon or text like in KDE 3 (Note that the look of the hovering is just a prototype and might change)

Grouping Support For All View Modes

Currently the "grouping" feature is only supported for the icons mode but will be available for all view-modes in Dolphin 2.0. I could not provide a screenshot yet as the code for grouping is still in a very early alpha-stage. In opposite to the current version of Dolphin grouping will not slow down the performance at all.

Animated Transitions

At the moment when removing or inserting items, changing the zoom-level or resizing the window the item-positions change magically from the original position to the new position. This sometimes makes it tricky for users to follow the new location of the items. With Dolphin 2.0 the layout-engine is fast enough to make those transitions animated. I don't like animations that slow-down the usage of an application so I took care to make them fast and unobtrusive.

From a developers point of view the new engine simplifies the maintenance a lot and lowers the barrier for developers to contribute patches for Dolphin. The code has been pushed to master today. Please note that the code is in an early alpha-stage and although the most tricky parts have been implemented already very basic things like drag and drop or selections have not been pushed yet. Those things are rather trivial to implement but it is still a lot of work and takes some time to have back the original feature-set. But I'm confident that everything will be ready until the 4.8 release of KDE Applications and hope that the new view-engine will justify the 2.0 version number :-)

Menu Bars

The menu bar has always been a kind of "holy grail" of user interface elements for me. It contains all application commands and allows the user to discover the application capabilies and to learn the keyboard shortcuts. Often used commands are placed into the toolbar for faster access.

I did no scientific research about this, but I think first it was Microsoft with Windows Vista which started to put the menu bar into question for some applications:

• The ribbon replaced the traditional menu bar for their office suite.
• The menu bar is hidden per default in the Internet Explorer and the Windows Explorer. To still be able accessing all commands a kind of menu-button has been added to the toolbar.

Until I tried those applications I've been a strong opponent of those "menu bar violations". But after working a while with both approaches it seems that ribbons work very well for applications with a huge number of commands. I'm not sure whether the Internet Explorer or Google Chrome has been the first browser without menu bar, but as user of Chrome since around two years I was surprised that I never missed the menu bar and liked the well-arranged menu button.

I got the impression that the menu button as replacement works well for applications with quite less commands. In the meantime even Firefox 4 has switched to a default setup where no menu bar is shown; so I asked myself whether this might be an option for Dolphin and simply gave it a try. Since the release of Dolphin with 4.5 I try to strive for a cleaner and less cluttered default setup and now with having no menu bar I think the default setup is quite OK [1]:

It gets move obvious when comparing this with the default setup in 4.5:

Before the complaints "I want my menu bar back" start: Of course it is possible to enable the traditional menu bar :-)

Back to the new default setup of Dolphin. Beside the missing menu bar a lot of smaller updates have been done too:

• The Information Panel on the right is hidden.
• Toolbar items where the icon is sufficient for knowing the command don't have a text. By the way: In 4.7 this can be changed by a simple right-click.
• If the Places Panel is shown (like in both screenshots on the left) the "places selector" left from the Home > Pictures > Wallpapers path is hidden as it is duplicated functionality provided by the Places Panel.
• The Panels are "locked" per default like in Amarok and don't have a headline and two buttons.
• The search bar at the top right has been integrated into the view when executing the "Find" command.

Please note that those points just talk about default settings, no functionality has been taken away. For me it was - and still is - one of the main goals of Dolphin that it is easy and efficient to use without cutting too many features. I somehow like it that despite the added functionality during the last years this is not reflected in additional visual clutter. When looking back at the history of Dolphin screenshots it is somehow funny that for the upcoming 4.7 release Dolphin looks more similar to the old KDE 3 version than the 4.5 version :-)

[1] Please ignore the current look of the zoom-icons in the bottom-right of the screenshot. They will be replaced by a more decent version created by Nuno before 4.7.

Don't Crash When Reading Metadata

Each time a tooltip is shown in Dolphin or the Information Panel is enabled the metadata of a file must be retrieved:

History

When Dolphin has been written for KDE SC 3 this was straight forward: The class KFileMetaInfo has been used and the metadata was read in the context of the application within a short period of time. The fast retrieving was possible by using the hint KFileMetaInfo::Fastest that assured only up to 64 KByte of the file are read. This limit was sufficient for getting the most important metadata.

With the transition to KDE SC 4.0 KFileMetaInfo internally has been rewritten to use Strigi for getting the metadata. Like Dolphin and other components in KDE SC 4.0 also KFileMetaInfo and some metadata analyzers of Strigi had rough edges:

• The KFileMetaInfo::Fastest hint simply has been ignored. Hovering a big video file resulted in reading the whole file. As this reading has been done in the context of the application Dolphin was completely blocked during that period of time.
• When implementing the KFileMetaInfo::Fastest hint later it turned out that a few analyzers of Strigi simply decided to ignore this limit.
• To bypass a blocking Dolphin I've moved the reading of the metadata into a thread. This worked well until it turned out that some analyzers are not reentrant and yet-another-workaround was required to prevent two threads using a similar analyzer.
• Sebastian Trüg (although not responsible for this part of the code) investigated some cool work into KFileMetaInfo and found a way to let all Strigi analyzers respect the 64 KByte limit without changing the analyzers. I was very happy about this until it turned out that some analyzers crash when they get streams ending after 64 KByte...

Current State

The following things work now in KDE SC 4.6:

• The quality of a lot of Strigi analyzers has been improved during the last years and most of them work very reliable.
• The analyzers work fast by getting only 64 KByte to read.
• In comparison to KDE SC 3 the metadata is read in a custom thread which makes the user interface even more responsive.

Still open:

• Some analyzers are not reentrant. This is not a big showstopper as reading metadata in parallel is anyhow quite rare so the workaround to serialize the access won't result in a noticable slowdown from a users point of view.
• Some analyzers crash (and hence also Dolphin crashes).

From a users point of view it is not important whether Dolphin crashes because of an analyzer or because of an issue in the Dolphin code. Although most of the analyzers are very stable in the meantime it is still a pain for users that e.g. have some Powerpoint-files where the corresponding analyzer simply cannot scope with the 64 KByte limit.

KDE SC 4.7

I understand that writing metadata analyzers can be very tricky, but I was always convinced that not crashing when reading data is not difficult. But no matter whether I'm right or wrong with this assumption: Fact is that more than 3 years after the release of KDE SC 4.0 a few analyzers still crash and seem to be without maintainers that care about this.

Well, with KDE SC 4.7 those crashes will not result in crashing Dolphin anymore. I've moved the reading of the metadata into a custom process. If an analyzer crashes then the worst thing that happens is that no metadata is retrieved. The nice thing is that this also solves crashes for other components that read metadata: E.g. the fileproperties-dialog or overwrite-dialog of kdelibs. In retrospective I should have done this already a lot earlier, but the fact that the old approach worked so well in KDE SC 3 just made me resist to use a dedicated process for this. In the meantime I'm convinced that this approach is the right way in the longterm: It is simply risky if the stability of an application or some kdelibs-dialogs depend from external plugins where the quality of the code varies a lot.

So let's hope this is my last metadata-related post and that this topic is solved finally :-)

Update: Carsten Pfeiffer pointed out that in KDE 3 the KFileMetaInfo::Fastest hint did not restrict the parsing to 64 KByte. Instead it was up to the analyzers itself how they provide metadata that can be calculated cheaply. Too sad that most of the current Strigi analyzers don't support this.

Dropbox Integration for Dolphin

Thomas Richard contacted me recently and told me that he is working on a Dropbox integration for Dolphin. I tried the plugin already and it looks very promising - any testing would be very welcome!

Dolphin Improvements for KDE SC 4.6

As usual after the KDE feature freeze, I'd like to give an overview which improvements have been done in Dolphin for the next KDE SC.

Searching

I wrote already about the search improvements some months ago. In the meantime Sebastian Trüg has extended Nepomuk by facets and integrated them as "Filter Panel" into Dolphin:

The facets provide a very comfortable way for the user to shrink the number of search results. From a developers point of view those facets are a great thing too: It is easy to integrate them into an application. A lot of default facets are offered by Nepomuk, but it is also possible to embed custom facets.

As mentioned earlier Dolphin now allows to search for files even if Nepomuk is disabled, however the "Filter Panel" is a feature that only works in combination with Nepomuk and indexed files (at least for KDE SC 4.6).

Beside this improvements also other finetuning has been done for searching:

• The default view has been changed to show the path.
• The context menu allows to open the search result in a new tab or window.

Column View

Some long overdue improvements have been done for the column view:

• The column width can be changed by the user.
• The column width automatically is extended to the longest filename.
• Rubberband selection like in the icons-view and details-view is possible.
• Neighbor columns are always aligned in a way that it is possible to navigate through all columns without using the horizontal scrollbar.

Git Plugin

Sebastian Dörner and Johannes Steffen have implemented a Git plugin for Dolphin. It is part of the kdesdk-package.

Other Improvements

• Folders Panel: Improved automatic horizontal scrolling (can be disabled now too).
• Improved context-menu when no file is selected
• Multiple renaming: It is now possible to provide leading zeros if wanted (patch implemented by Matthias Fuchs)
• Service menus
• ... and of course a lot of bug fixes

Improved Service Menus

Dolphin and Konqueror offer so called "services-menus", which are shown when opening a context-menu of a file or directory. For example the context-menu for a JPG-file will show the menu entries "Convert to PNG", "Convert to GIF", ... - those entries are service-menus.

It is very easy to create a service-menu. In a nutshell it is just a text-file that allows to start an application with the selected files as parameters.

But service-menus also have some restrictions: Only the MIME-type is used as criteria to define which entries are shown. So it is not possible to show a service-menu only if e.g. exactly two files are selected or to create dynamic service-menus dependent on some meta-data of the selected files.

Sebastian Trüg has written an interface called KFileItemActionPlugin that bypasses those restrictions. The interface will be available in KDE SC 4.6.0 and is supported by Dolphin and Konqueror.

Some developers might notice the similarity to the KonqPopupMenuPlugin, that has been available since ages, but is not supported by Dolphin. The reason why it is not supported in Dolphin are some interface-issues when using the plugin outside the scope of the Konqueror context-menu. After discussing this with David Faure and Sebastian Trüg we decided to cleanup the interface, call it KFileItemActionPlugin and mark the KonqPopupMenuPlugin as deprecated.

Sadly there are not much applications for KDE 4 that take usage of the KonqPopupMenuPlugin interface. On one hand this is good as this means less efforts to port it to the new KFileItemActionPlugin interface. But on the other hand for the users out there this means a not so tight interaction of the KDE file-managers with applications.

So this is a kind of invitation to all application developers out there: Possibly the KFileItemActionPlugin is also a benefit for your application to get integrated in a better way into the KDE file-managers :-)

Search Improvements

KDE SC 4.5 will be out soon and as mentioned in an earlier blog entry, for Dolphin this release has been used to do bugfixing, polishing and internal cleanups of the code. I'm quite happy with the result, however last week I decided to have some fun again and have started to improve the search interface of Dolphin (will be part of KDE SC 4.6).

History

In KDE SC 4.3 a searchbox has been added to Dolphin's toolbar. It used Nepomuk to do the searching:

Although it was already possible to search also for tags, ratings and other kind of data, it was nearly unfeasible for users to discover this functionality. In KDE SC 4.4 I tried to improve this by showing some search options as soon as the user clicks into the searchbox:

By clicking on the green (+)-button, it was possible to specify the searching in a very detailed manner:

Problem #1

When I started to write this (quite complex) user interface, Sebastian Trüg already told me about his concerns, that this kind of user interface might not be the best approach. Well, I still thought that I need to provide something for the users to allow them more specific searches; the feature freeze for 4.4 was near and so I finalized the implementation for this interface.

But Sebastian was right: It turned out, that nearly nobody uses this (+)-button at all. It just takes way too many clicks to specify a query. A better approach is something like Alessandro Sivieri implemented in his semantic browser: Just provide basic filters, that allow the user gradually to decrease the number of found files if necessary.

Problem #2

Another issue is the distinction between searching indexed files with Nepomuk by the searchbox...

... and searching non-indexed files with the KFind shortcut in Dolphin:

Most users out there don't care about whether a file is indexed or not, so I tried to solve those two problems during the last week.

Improvements

When pressing the Strg+F shortcut (I don't know yet, whether "Find" should be part of the default toolbar setup), Dolphin changes from:

to:

Not really revolutionary of course, but I like it that the breadcrumb gets replaced by the searchbox and hence no space is required anymore in the toolbar for the searchbox. The nice thing is that this searchbox integrates the KFind functionality and the Nepomuk searching in one interface. It is automatically detected internally, whether the current folder is indexed or not. Needless to say that for non-indexed folders it takes longer to query for e. g. all texts that have the word "test" inside, but it works. Also without Nepomuk it is of course not possible to query for files, that have a specific rating. But as soon as Nepomuk is available and the current folder is in the index, a filter-button is available on the right side. When pressing the filter-button, the searchbox gets extended:

The interface of those extensions is just a prototype currently, but the basic idea is similar to Alessandro Sivieri's semantic browser: Just allow the user with less clicks to minimize the search results after doing a search by activating a filter. E. g. pressing on the "Home" tag will limit the search result to files that have been tagged with "Home". Although this does not sound very different in the first sight, it is a huge difference when trying it out yourself.

For me personally the ability to search also on non-indexed folders is a big win: In my development environment I don't have indexed my sources, still I often require to grep for some strings in source files. So instead of using the terminal I now can use Dolphin for it :-)