ppenz

Dolphin 2.1

2012-06-26T12:37:00.000+02:00

Dolphin 2.1 will be released as part of KDE applications 4.9 on the first of August and to me this is a very special release: After 6 years of development, around 2700 commits and a lot of fun I'll be forwarding the maintainership to Frank Reininghaus. Frank did a great job during the last years to improve Dolphin and I'm really glad that he accepted the maintainership.

For me forwarding the maintainership also means that I won't provide any bugfixes or features for Dolphin anymore. Probably this step is quite surprising for most readers and I think I owe an explanation. Before going into details it might be useful to first describe the reasons for developing Dolphin at all.

The first steps

At the beginning of 2006 I wanted to gain some experience with Qt and I've been looking for a small project. I liked the functionality of Konqueror but was not happy with the user interface - I thought that writing a small and fast file manager fitting just for my own needs and to learn Qt should not be that hard (if somebody would have told me that I'll be spending at least 6 years on this project I probably would have given up immediately). Thanks to some great classes in kdelibs I was able to browse through directories only a few hours later and my (wrong) assumption "this should not be that hard" got tightened.

Around mid of 2006 I've released the 0.5 version of Dolphin at kde-apps.org. Making a long story short: Matthias Ettrich called me and asked whether I want to help contributing to the filemanager for KDE 4.0. David Faure was very busy with porting parts of kdelibs to that time and more interested in doing the tricky and challenging parts instead of the "boring user interface programming" (I cannot remember anymore the exact words Matthias has used, but it was something like this). Well, suddenly I was part of the KDE community, got great support from Aaron J. Seigo and it started to get a great experience for me to contribute to such a large project. Learning Qt was secondary then, it was more about learning how the whole development for such a big project works and how decisions are made.

It is quite interesting to compare a screenshot from Dolphin 6 years ago to the recent version:

What has changed since then?

The KDE community is still great and there are enough things left to make Dolphin better, so what has changed since then for me?

One thing is that the time required to keep Dolphin in good shape increased during the last years. I'm doing this project in my spare-time and usually have spend around one evening per week on Dolphin. Especially during the last 2 years this time has increased. In the longterm especially the (for me absolutely necessary) step to port Dolphin to QtQuick2 is something I won't be able to do within a sane timeframe. The interesting thing is that porting the new view-engine to QtQuick2 is probably the easiest part: There is a clean seperation of the representation and the model and exchanging the representation should be doable within a reasonable amount of time. I guess with Qt 5.1 or 5.2 (I don't know) there will be desktop-components for QtQuick2 and porting Dolphin to this components will be a very timeconsuming and boring task: All the settings-pages, the URL-navigator, the information-panel, the search-interface, the tooltips, ... - this is just not doable anymore in my spare-time.

Of course you might ask whether a port to QtQuick2 is really necessary. But to me in the scope of KDE QtQuick2 is the only solution to be able to compete with the other big desktop environments out there in terms of a responsive and beautiful interface.

So would it help if other developers would join the Dolphin project and take care for doing the QtQuick2 port? Sadly for me this still would not be enough to keep on maintaining Dolphin, as there is another reason to quit contributing: I'm using KDE since version 1.2 and I never cared what market share KDE or Linux on the desktop has. However to me it was important that the desktop-environment I'm using and spending time for can compete with the desktops-environments from Microsoft and Apple. As user I always had the impression that I can do my regular tasks like reading e-mails, browsing, managing my photo- and music-collection, rarely writing a document, maintaining my contacts, adding calendar-entries... in a more efficient and comfortable way than on the other desktop-environments.

But at least for my regular tasks as user this has changed during the last couple of years. It is tricky to give examples without pointing fingers to parts of KDE where I think we are not competitive anymore, so I won't do this.

I don't have a good explanation why this gap has increased during the last years (at least from my perspective). One guess I have is that the kind of complexity of applications has changed during the last years:

The user interfaces tend to become simpler and easier to the eye, while the functionality of the application itself has increased. Hiding a complex functionality behind an easy to use interface are not known strengths of "typical" developers ;-)

