Monday, August 1, 2011

Introducing Dolphin 2.0

During the last months I've been working on Dolphin 2.0 which is planned to get released with the 4.8 release of KDE Applications. Dolphin 2.0 will get a new "view-engine" that will have several improvements in comparison to the current version.

Well, what means "view-engine" in the scope of Dolphin? The view-engine is responsible for showing the directory content as icons and text. In a very simplified form it can be seen as the sum of Dolphin's "icons mode", "details mode" and "columns mode".

"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...

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

86 comments:

Now i'm going to suggest something radical.Do you think it would be possible to replace the folderview painting by your new view?It has always bothered me that folderview and dolphin don't look and feel the same, because they are two different implementations. Also folderview is barely maintained, so more codesharing with something like dolphin would be a huge advantage.

I really like how hovering currently works in Dolphin. It's very clear and unique for all elements. If you select many elements it's really clear and obvious what is selected and looks nice in addition.In my opinion it would be a pity to lose this nice interface and go back to how it looked in KDE3. I don't see the advantages for this.Anyway, all other points sound really great and I'm really looking forward to see these features!

Yesterday I was wondering what happened to dolphin's and konqueror's item view, and now I'm really happy to read what's going on with their development, keep on with your awesome work :)

However, a suggestion: even if we are running kde from master, and software could be crashy/feature incomplete there, what about pushing your changes in a separate branch and merge it only when "almost done"?I really miss drag & drop and the preview features, I hope you will reimplement them soon.

That is nice, speed is really an issue with dolphin in large directories. Any chance this could also involve adding a virtual folder ".." for the path above the current folder? At the moment the lack of this (which other filemanagers like krusader) have, makes drag and drop to the folder above the current one impossible.

@Beat Wolf:> Do you think it would be possible> to replace the folderview painting> by your new view?

Yes, technically this would be possible now as everything is QGraphicsItem based. But the API must get stable first and this is for sure something that will not happen already for the 4.8 release... Also there is the same question for the file-open dialog, which also does not use the Dolphin implementation.

@Click: > In my opinion it would be a pity> to lose this nice interface and> go back to how it looked in KDE3.

I'm confused: The interface will stay the same, only the hover-area will be optimized to allow non-rectangular areas. Nothing is "lost" by this ;-) The look is not finalized yet and might stay equal to the current Dolphin version.

@[Po]lentino:> However, a suggestion: even if we> are running kde from master, and> software could be crashy/feature> incomplete there, what about> pushing your changes in a> separate branch and merge it> only when "almost done"?

I thought about this, but by developing on a separate branch I would be the only person that is testing Dolphin and most probably other developers won't notice any commits done there. By doing it on master I think the process is more open and I get more reviews of my commits.

@toddrme2178:> Is it going to be possible to> install this independently of> KDE trunk or will it depend on> changes outside of dolphin?

These changes are independent from trunk and don't depend on changes outside of Dolphin. But I've only tested it it with trunk, so no promises :-)

> Is this also going to> allow collapsing groups?

Not yet and I'm quite sure that at least for 4.8 this won't get implemented as there are still too many open other issues that must be fixed first. However I like this idea and hopefully this will be something for 4.9.

> Is it going to fix the issues> with keyboard navigation when> grouping is enabled?

@ click: The problem I have with the hovering is that it makes it really hard to use the rubber band for selecting icons. You either need a large gap, which wastes a lot of space, or you need to start at the edge of the screen, which makes it hard to do many types of selections. I have practically given up trying to do rubber band selections since the current interface makes it so difficult. So for me the change is quite welcome.

Hi, I'm currently using the symbol view mode with only one line of text per filename, rather small icons and the grid organized after columns (icons left of filename).Until now each column of files has exactly the same width, regardless of the actual filenames in the column.Therefore I have only two options:- Have narrow columns with many filenames cut off.- Have width columns with a lot of wasted space.

Will these changes also support dynamic column widths, so I can see the whole filenames?

I hope this will improve display of picture previews, since you cannot browse a folder with lots of pictures, go to a subdirectory, and go back and just be back again. No, it takes forever for the previews being re-loaded which is just unacceptable. A better cache is needed here :)

The same caching mechanism will be used also for Dolphin 2.0. The updates are slightly faster because of the new layout engine but I'm wondering about "takes forever": Do you have some rough numbers? E.g. all visible previews get resolved here in around 1/3 of a second when going back even on a slow computer. The invisible previews get resolved in background and this takes longer when having several thousands of items but this is to keep the UI responsive and as they are invisible I don't consider this as an issue.

@Anomymous:> But doesn't that make the floating > icons (select/deselect) more> difficult to use?

I'd say it makes it easier to use: With Dolphin 1.7 the position of the select/deselect icon is hard to guess for users until they hover an item. It is always aligned on the top/left of the hover-rectangle which is unknown until hovering instead of the top/left of the icon itself.

