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.