The complexity of the non-user-interface-parts of applications has increased a lot. Web-browsers are a good example: While the interface got simplified during the last years, the engines showing web-pages got really complex and are maintained mostly by fulltime-developers in the meantime. There seems to be a similar trend in PIM-applications ("cloud"), chat-clients (one simple user-interface, a various number of protocols) and for desktop-search-engines (simple user-interface, really complex stuff going on behind the scenes).

Working on the non-user-interface parts of applications can be challenging and this is not something that most freetime-contributors are striving for. But if there are not enough contributors for the complex stuff behind the scenes and if no company is willing to invest fulltime-developers to work on this... - well then we are losing ground. And even if Gnome seems to get more support from companies, I don't see a big difference to KDE here.

Probably my explanation/guess/theory is nonsense and utterly wrong. But this does not change my point of view that at least for my tasks I can work in a more efficient and comfortable way on other desktop environments in the meantime. And this aspect makes it hard to keep up the motivation for investigating a lot of spare-time into KDE.

I hope this does not sound like a blog-entry from a "frustrated developer" - this is not the case :-) I'm leaving the project at a stage where I still liked to contribute and where I enjoyed being part of KDE. I wish KDE all the best for the future and I'm proud that I got the chance during the last years being part of this community!

Improved Views

2012-06-03T12:34:00.001+02:00

Until now Dolphin could display metadata like rating, tags, comments, image-sizes, album-name, ... only inside tooltips and the information panel:

With the release of Dolphin 2.1 (as part of KDE applications 4.9) this kind of information can now also be shown inside the views. I'll just let some screenshots speak for themselves:

Plasma Active and Maliit

2012-04-12T16:16:00.001+02:00

Openismus gave me the opportunity to check how good or bad Maliit works together with Plasma Active. As I've never installed Maliit nor Plasma Active until now I expected some pitfalls, but in the end I got both of them running on a WeTab tablet:

Most Planet KDE readers are of course familiar with Plasma Active, but what is Maliit?

Maliit

Maliit provides a cross-platform input method framework for mobile text input including a virtual keyboard. Maliit is the input methods solution used in Nokia's N9 MeeGo phone:

Providing a virtual keyboard seems to be straight forward in the first sight, but it is very challenging if things like predictive input, error-correction, cut/copy/paste, multitouch, context-sensitivity or languages like Chinese and Arabic should be supported.

Current State

The combination of Plasma Active and Maliit works together better than I expected initially: Focusing an input field automatically pops up the Maliit keyboard and entering a key results in showing the output without delay on the WeTab tablet. This sounds self-evident, but the performance is very critical for a virtual keyboard: Even a minor delay after touching the device gets noticed by users - the acceptable delay seems to be a lot lower than the usual "keep it below 300 ms and it will be perceived as fast" user interface objective.

At the moment there are at least two open issues that need to get fixed in Maliit:

When entering a key the 'key magnifiers' (= the orange 't' in the first screenshot) don't disappear. The issue is tracked on the Maliit bug tracker and investigations are ongoing.
Currently Maliit requires compositing for providing the virtual keyboard as overlay.

Installation

I've installed Plasma Active and Maliit from the sources on the master-branch to be sure being on track with the latest state of both frameworks. For Plasma Active the installation guide and the development guide are sufficient for building Plasma Active. I've added a few notes to the Maliit on Plasma wiki to document the approach I've taken.

Installing Maliit is straight forward. On the first screenshot above word prediction is enabled. For this Presage is required, one pending merge-request must be used and qmake must be called with CONFIG+=enable-presage

The progress of integrating Maliit into Plasma Active is tracked at https://bugs.maliit.org/show_bug.cgi?id=51 - I cannot judge the final outcome of this, but I think from a technical point of view it is a benefit for both frameworks if they are interacting well. Whether Maliit might be a candidate for being the default input method for Plasma Active also involves some non-technical topics like the general maintenance of Maliit and whether there are enough resources to make the integration with Plasma Active really perfect. We'll see :-)

Taking Care for Details

2012-03-04T14:13:00.001+01:00

Frank Reininghaus already wrote about all the 4.8.1 Dolphin-bugfixes we've done, so I'd like to talk about just one specific fix: It is "only" about some visual improvements regarding the layout of items when turning on the grouping-feature, but the interesting thing is what happened behind the scenes.

