Version Control Support

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

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:

1. The number of clicks to activate a filter must be minimized.
2. It should still be powerful: The kind of filters should not be limited.
3. 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

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

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

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

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.

Directory Thumbnails

Usually after a KDE version has been released, it's quite clear for me how Dolphin will look like in a half year for the next release. The time for feature development is quite limited, so there is only a small set of features that can make it into one release.

The best thing of being part of the KDE community is when other KDE developers provide patches for useful features, that I did not have on my Todo-list at all. This happened recently when David Nolden submitted a patch for directory thumbnails. I even did not notice the feature after it had been committed (the code for this is outside the scope of Dolphin). I only got aware about this because David send me a mail, where he asked about the reason of having a wrong alpha blended background for directory thumbnails.

I tried to fix the issue and did some adjustments in the code to have the image folder as background and the images aligned in front of the folders. Well I'm no real artist and two days later another mail was in my inbox. This time from Fredrik Höglund, who provided a patch to improve the look of the directory thumbnails by a nice white border and shadow.

David already wrote about this feature in his weblog and even added a very useful slideshow feature for previews. Feeling somehow guilty that Dolphin got improved by a feature I even did not have on my radar I wanted at least to take care on the remaining issues:

• fix scaling issues for large directory thumbnails

• improve the performance

• let the user configure which previews should be generated

The scaling of the icons in general was not as good as possible. This was especially visible with large icon sizes and has been fixed now:


The directory thumbnails get cached now and are quite fast after creating the thumbnails at least once. Before showing the directory thumbnail it is checked whether the directory content has changed to assure that no outdated cache is used.

Still it is possible that some people don't like this feature, so I added a configuration to let the user decide which previews should be generated:


I'll write about the other features that will appear in Dolphin for KDE 4.3 during the next week :-)

Trees

Per default the details view in Dolphin looks like this:


and can be configured to be a tree view:


Some settings in Dolphin, like 'Show Hidden Files', 'Show Preview', 'Sorting' and 'View Mode' are remembered per directory, which means that e. g. directory A can be configured to always show previews, while directory B can be configured to show just icons.

Other settings are global. For example the icon view can be configured to have a specific font. When changing the font, this font will be used for all directories where the view mode is an icon view.

The decision which setting is global and which setting is directory dependent is not easy. Currently the setting whether the details view offers collapse/expand-items for the tree functionality is a global setting and is called "Expandable folders". We are unsure whether there are use cases to remember this setting per directory or not and if we should change this in KDE 4.3.

Remembering the "Expandable folders" setting per directory would make it possible to have a tree view for directory A, while having a details view for directory B. I would be very interested to have some feedback for this topic by providing a use case that makes it useful remembering this per directory.

Generally speaking remembering the settings per directory has the benefit of being very flexible, but this flexibility also has it's drawback: Each time a new directory is created or entered the first time, more view dependent settings have to be adjusted.

So what do you think?

PS: All users that have activated the option "Use common view properties for all folders" I'd kindly ask to give no feedback, as with this setting all options are global settings and not directory dependent :-)