Dolphin 2.0 - Status Update

Grouping Support

When introducing Dolphin 2.0 I talked about  grouping support for all view modes. But I could not offer any screenshots, as this feature was not ready yet at that time. So here we go showing the same folder grouped by the file type in the icons-mode (which is already available since Dolphin 1.2):

... in the compact-mode:

... and in the details-mode:

I think there is a lot of room for visual improvements of the group-headers especially in the combination with the details-mode. However this is something that needs to be discussed with our Oxygen-gurus Nuno and Hugo and will hopefully be improved in the next version.

Still I'm quite happy with the new implementation. It fixes performance issues that occured with the previous implementation, fixes keyboard-navigation issues and provides a solid base for future extensions like grouping by rating, tags, comments or any arbitrary grouping-category.

General Status

The rewrite of the Dolphin view-engine was a lot of work and resulted in changing of much code. The benefits are an improved performance, getting rid of a lot of bugs that could not be solved with the old view-engine and a better maintainable code-base. But it would be illusionary to expect that there will be only benefits and zero regressions: Dolphin 2.0 will be a typical "dot zero" release where minor issues will popup after the release. However based on the current feedback on bugs.kde.org there seem to be no showstopper bugs left. The currently known regressions and missing Dolphin 1.x features can be seen on the Dolphin 2.0 Status page and I'm confident that during the 4.8.x release cycle most regressions can be fixed.

Outlook for Dolphin 2.1

As the development-focus will be to fix the regressions and making the fixes available for the 4.8.x cycles, there is not much room for big features in Dolphin 2.1. But there is one feature that I miss since Dolphin 1.0 and that could not be implemented with the old view-engine: The showing of any arbitrary meta-data of a file in the views. The tooltips and the information panel already can show things like rating, tags, album-name, image-size and a lot more:

Now in Dolphin 2.1 it will be possible to show all this kind of meta-data as part of a file or directory in all view-modes (this also includes sorting and grouping). The view-engine internally already supports this but I could not finalize the user interface for the 2.0 version.

This makes it e.g. possible to configure a kind of "Music view" where for each song the artist, album-name and the rating is shown. Another usecase might be images, where showing the image-width and -height as part of each image might be useful.

Finally I'd like to say thanks especially to Frank Reininghaus, who helped a lot to get the new view-engine in shape. Frank told me he probably wants to give some development-updates on Planet KDE in future, but I think I need to create some public pressure by mentioning this here to make it happen ;-)

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