It started when Martin Zilz from kreativkonzentrat wrote me an e-mail a few weeks ago with some suggestions how to improve the look of group-headers. The base of discussion was the following state:

Beside the group-headers Martin also recognized other issues with the layout and it required several internal adjustments in the view-engine to achieve what Martin suggested. But after sharing a lot of e-mails with updated screenshots and doing some finetuning in the code I'm really happy with the end-result:

But beside the icons-view we also adjusted the group-header for the other views. Before the changes the compact view looked like this:

After following Martin's suggestions it looks like this:

The details-view is something where I'm still not 100 % happy, as the alternate backgrounds don't work well together with the grouping from my point of view. However I'd say the look still has improved from:

to:

The main reason why I've written a blog-entry about this bugfix is that it should be an example of how an application can get improved when working together with skilled designers. As developer it is tricky to think outside the boundaries of your own implementation. E.g. I never thought about the vertical lines in the compact-view as the height of the group-header widget was only around 20 pixels. Martin was able to think outside those boundaries and in the end it was not tricky to implement. I had similar experiences when working together with Nuno and Hugo from the Oxygen team. Although many users probably won't see the difference in the first sight I believe those details matter to have a comfortable user experience.

Dolphin 2.0 - Status Update

2012-01-03T22:48:00.000+01:00

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

2011-08-01T08:45:00.000+02:00

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

2011-03-27T20:56:00.004+02:00

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

2011-03-05T15:18:00.015+01:00

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

2010-12-22T08:39:00.003+01:00

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

2010-11-20T11:29:00.010+01:00

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

2010-11-02T16:56:00.003+01:00

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

2010-07-24T16:44:00.029+02:00

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

Version Control Support in Dolphin

2010-06-02T19:07:00.006+02:00

In KDE SC 4.4 Dolphin got support for Subversion:

The Subversion support has been implemented as plugin, which is part of the kdebase package and loaded automatically after starting Dolphin.

For the upcoming KDE SC 4.5 two changes have been done:

The Subversion plugin has been moved from kdebase to kdesdk. If you are updating to KDE SC 4.5 and don't have installed the kdesdk package, the old Subversion plugin from KDE SC 4.4 will of course still work. However it is recommended to install the kdesdk package to get an updated version.
The version control plugins are not enabled by default. Although the loading of the version control plugins is done asynchronously, it still consumes memory and (a little) performance. So if you are updating to KDE SC 4.5 and want to have version control support, you must enable the plugins once inside Configure Dolphin... > Services.

