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:
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."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."
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 :-)
86 comments:
Sounds great!
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.
Great to hear! I am really looking forward to these improvements. Is it going to be possible to install this independently of KDE trunk or will it depend on changes outside of dolphin?
Is this also going to allow collapsing groups? Is it going to fix the issues with keyboard navigation when grouping is enabled?
@ anonymous: I assume you are not using the breadcrumb mode? If you are, you can just drop on the breadcrumbs.
@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.
@Peter: This is great news. Dolphin is already a great file manager, but this plan seems to make it flawless (with maybe on exception, see below). Thank you. :)
@Click: I agree that it is really nice not to have to click on the icon itself, but on a larger tile over which icon and text are drawn. I agree that is is very intuitive and better than in KDE 3.
@Anonymous: You can already drag a file or folder as you desire: drag it onto the parent folder in the URL bar. Done. :)
@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?
Yes :-)
@ 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.
@Anonymous:
> Any chance this could also involve
> adding a virtual folder ".." for
> the path above the current folder?
It is not planned at the moment, as this is a very rarely requested feature (my personal opinion about this is that the breadcrumb should be used for dropping instead - like mentioned by todd already)
Ah nice! I noticed this today while browsing folders, but wait, how do I select multiple items?
@Shantanu:
> Ah nice! I noticed this today
> while browsing folders, but wait
> how do I select multiple items?
Selecting items currently does not work at all but will be reactivated again during the next months. The code is really in a very early stage and basic functionality has been deactivated temporary.
Thanks for your commitment, Peter, this is really great news, as this addresses *all* my concerns regarding Dolphin !
I didn't know those issues were mainly due to QT classes themselves !
Thanks again !
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?
Thanks !
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 :)
@Anonymous:
> Will these changes also support
> dynamic column widths, so I can
> see the whole filenames?
Yes :-)
@Kai Uwe:
> No, it takes forever for the
> previews being re-loaded which
> is just unacceptable. A
> bettercache 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.
"So the hovering only takes place when the mouse pointer is above the the icon or text like in KDE 3"
But doesn't that make the floating icons (select/deselect) more difficult to use?
@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 :D
Only 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
@Kai Uwe:
> I just tested Dolphin on master.
> AWESOMLY FAST! Go for it! :)
Great to hear, thanks for testing!
> Only thing: It seems not to
> continue generating previews while
> you’re scrolling.
That's intended to keep the user-interface smooth during the scrolling.
A few questions.
Will this port to systemsettings? Systemsettings interface with asia character long time suffers from too narrow text... Seems this would be great for systemsettings item text.
And another question will this work depends on Qt 4.8?
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.
Apart from kde-baseapps do I need to compile anything else to try this out? What about Itemviews-NG (is that external dependency or is it included in the initial dolphin 2 patches?) and Qt?
Please give me a prompt advice or I will commit a suicide. TYSM
@csslayer: Try using the settings protocoll (enter settings:/ into your dolphin adress bar). Unfortunately it’s kind of unsorted but yes, systemsettings is a bit weird.
@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!
Great work!
I can tell you it compiles under KDE 4.7, and at least the speed improvement in loading huge folders works like a charm!
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 really hope someone will be interested enough to develop it.
@ Kai Uwe & Alessandro Sivieri
Thank you guys but I'm afraid you sent your posts too late. No, no: I'm still alive:
https://picasaweb.google.com/lh/photo/j_BkeWMGw8glqb-kEktYMQ?feat=directlink
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..
Right, since I have calmed down a bit:
1) missing 'copy' and 'paste' entries in dolphin file/dir context menu
2) cannot drag files/dirs between dolphin windows
@ Kai Uwe: what, specifically, did you do to the cmake file? And what commands did you use when compiling? I tried it and it said there was no make target "install".
@toddrme2178:
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr (I used /opt/project-neon since I use project neon which provides daily KDE builds)
make
sudo make install
that did the job for me?
@ Kai Uwe: That's what I did to. What specifically did you change in the cmakelists files?
@toddrme2178
RE: no target 'install'
Did you run cmake first?
These are the usual steps when building with cmake (assuming you already have necessary build deps installed):
1) create 'build' (or whatever you want to name it) subdirectory in the top level source repository directory
2) go to the build dir and run:
[b]cmake ..[/b]
or ..
[b]cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`[/b]
.. if you want to make sure that the application will be installed (after compiling) in the default KDE installation directory
3) (while you are still in the build dir)
[b]sudo make install[/b]
4) (optionally, to update KDE's system configuration cache)
[b]kbuildsycoca4[/b]
@toddrme2178
Sorry about the [b][/b] tags. I thought that blogger uses BBCode but I was wrong. I should have used html tags instead to bold the text. I'm pasting corrected text below:
1) create build (or whatever you want to name it) subdirectory in the top level source repository directory
2) go to the build dir and run:
cmake ..
or ..
cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
.. if you want to make sure that the application will be installed (after compiling) in the default KDE installation directory
3) (while you are still in the build dir)
sudo make install
4) (optionally, to update KDE's system configuration cache)
kbuildsycoca4
@toddrme2178
Dunno what the hell is wrong with me today. Obviously between cmake .. and sudo make install you need to run:
make
or (if you have a multi-core cpu, to speed the compilation process up):
make -jn
(where n will be a number of threads; let's say that for a dual-core cpu -j2 or -j3 is pretty safe; I don't go above -j6 on my quad-core)
Yes, I ran cmake before. I think there might be an issue with the cmakelists file, which is why I am trying to figure out what changes other people made to it.
I didn't make any changes in CMakeLists.txt so I've built all components and I didn't come across any issues.
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).
@Peter:
Sorry, I wasn't clear about this and used some wrong words.
>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
Wonderful work! I can't wait for this to land.
Yay! Unclipped filenames has been my biggest pet peeve since forever, and you've now got it fixed. Awesome. Thank you!
@ 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 :)
@toddrme2178
I've tried myself and it worked successfully. Simply I removed these lines from CMakeLists.txt ..
add_subdirectory( kdialog )
add_subdirectory( keditbookmarks )
add_subdirectory( konqueror )
add_subdirectory( kfind )
add_subdirectory( plasma )
add_subdirectory( konq-plugins )
.. leaving these:
add_subdirectory( lib )
add_subdirectory( dolphin )
Then just standard configuration and building.
I guess that lib must be built in order to build dolphin (and any other components from kde-baseapps) and that's why I didn't remove that line. But maybe I'm wrong and you could remove it as well..
Great news! Interesting dude...
Thanks for sharing informative news.
Hello Peter!
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.
Regards,
thorGT
So many comments, I hope I did not miss one question:
@csslayer:
> Will this port to systemsettings?
At least not for 4.8, as I need to take care that the API gets stable first before making it public.
> will this work depends on Qt 4.8?
No, Qt 4.7 is sufficient.
@Bigbrovar:
> One thing dolphin (and I say the
> rest of kde systemwide) needs is
> support for smooth scrolling.
Smooth scrolling is planned for Dolphin 2.0.
@Ignat:
> 1)Is the Itemviews-NG *not* an
> official Qt library?
No, it's only a research project that has been cancelled AFAIK.
> 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.
Thank you for the quick answer :)
>that has been cancelled
If that's the case, do you know what's going to replace the Interview in the future? It sounds a bit irrational for Qt to invest time into IV-NG and then trash it.
>I took mainly the concepts and the interfaces
Do you mean that you have written a Model-View framework yourself from scratch? :)
Also, does the port described in this post affect both the Model and the View or the View only?
Regards,
thorGT
@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?
It affects the model, the view and the controller.
Wow! Is this going to fix Bug 275398 - "Dolphin truncates file names in Icon View set on columns and zoom level at minimum" too?
Also, how about a quick switch to a compact list that works like in File Open? "Bug 275357 - Dolphin needs a Compact List view identical to the Short View present in KDE4's File Open dialog."
Thanks!
@Béranger:
> Wow! Is this going to fix Bug
> 275398 - "Dolphin truncates file
> names in Icon View set on
> columns and zoom level at
> minimum" too?
Yes!
> Also, how about a quick switch
> to a compact list that works
> like in File Open?
Fixed too already :-)
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.
Heya,
Very cool to see a usage of the framework, I actually got an opportunity to use it at work in a product we are developing recently too and I noticed that it still has several issues.
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.
Thomas Zander
@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 :)
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?
@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 ;-)
Peter, I believe the following Dolphin bug needs some love:
Bug 265657 - "File Already Exists" dialogue window is too small to display useful information.
What do you think?
That isn't really a dolphin bug, it is a kio bug. It is part of the system underlying dolphin, konqueror, the file open/save dialog, and numerous other things.
It looks like KDE is slowly becomming really great. Time to rewrite everything and start from scratch with KDE 5 :) We linux users don't really need a great software...
I have openSUSE in one of my home directories:
http://download.opensuse.org/repositories/home:/TheBlackCat:/kde/openSUSE_11.4/
It is building dolphin alone against existing KDE releases. However, it only builds for KDE 4.7 and later versions of 4.6.
Let me know if there are any major updates and I can pull in a new git revision.
Thanks for your good work, Peter.
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.
Greetings, and again, thanks for yo great work! :)
Javier.
Here is small video.. This is great!
http://www.santyago.pl/blog/read/2011/08/06/kde-4-8-mala-prezentacja-dlophin-2-0.html
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..........
Kind regards
JBT
^ bump ^
:)
@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.
scrolling through the items mainly, but it also uses a vast amount of ram apparently (2GB sometimes).
cheers for the info.
That's awesome! I wish the code could enter Krusader as well.
P.S. A humble feature request: would you please add the "Send by E-mail" option to the context menu? Thank you!
@slonoinquisitor:
> P.S. A humble feature request:
> would you please add the "Send by
> E-mail" option to the context
> menu? Thank you!
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.
I just upgraded to Kmail 2 to find that you are right, and the option is already there. Thus, the FR is closed. Thank you once again for your wonderful work!
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...
Anyway, good luck for 2.0 :)
id3 support should be given to columns.
please preview :http://en.wikipedia.org/wiki/Id3
Any news regarding Dolphin 2.0?
Oh I so much hope the animations speed can be tweaked.
For senior users the animation is just too fast! And for young and experienced users it can be too slow or even just on the way.
So make the animation speed possible to be configured from 2 second to 0ms.
Seniors have time and will power to wait, it is better to them that they see the animation so they can understand it, than it is just bling bling as for young users or experienced.
This is great, thank you for all your hard work on Dolphin, Peter!
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.
The bug is still here on 4.8 RC1 :)
@Azou:
> The bug is still here on 4.8 RC1 :)
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 :)
Regards,
Vladimir
How do I make Compact View the DEFAULT for "virgin" directories that have never been visited with Dolphin 2.0?
@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 need contact the author of dolphin to have interface with my software (Ultracopier), can you contact me? See all my contact info on the contact page.
First, thanks so much for all the wonderful work....
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...
Don't get me wrong, I'm definitely a happy Dolphin here :-)
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).
Post a Comment