With Dolphin 2.0 the position of the select/deselect icon can be moved exactly to the top/left of the icon or even slightly overlapping of wanted. So the position of those icons will be predictable without hovering and hence will be faster to access.

@Peter: I just tested Dolphin on master. AWESOMLY FAST! Go for it! :)I just tested navigating in the folder where I was criticizing the preview load time a lot.I clicked on the folder and it took some time for the preview being loaded for the first time (it feels that it takes longer than before) but then once the previews are generated, navigating back and forth makes them almost instantly appear again. Even closing dolphin and navigating to the same folder again is insanely fast. That was what I have been waiting for since I use KDE :DOnly thing: It seems not to continue generating previews while you’re scrolling. Maybe it does, but not in the visible scope but somewhere else (linear from the beginning?). If you release the scrollbar then it continues generating the prewviews

That's some needed work, thanks!I'm a little concerned about the hover area and the position select plus icon.If I understood right the plus icon will be over the icon, I would personally prefer it to be at the top left corner like now, it feels cleaner, as each icon/filename space is clearly defined, in the new way icon and filename look more like 2 distinct objects.

@damian: I think this was just a demonstration for the non-rectangular boundaries and has nothing to do with the plus position :)

@tobaj: I just did "sudo apt-get build-dep dolphin", "git clone git://anongit.kde.org/kde-baseapps", (modified the CMakeLists.txt to only build dolphin and not plasma and other stuff) and compiled it. Worked fine :) Try it!

I also like how hovering is done actually, but the clipping text thing will be a welcome improvement (and the animated transition too).

On the other hand, what I'm really missing is a Preview feature like on OSX see the mockup here : http://saukonpaa.com/videos/preview.gif and the corresponding feature request / brainstorm here : https://bugs.kde.org/show_bug.cgi?id=247322

I've built all components (well, what the hell?) not just dolphin. I'm very glad that just standard built process did the job and it went smooth painless.

Listing large directories in dolphin is indeed many times faster now. Beyond compare to dolphin 1.7 (bye bye my old friend!) I like the new animations too. There are some glitches but I'll hold my horses. I'm still too excited to post bugs now..

Looks quite fine to me so far .. some bits are missing (hey, get me drag&drop back!) but it certainly looks like improvement (in speed).

Just want to mention .. I actually happened to like that all view items are the same size ("appeared" that way) in Dolphin. It was what made Dolphin better usable than most file managers (FOR ME: take care, opinion). It somehow made selecting easier :).

Anyway, great work, I really appreciate you working on even improving one of the best file managers the world has seen so far.

Thank you! (basically I could just have said that, but you know, constructive critism is always funny :D).

>I'm confused: The interface will stay >the same, only the hover-area will be >optimized to allow non-rectangular >areas. Nothing is "lost" by this ;-) The >look is not finalized yet and might stay >equal to the current Dolphin version.

I referred to the look of selected items only. If this stays the same, I'll be totally satisfied ;D

@ tobaj: I want to install dolphin on its own, so I need to compile it without the rest of the applications, so I need to modify the cmakelists file (or files). Kai Uwe said he or she did this, and I was trying to find out more specifically what was done.

One thing dolphin (and I say the rest of kde systemwide) needs is support for smooth scrolling. Currently scrolling on dolphin is very jumpy. giving it support for smooth scrolling would go a long way in improving the overall user experience. Keep up the good work :)

I'm very glad to hear about these changes, however still having trouble understanding some parts of this post. Namely, this paragraph:

>So the new view-engine for Dolphin 2.0 is build on a (very) modified subset of Itemviews-NG.

1)Is the Itemviews-NG *not* an official Qt library? Is the library ever going to be integrated into Qt, how can we be sure?2)Did you simply copy their Git code? If so, how are you going to keep the Dolphin and the Git version of the code in sync?

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

3)IIRC libraries are not "integrated" into applications, libs are "used" by the apps. What did you actually mean to say with this sentence?4)Will you port Dolphin to Qt Quick, thus trashing the new 2.0 View code?

Also, I'd like to ask you if you changed the View only or both the View and the Model part of the code.

> 2)Did you simply copy their Git> code? If so, how are you going> to keep the Dolphin and the Git> version of the code in sync?

I took mainly the concepts and interfaces, the code in Dolphin itself overlaps very less with the Itemviews-NG code. Nothing needs to be kept in sync as there is no active development ongoing in Itemviews-NG.

> 3)IIRC libraries are not> "integrated" into applications,> libs are "used" by the apps.> What did you actually mean to> say with this sentence?

Currently this "lib" is part of Dolphin. It is open yet whether this will be moved to kdelibs in future. What I meant is that the "view-engine" code in Dolphin will be adjusted to use Qt Quick in future.

