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.