A very basic version of a Git plugin is already part of kdesdk. It only shows the version state of files and does not offer any context menu yet, but a group of students works already to improve this. The outcome will hopefully be merged to kdesdk until KDE SC 4.6 (oh dear: KDE SC 4.5 is not out yet and I'm already talking about 4.6 :-/)

Autotools Support for Qt Creator

2010-04-21T16:23:00.003+02:00

Openismus gave me the opportunity to write a autotools plugin for Qt Creator. The plugin is available for download at http://www.gitorious.org/qtcreator-autotools-plugin. Please check the README file for installation instructions.

The plugin allows to load an autotools project and offers the following functionality:

Syntax highlighting for Makefile.am files
Automatic project tree update if a Makefile.am file or the configure.ac file has been changed
Out of source builds
Configuration of build steps
Code completion

The project is in a very early state and has not been tested yet by a broad user base. Any feedback would be very welcome!

Git

2010-03-11T11:17:00.003+01:00

The question which version control system is "the best", is often the base for endless discussions. I'm quite pragmatic in this regard: I've used Rational Clearcase during the last 9 years and worked with CVS and Subversion during the last 4 years. From my experience the acceptance of a version control system depends a lot on how it matches to the software development workflow of a company/community.

Personally I prefer the straight forward approach of Subversion over the (technically) powerful Clearcase. Still Subversion is cumbersome when working with temporary development branches and I was curious when I heard about the concepts used in Git. After reading about Git I thought that it unites the benefits of Clearcase and Subversion without introducing any drawbacks.

At Openismus I got the chance to work with Git on a real project. The first impression was ambivalent: On one hand Git is extremely powerful, fast and does not limit the developer how to work with branches or doing merges. On the other hand the learning curve is higher than expected and it requires a different mind set in comparison to centralized version control systems. Because of the huge amount of new possibilities a ruleset for projects using git is highly recommended. Git reminds me to C++: You can do wonderful things with it in a clever way, but it's very easy to shoot oneself in the foot.

I still need to learn a lot about Git, but after a few weeks of working with it I already prefer it over Subversion a lot. More and more projects switch to Git, so this does seem to be a common experience.

Packaging

2010-03-04T15:41:00.005+01:00

Before I joined Openismus, I never created RPM- or Debian-package for my sources. After releasing an early version of the Dolphin sources at www.kde-apps.org, friendly people stepped up and created RPM- or Debian-packages for them. When Dolphin got part of KDE, the packaging anyhow was no problem anymore as it had been done by the Linux distributions.

At Openismus one of my first tasks was the prepare Debian packages for Glom and the Qt frontend Qlom. Beside preparing packages for Ubuntu Karmic, also packages for Maemo had to be created.

I always thought developing software can be tricky, but now I know that creating a package is also very challenging and requires a very focused style of working. As there are many traps for beginners, I'd like to provide some useful links that helped me to fulfill this task (beside the help of my colleagues at Openismus of course):

Debian New Maintainers' Guide: Is a must-read if you need to create a package from scratch.

Building Modified Debian Packages: Provides a good overview for the case where a source package is available, which should be updated by some patches.

Creating Debian Packages for Maemo: When creating a Debian package for Maemo, some things from the Debian New Maintainer's guide can be skipped, other additional steps are required. Beside step by step instructions to create a Maemo package from scratch, the differences to a default Debian package are explained well there.

Still there is a lot of room to fail at the beginning. There have been some traps I fell into and I'd like to summarize them as long as I can remember them:

Don't modify a decompressed version of a file that is part of the *.orig.tar.gz file, without updating the *.orig.tar.gz. This sounds (and is) obvious, but it is easy to fall into this trap when modifying e. g. a configure.ac file for testing. The result of doing such changes is that the local installation of the generated package might behave different in comparison to the official package created by a PPA.

Beside the build dependencies take care to verify the runtime dependencies. It is easy to forget this, as the local system most probably will already contain the needed packages.

Profiling

2010-02-22T19:05:00.004+01:00

Although I like Criminal Minds, this blog entry is less thrilling: it's about profiling applications like Dolphin.

When I faced a performance issue in Dolphin, I usually used valgrind in combination with callgrind to find the bottleneck (valgrind --tool=callgrind dolphin -nofork). The output can be visualized by KCacheGrind in a nice way:

One big benefit of Valgrind is that it gives 100 % coverage of user-space code. But as usual there are rarely benefits without drawbacks: As valgrind is a kind of virtual machine, that uses just-in-time compiling, the application runs around 5 times slower. This can get a problem if timers are involved in the application. Also performance issues in combination with threads are tricky to identify, because valgrind does not give a non-obtrusive performance overview of the overall system.

So I started to get familiar with OProfile during the last week. OProfile is a non-obtrusive system-wide profiler, which means that the application runs (nearly) at the same speed as without profiler. OProfile gives an overview about the workload of all processes in the system. This is very useful for Dolphin, as the overall performance of Dolphin depends also on e. g. Nepomuk and asynchronous operations to e. g. get file previews. It is possible to convert the OProfile output to a readable KCachegrind file by 'opreport -gdf | op2calltree'.

Dependent on the usecase, both tools are really helpful. The next thing on my TODO-list is to get more familiar to locate I/O bound bottlenecks: When reading the number of sub directories for 20000 directories, the bottleneck is definitely not on the CPU side (in this case neither Valgrind nor OProfile can detect the bottleneck). All in all I hope that I find the time during the KDE SC 4.5 cycle to improve the Dolphin performance in some areas with the help of these tools.

Visiting Openismus in Berlin

2010-02-15T15:19:00.005+01:00

On February the 1st I started my new job at Openismus. Most of the time I can work at home in Austria, but last Wednesday I got the chance to meet the Openismus team at their office in Berlin. Beside my first visit of Openismus, it was also my first visit of Berlin. I was very impressed by both of them: the team and Berlin.

I got the chance to do some trials with Qt on Maemo and to get familiar with what is working well and which parts still need a lot of investigations. All developers at Openismus are Gnome people, being the only one using KDE is not always easy ;-) But maybe it helped that Dolphin does not look so much different in comparison to Nautilus - I even got a KDE-sticker from an Openismus colleague.