> 4)Will you port Dolphin to Qt> Quick,

Probably, but not before Qt 5 is on the horizon.

> thus trashing the new 2.0> View code?

The 2.0 code won't get trashed because of Qt Quick, only a rather small part needs be adjusted. Most of the 2.0 code is not user-interface related at all.

@Ignat:> If that's the case, do you know> what's going to replace the> Interview in the future?

This should be handled by Qt-Components, but there is nothing in development currently that would work for the requirements that Dolphin has.

> Do you mean that you have> written a Model-View> framework yourself from> scratch? :)

No, I would not say it like that: I think the term "Model-View framework" is wrong, the model-view-controller-concept is just a pattern and I've implemented this pattern for file-items and that's it :-) No matter what Qt will offer in future, the usage KDE's KFileItems, KDirLister, KIO-slaves etc. must be done by someone anyhow and this is what I did.

The generic interface of the MVC-pattern used here is really small.

> Also, does the port described> in this post affect both the> Model and the View or the View> only?

I am very sad that current Dolphin version does not keep its original functions.

AFAIK, a file manager's main task is to help the user with showing/listing the features of files. Before getting to the content of files, we are often interested only in the storing features of the file: name, size, creation date, etc.

The current Dolphin version is not able to show the accurate size of file if it is over 1kB. It shows only the rounded value in kiB, MiB units. It is not a solution to click on the properties because if I want to see and compare the size of few files I cannot see them simultaneously.

I am not against the solution of using such units. There may be people who like it. I am for having the option to switch to accurate file size.

Until that, I am forced to use the old midnight commander for file management.

@Thomas Zander:> I was wondering if you noticed my> clone of the itemviews-ng on> gitorious and the fixes I> made there, and if you have> any fixes that we may combine.

No, I did not notice your itemviews-ng clone yet but will take a look after the Desktop Summit :) I noticed several smaller issues in itemviews-ng and actually I'd say that the current code in Dolphin differs quite a lot already. What I really liked in itemviews-ng is the simple model-approach and the basic concept of how the view works with the recycleable items - still I've changed a few basic concepts (e.g. in Dolphin the "treeview" is not completely separated like in itemviews-ng for several reasons) but I think it is good if we keep an eye on each other to probably exchange ideas + improvements :)

@Anonymous:> Dolphin has some good features,> but it is missing the one feature> from Konqueror that I can't> live without: arbitrary> splitting of view panels. Are> there any plan to include this> feature in Dolphin?

There are no plans for this at the moment. The feature is very rarely requested and I see this clearly as Konqueror-feature. The problems I've with arbitrary splitting is that the user-interface for closing/creating splits is quite complex for the main target user group (see http://dolphin.kde.org/philosophy.html) of Dolphin. Sadly I cannot make all users happy at one time ;-)

@Anonymous:> Dolphin has some good features,> but it is missing the one feature> from Konqueror that I can't> live without: arbitrary> splitting of view panels. Are> there any plan to include this> feature in Dolphin?

There are no plans for this at the moment. The feature is very rarely requested and I see this clearly as Konqueror-feature. The problems I've with arbitrary splitting is that the user-interface for closing/creating splits is quite complex for the main target user group (see http://dolphin.kde.org/philosophy.html) of Dolphin. Sadly I cannot make all users happy at one time ;-)

I want to support Anonymous petition.I know nothing of programing so I can't see why adding a horizontal split option is more difficult than the vertical one, already present.Surely inmense majority of users don't need such an advanced splitting capacity as Konqueror's; not too often we need 3 vertical and 5 horizontal splits for managing files in a dozen or more deifferent folders simultaneously, ok, but since most users use only Dolphin for file managing, and let Konqueror for... well I don't know for what since it sucks at web browsing, basic horizontal splitting feature would be a good one, and avoid the need of switching their favorite file manager for a Konqueror 4 which file management capacities many users don't even know/remember.Try by yourself to work with Dolphin occupying just half or third of your horizontal screen size -many people have 2 or 3 windows distributed over their screens at the same time, especially on medium-big resolutions- then open recursively a folder with 8-10 subdirectories with normally long names; now split the view: you won't be able to read the last directories, and need to move the horizontal scroll bar, hover the mouse and wait for the tip or the info panel information, or mazimize horizontally the window.Well, this is not some severe bug, of course, but in terms of usability is a clear defficiency, users need more time and "maniouvres" to achieve something a sime horizontal split would offer instantaneously.

