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

Version Control Support in Dolphin

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:

1. 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.
2. 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

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

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

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

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

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

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:

1. 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).
2. 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).