I'm learning a lot of new stuff currently and will have less time during the next weeks for Dolphin. However this will change after mastering the usual time that is needed to get really productive. In the end I hope that I can apply the knowledge I gathered through KDE development with Dolphin for Openismus and also that Dolphin will benefit from the new things I learn at Openismus.

Internal Cleanups

2010-01-31T12:42:00.015+01:00

Warning: This might be a quite boring blog entry for non-developers - no fancy screenshots and no new features... ;-)

Beside taking care to keep Dolphin simple and efficient for users, it is also very important for me to do the same for the code: It should be simple and easy to maintain for developers.

Sometimes this works quite well, but it also happens that parts of the code need to be refactored. It is quite common in commercial companies that developers don't get the chance to refactor the code: The user does not recognize it in the first sight and there is definitely a risk of having regressions.

I'm convinced that in the long-term keeping the code base clean pays off and results in less bugs and easier maintenance. Although some features like improved searching or version control support have been added for Dolphin in KDE SC 4.4, I also did some internal cleanups.

For KDE SC 4.5 I want to completely concentrate on fine-tuning the code base of Dolphin, so that some long standing bugs can be fixed in a clean manner:

Information Panel

I totally underestimated the complexity of the Information Panel before KDE SC 4.0 had been released and was never happy with the code-base. I tried to fix things from release to release (which can also be seen visually when looking at the screenshots from the Dolphin-News). Now with KDE SC 4.4 the code-base is a lot better, although there is still some work until it can be moved to kdelibs to get shared with other applications (I blogged about it already in Information Panel and Tooltips). One issue that needs definitely to be solved for KDE SC 4.5 is a non-blocking fallback solution for showing meta information even when Nepomuk and Strigi indexing are turned off (bug 193592). Also fixing the missing meta information in the properties dialog (bug 190588) is a must.

Column View

The column view has been added shortly before the feature freeze for KDE SC 4.0. I fell into the trap to assume that showing several columns cannot be much more difficult in comparison to the other views. The result was that the column view added a lot of complexity to the code and fixing column view related bugs was tricky. I cleaned up the code base for KDE SC 4.4 and am quite happy now: A lot of interfaces and workarounds could be removed, less code is needed and fixing column view bugs is straight forward. The beta releases and release candidates popped up some regressions, but they could be fixed quite fast.

Location bar ("breadcrumb")

Long before KDE SC 4.0 had been released, the location bar was only meant as prototype. It happened too fast, that we moved it to kdelibs to make it available for the file dialog... It was my fault not taking care to cleanup up the public interface of this widget before KDE SC 4.0 (honestly speaking: There really where more serious problems to solve to that time ;-)). I could not manage to do a cleanup for KDE SC 4.4, but a refactored version is already available on trunk. There are two nice "side effects" of this cleanup:

Dolphin can now easily remember the expansion state of detail-view trees when going back in history (I've to thank Frank Reininghaus a lot for his contributions in this area).
The Dolphin code could be simplified, as it is very easy now to remember history states.

There are also a lot of minor things I wanted to fix since KDE SC 4.0 already. For example in the icons view the wrapping of file names is only done nice on spaces or the minus symbol. Dots and underscores are handled like letters, which might lead to nasty wrappings like:
my_document.tx
t
instead of
my_document.
txt

The searching for Dolphin has already improved in KDE SC 4.4, but still needs a lot of work...

Things like these are what I'd like to fix in Dolphin for KDE SC 4.5, so please don't expect huge, new features :-)

BTW: I'm very happy to announce that on February the 1st I'll start working fulltime at Openismus. Most probably I'll get the chance to work with Qt for Maemo 6 (Harmattan).

Version Control Support

2009-12-12T16:50:00.005+01:00