But in fact mi comment wasn't motivated by this issue. What I originally wanted to suggest you is to add the option of showing metadata colums like Windows Explorer does since Windows XP if not even before. Besidea file sizes, owners or dates it'd be cool being able to add colums like bitrate or album title for audio files; author or keywords for documents, resolution and EXIF info for photos, or resolution and duration for videos, among others. I know we can see some of this info in the info panel, but we have to hover the mouse one by one through all the files in a folder, and of course we can't sort the files by any of these criteria. We can also use teh dedicated programs like Amarok, Gwenview or Okular and get tons of useful info, but the purpose of a file manager is that: file management, no? and all those metadata are very useful for file management.Well, what do you think? Could it be possible? I do love Dolphin as it is now, but I miss some features, I think very useful for most users, that are present in file managers ¡¡from the XX century!!, haha.

Is this Qt Interview Framework, responsible for the poor dolphin performance, likewise used as the view-engine in Gwenview?

I ask because i work 3D animation company that uses linux workstations with a choice of Gnome or KDE, and our lead artist feels compelled to use the former because image browsing applications in KDE are far to slow to deal with folders containing thousands of rendered images.

If Itemviews-NG was equally a solution to the problems we have with Gwenview then you could claim back one more user..........

@jedibeeftrix:> Is this Qt Interview Framework,> responsible for the poor dolphin > performance, likewise used as the> view-engine in Gwenview?

I don't know whether Gwenview uses Interview internally.

> because image browsing> applications in KDE are far> to slow to deal with folders> containing thousands of rendered> images

It depends what you mean with "slow": The initial loading of the folder or the scrolling through the items or the overall time until the images are rendered? AFAIK Gwenview only renders the visible items so at least the loading should be fast (but I did no stress-test with Gwenview).

However there is no simple answer for a such generic question and IMO this nothing which depends on Gnome or KDE: you can write slow/fast applications that deal with images in both environments.

Such a menu must be provided by the e-mail application as "service menu" (see http://techbase.kde.org/index.php?title=Development/Tutorials/Creating_Konqueror_Service_Menus) and Dolphin will embed it automatically. If I'm not totally wrong KMail2 already provides such a menu and hence is available in Dolphin.

Still nothing related to somehow merging/wiring places and treeview :/

Several proposals have been posted in the brainstorm forum, but nothing has been done. If you want to have treeview visible you have to deal with too much scrolling because of having the usual linux tree (you know, etc, home, usr.. folders).

Many people (including me) would like to see some advances in this point, whatever solution you choose:- Using a merged version, similar to the one used in gwenview.- Allowing the user to filter the visible folders from /.- Using the closest place as root of the treeview.- Other ideas here...

I have pulled the most recent sources from GIT and compiled. As well as generally being MUCH snappier and therefore much less frustrating to use, the changes also appear to have helped me a lot with the issues I was experiencing in relation to this bug:

https://bugs.kde.org/show_bug.cgi?id=267188

Anyone who also suffers from these issues might want to try building their own Dolphin.

Also want to say the build process was very easy and stress-free. Cmake makes things so much easier than the old days...

There is a bug with the dolphin in kde 4.8 beta2:When using the "open folder during dragging operation" option while in split view mode, dragging a file to a folder in the other "view" cause it to open in both views. ie changing the path of both views to the target folder, instead of changin only the relevant one.

Since Dolphin will utilize a new framework, will it support hiding files by placing their names in a ".hidden" file anytime soon? Gnome's Nautilus, and I believe a bunch of other managers already have this and I got hang of it. It was sad to see it go as I made the switch over KDE.

Please report it on bugs.kde.org instead of the blog. It is impossible for the Dolphin team to keep track of bugs reported per e-mail, on blogs or on forums (it is already tricky enough to do it on bugs.kde.org). Thanks!

Great job! This corrects all issues I had with Dolphin but one. I would like Konqueror like bookmarks along with places. I use Dolphin for file browsing, ftp, ssh (fish) ... so organising links in many like structure would help alot.

Anyway, great job. This was already best browser out there. Now there is no comparison at all (except maybe with DOS Navigator :)

@Rulatir: Go to "Customize View" (or so) in Dolphin’s menu (or View → Customize View if you have the menu bar enabled), choose the view mode, sorting, etc to your liking and then choose "Use those settings as default" and confirm the dialog. This will make the new setting default for unvisited directories.

I have always been wondering about the startup performance of dolphin. It is not "slow"(maybe ~0.5s), but just isn't as snappy as the MS File Manager (it just pop-up). Is there any plan to improve upon this area?

I know everyone is saying Windows is cheating and pre-load a copy of the File Manager. But then to be fair, even with a running Dolphin, opening an additional Dolphin window isn't as snappy.

I understand the maybe 0.3s difference won't save you any time practically, but the perception of whether KDE is "responsive" or not sometimes lies there...

Hi, is there any way to compile dolphin without animated icons? any line i can comment or remove? I'm asking because i want to experimenting a thing, not beceause i dislike the new animations(which are pretty awesome).