Before a feature is added in Dolphin, it is checked whether the feature is mandatory for Dolphin’s target user group. If this is not the case, it does not mean that the feature cannot be added; first it must be clarified whether the feature might be non-intrusive and adds a value for users outside the primary target user group. Non-intrusive is mainly related to the user interface. A feature that adds a lot of clutter to the main menu, context menus or toolbar might harm the target user group. In this case the feature will not be added.

A good example of a feature that is non-intrusive is the embedded terminal in Dolphin. It only requires one entry inside a sub menu, but adds great value for a lot of people that are not in the scope of Dolphin’s target user group.

Another kind of non-intrusive feature will be available for Dolphin in KDE SC 4.4: version control support. In KDE 4.4 at least a plugin for Subversion is given:

The version state emblems and additional entries in the context menu will only be shown if a directory is under version control, so this feature fulfills the requirements for being non-intrusive. The plugin still has a lot of rough edges and has mainly been written for testing the plugin interface. Still I use it regularly and it fulfills most of my needs.

It is possible for developers to write other version control plugins for Git, Mercurial or whatever, just by following the instructions given in the plugin interface. In KDE SC 4.5 it is planned to embed the plugins as part of the kdevplatform package, but this has not been finally decided yet. The benefit to offer the plugins as part of kdevplatform will be, that the existing infrastructure for version control integration can be reused by the plugins.

Big thanks go to Nuno Pinheiro, who created icons for the version control states!

Searching

2009-11-14T13:31:00.010+01:00

If I compare the number of files on my current hard disk with the number of files I had 10 years ago, I'm quite amazed. How to deal with this increased number of files is topic of a lot discussions. Tagging, searching, filtering, relations, virtual folders... - terms, where from a KDE-developer's point of view Nepomuk comes to mind, which provides already all the technical base. Still there is the task to integrate Nepomuk into applications, so that users out there are able to benefit from this great technology.

It's a small step only, but at least one step further: During the last week I've integrated Addam Kidder's GSoC 2009 work into Dolphin. I know that some people don't see searching and filtering as "the solution" to deal with the increased number of files and I agree. Nepomuk offers a lot more, still the searching and filtering is a basic feature, that I personally require quite often during my workflow. The current state of the code is far from finished, still the basics are there now. As soon as the search-bar at the top gets focused, the search configurations pop up below as shown here:

Searching for files having the tag "Tree" is very simple. Selecting "Equal to" and the corresponding tag in the combo-boxes beside "Tag:" has the following result:

One goal of the interface was to minimize the number of clicks that are required to specify a search query. That's the reason why per default at least three (hopefully) commonly used search criterions are visible. For sure it is possible to create very complex queries with more criterions too:

Still I think users will use such complex search queries quite rarely. I had some discussions with Sebastian Trüg and Alessandro Sivieri regarding the faceted panel, that exists as prototype currently. The discussion convinced me that a common workflow for users might be:

Fill the search-bar with some keywords and trigger the searching.

Only if the number of returned files is too high, start a filtering step by step on those files.

This might sound obvious, but has implications on the user interface:

The number of clicks to activate a filter must be minimized.
It should still be powerful: The kind of filters should not be limited.
Doing filtering step by step means that the user interface may not get hidden after triggering the first filter.

Especially the combination of point 1 and 2 have requires doing some compromises. Limiting the number of clicks requires more screen space. As there is only a limited screen space, the number of shown filters must be decreased. Finding a balanced solution is quite tricky.

I'm also unsure which data the breadcrumb should show: Visualizing a string like "nepomuksearch:/+lastModified<2009-11-13 +rating<8 +tag:Peter" to the user is something where I doubt Apple would do. Any suggestions would be welcome.

That's also one purpose to write this blog entry: Please let me know your daily problems when trying to search and filter files from your hard disk. I hope that I can integrate your input until KDE 4.4... Thanks!

Information Panel and Tooltips

2009-11-06T20:12:00.002+01:00

Dolphin for KDE 4.4 will provide a refactored information panel and refactored tooltips. The goals of the refactoring have been:

Show the same data in the information panel and the tooltips. Up to now the information panel did not provide any information about the permissions or the owner of a file. The tooltips have shown this kind of information already, but they did not provide informations like rating, comments or tags.

Prevent a possible blocking of the user interface, even when a slow Nepomuk backend or a buggy Strigi analyzer is installed. Although in KDE 4.3 some improvements had been done already, there have been still problems in this regard especially for tooltips.

Improve the layout of the information. The rating, comment and tags information are not handled in a special manner anymore.

Simplify the interface for editing tags and comments.

Although there is still a lot of finetuning necessary until KDE 4.4, it is obvious already that the tooltips...

... show the same information as the information panel:

Originally it was planned to move the refactored widget to kdelibs, so that applications like Mailody, Gwenview and Okular can show the informations in a similar way. However there have been some usecases especially in combination with Gwenview, where the interface of widget was not sufficient yet. So we decided to leave the widget in Dolphin for KDE 4.4, but I'm confident that we find a good solution until KDE 4.5.

Nepomuk and Dolphin

2009-06-24T16:10:00.004+02:00

Sebastian Trüg already blogged about the Nepomuk Coding Sprint that happened last weekend in Freiburg. It was great to meet all the guys in person and to share ideas face to face. Sebastian was a great host and I liked the general spirit of the meeting :-)

I just wanted to give a short summary from a Dolphin point of view. On the weekend the following things have been improved for KDE 4.3:

The labels for Nepomuk meta information have been fixed.

The usability of the comment widget in the Information Panel has been improved.

Performance problems when renaming several hundreds of items have been fixed. Originally I thought this has been caused by Nepomuk, but it was a Dolphin internal issue.

We could track down the root cause for freezes when a tooltip is shown for huge PDF files and MPEG files. Originally we wanted to discuss whether we want to use Nepomuk instead of Strigi to get the meta information, but it turned out that only two Strigi analyzers need to be fixed to respect a maximum size setting.

Well, I was not as productive as I wanted to be. The main cause was that my development environment on the Notebook was not setup properly and it took me some time to fix it (until this sprint I did not use my Notebook for development).

The more interesting thing is what we’ll try to improve for KDE 4.4:

Better search integration. Although Dolphin for KDE 4.3 offers a search box, this is just a first start. We did some discussions and Dolphin for KDE 4.4 will offer a user interface element to configure the search query in an easy manner. Maybe this interface element can be used by other applications too if it works well.

Fix usability issues of the tag rating widget. The tag rating widget in the Information Panel has some usability issues. Gwenview goes into the right direction I think and the goal is to have a common widget for KDE 4.4.

Sebastian introduced his Formatting Rule System which might be very useful for the Information Panel. It requires a lot of work as it is still in draft, so it’s unclear whether we can integrate this to KDE 4.4 already.

Generally I was impressed how much potential Nepomuk offers. I think it will take quite some time, but I’m convinced that real innovative things can be done in future by using Nepomuk (especially in combination with PIM related applications).

Qt Creator

2009-05-01T22:59:00.003+02:00

In the office I use Microsoft Visual Studio and Eclipse for the C++/Java development. For developing Dolphin I used an editor and the shell, but honestly speaking in comparison to an IDE this is very inefficient especially when it comes to debugging.

After reading Qt Creator, CMake and C++/Qt Development I gave Qt Creator a try and was highly impressed. Although it currently cannot compete with the functionality of an IDE like Visual Studio or Eclipse it is a pleasure to work with Qt Creator. The user interface is very clean and polished and I have high expectations for future releases...

Information Panel

2009-04-12T21:48:00.006+02:00

Dolphin for KDE 4.3 will have some improvements for the Information Panel. One improvement is that Nepomuk is used to get the meta data, which allows to show a lot more information:

Currently the meta data titles are internal names used by Nepomuk (e. g. "audioCodec"), but this (hopefully) will be improved until KDE 4.3 so that it is written as "Audio Codec:".

It is also possible now to configure which informations should be shown:

Because of Phonon it is possible to play audio files:

... or even videos:

Please note that it is not the intention to convert Dolphin into an audio-player or video-player. The current functionality is just meant as improved preview for media files.

Final remark: Until KDE 4.2 it was possible that Dolphin got blocked for several seconds when reading the meta data of specific files (huge videos, compressed files). The nice thing about using Nepomuk is that no blocking occurs anymore, as the meta data parsing has been done already outside the context of Dolphin.