“As some of you who monitor the KDE news sphere may have noticed, there has been a recent addition to the kdebase module. The Dolphin File Manager has been added to complement Konqueror’s browsing capabilities. Read on for more information about this new File Manager and its relationship to Konqueror and the rest of KDE.”
Dolphin is looking good.
I don’t really like Dolphin as of yet. Too Gnome-ish for me
And I also got too used to konqueror’s photobook view. Thing is, although it’s fast and lightweight and supports kioslaves, I don’t think fragmenting kde’s file management is a good move. Maybe if it would be done as a kpart allowing it to be pulled into konqueror transparently and allowing the choice between konqueror’s default behavior and dolphin. That would be something I’d like.
I don’t see myself using it either, I like how konq can embed everything (why open another app to view that pdf I can view in another tab) making the computer truly network transparent by removing the application distinction between files on and off your computer (including www), however, if Dolphin stops people complaining about konq’s buttons and and niggles then I am all for it. Lets just hope that people don’t start complaining that “KDE includes TWO! file managers, OMG it’s like the sky is falling”
I will be happy.
Some of my initial concerns with Dolphin were resolved by this article, but some remain. KIOSlaves are nice, sharing code with Konqueror is nice, and I think the more structured view of the filesystem is nice. Trees are nice, but a breadcrumb are basically a tree collapsed into a one-dimensional path.
The only real loss of functionality might have been drag-n-drop into a directory along an orthogonal path, but from the screenshots and description, it seems like you might be able to do this using the click-hover behavior of the breadcrumb widget. I’m not sure if this functionality is replicated for the items in the resulting drop-down, but if these items also expose their contents when click-hovered-over, then you can drag-n-drop from wherever to wherever using the breadcrumb. Given the additional screen real estate saved by using the breadcrumb, I see this as a step in the right direction (if implemented as I described).
The part that doesn’t please me is the seemingly arbitrary decision to remove support for embedded viewers. Yes, I understand that Dolphin is supposed to be a dedicated file manager with widgets that aren’t appropriate for a file viewer. So what? If I want to view a file in Dolphin, remove the breadcrumb (and any other inappropriate widgets), and let me view the damn file! If I want to go back, I’ll hit the back button (or click on a bookmark in the left pane), and the file manager-specific widgets reappear. Simple, so long as these removable widgets are built as KParts.
I urge the KDE folks to be more dynamic with their interfaces. The infrastructure is there, why not use it to solve these real interface problems? Do you want the same interface for your web browser as you do for your file manager? Of course not. But it makes sense both from the perspective of both the developer and the user to have the same application (potentially even in the same window) serve both purposes.
There are only so many operations we do on a desktop computer: we find, browse, view, and edit data. Our application framework should support plugins for each data type, including how to assemble an interface for each supported mode of access. We suffer from having too many discrete applications that have overlapping support for data types and/or their relevant access modes. In the case of Dolphin/Konqueror, our primary problem is that we aren’t defining our interface based on whether the data is a file or a webpage and if our mode is browse or view. Of course this is a simplification, but you get the general idea.
> The part that doesn’t please me is the
> seemingly arbitrary decision to remove support
> for embedded viewers.
This is not an arbitrary decision. It is perhaps the most important difference between Dolphin and Konqueror. After all, Konqueror is essentially a shell for embedded viewers.
The various quirks which embedded viewers suffer caused frustration for a number of participants in a file browsing user interface study which was produced last year.
http://usability.kde.org/activity/reports/2006/filebrowsing.php
Opening files in separate applications is one solution to the problem.
This particular solution also comes with a very attractive plus point – a maintainer whose code contributions benefit many other KDE applications.
Improving the handling of embedded viewers is something that can also be done, although it requires:
1) A developer / developers who are willing and able to do the work.
2) Some fresh ideas on how to solve the problems.
3) Getting approving consensus for the proposed user interface changes.
4) Getting approving consensus for the proposed technical changes.
5) Time to do enough implement->test->adjust iterations to get a result ready to ship.
This is not trivial then.
And finally, I would anticipate resistance from the user-base which is sometimes very conservative with respect to user interface changes to an existing product.
And finally, I would anticipate resistance from the user-base which is sometimes very conservative with respect to user interface changes to an existing product.
True, but this can be easily alleviated by including both of them, which is being done. Those who care, will be able to use whatever they like, so I don’t really see a problem here. And however gnome-people wished it would be differently, switching file managers is not a hard thing to do.
All in all, time will show whether Dolphin will be taken in or thrown out. It’s good it’s available, and it’s good we can choose to use it or not.
After all, Konqueror is essentially a shell for embedded viewers. The various quirks which embedded viewers suffer caused frustration for a number of participants in a file browsing user interface study which was produced last year.
IMHO, this is the correct approach. If the embedded viewers have quirks, then this is a flaw in the implementation, not in the design. Usability studies are only useful if you can determine whether the underlying cause is poor design or merely poor implementation.
Let me put it this way. If the embedded viewers behaved as they should, then would the test subjects have had problems?
The part that doesn’t please me is the seemingly arbitrary decision to remove support for embedded viewers.
Well, you can bet they won’t do that since that would make Dolphin into… well, Konqueror
hmm, maybe taking the mac os idea of having all apps put their menus in a single bar to the logical “extreme”?
as in, dispense with programs altogether, instead turn them into package of functions that all work inside a single gui.
each time a file is opened a matching toolbar or toolbars are opened on the top area of the screen. or maybe borrow something from ms office and have said bars load as tool tabs. one for view, one for browse, one for edit and so on.
still, there may be some overlap between them. like say the rotation of a picture. should it be in edit or view? or maybe both?
hmm, tabs…
I’ll confess, I’m responsible for that article. Considering the sort of feedback that the dot is getting on this topic, I figured I’d take the opportunity to pre-emptively comment on some of the most commonly raised concerns:
1) It shares code with Konq. There is no real duplication of efforts as Konq and Dolphin both act as a sort of thin shell around underlying libraries. In fact, these libraries (such as the icon view, or the io slaves) are shared with the File Dialog as well.
2) It’s not an attempt to create a File Manager for dummies. It’s an attempt to create a highly specialized, powerful file manager that uses sane default setting (but is highly configurable) which has a low learning curve. It’s not designed to be a file viewer, like Konq is.
3) Konq is not going away. You can select Konqueror as your default file manager still, if you prefer it to Dolphin. Konq will still be configured as the default web browser.
4) According to its lead developer, it will get a tree view, and an embeddable konsole screen before 4.0 is released. Please keep in mind that this is a very early version, and that improvements will still be forthcoming.
That is all. Please feel free to check out the recent developer snapshots as well, if you’re interested in trying it for yourself.
Considering the thread at the dot, smart move 😉
TREE VIEW 🙂
So it finally made it in the minds of the dolphin devs. Great. Just that one feature that would stop me using dolphin. Hopefully Dolphin will be as friendly as Kong when I like to paste text of images into the file manager, asking me for a file name for the new content, or when making symlinks.
I guess you meant “stop me using KONQI” 😉
Anyway, I guess that kind’a thing will work, yes. Don’t they generally deliver nice code, these KDE guys?!?
Xfce saw this need and created Thunar. KDE sees this need and creates Dolphin. It is what users want. It is the trend.
Kudos for seeing the need and responding to it.
I’ve compiled Dolphin 0.8.2 from source (where are binaries for testers!?)and it fast. Really fast. That is good. Ftp support – good. No www support. It’s ok, we have plenty of other browsers. Will it replace Konq? No, it is not meant to replace Konq, but complement it.
Waiting for KDE4 impatiently…
P.S. Shouldn’t it be renamed Kolphin?
I’ve compiled Dolphin 0.8.2 from source (where are binaries for testers!?)and it fast. Really fast. That is good. Ftp support – good. No www support. It’s ok, we have plenty of other browsers. Will it replace Konq? No, it is not meant to replace Konq, but complement it.
Waiting for KDE4 impatiently…
Thats the whole point; seperation between the web browser and file browser rather than having a grand unified mess of code; have one tool that does a small set of jobs well rather than trying to touch base with everything out there.
IMHO they should have been more agressive and made a definate seperation like they have with GNOME and made it strictly a file manager alone and relegated Konqueror to just a web browser.
I’m sorry this comment is really unnecessary but I’ve just got to say
LOL KOLPHIN!
Okay, got that out of my system.
Guess where comp newbies Meka is? Yes, Desktop. Why we can not see Desktop’s icon? Yes, sure we can click on Home, and find Desktop there, but it would be VERY good to make it more visible.
Well, sucks then for KDE 4 newbies, as it probably won’t have a desktop. At least not one with icons and documents and folders on it… Documents belong in the folder $HOME/documents, not on the desktop. Applications should be started from an ALI (application launcher interface), not from desktop. etcetera.
Untrue. ~/Desktop is location like any else, and KDE will support it as long there are apps using it (like Firefox, which even defaults to Desktop for all downloads). Some concepts of Plasma might provide replacement mechanisms for Desktop usage, but not allowing users to keep files and application launchers would equal disaster.
Remember that it’s always about community and userbase.
OK, I admit, I was a little exaggerating 😉
dolphin as default file manager – looks good
As a filemanager Konqueror is great.
They should have created a web browser component instead.
I’ve used KDE as my desktop for 4 years or so now. Doing so has its downsides, like frequently hearing how KDE is bloated, how no commercial apps are made for it, how no major distros use it by default. It can be hard to find KDE apps for some things, and I have to use out of place Gnome apps.
I’ve found it worth it though, since I liked KDE’s focus. I like lots of buttons and configurability. I liked it for the same reason Linus does, though I don’t subscribe to his flipside of then criticizing Gnome.
This whole Dolphin thing though is leaving me with a feeling I can’t shake, that KDE has jumped the shark. I’m not saying it has, just I get that impression. Naturally I’ll wait and see how things pan out, but I’m not excited for KDE4 anymore.
If I’m going to have to deal with interface changes recommended by usability studies (which always seemed to be aimed at people who don’t actually use the interface yet, but we’d like them to someday!) and a constant push towards simplification, I might as well use Gnome. At least then I’d be using the DE that for some reason gets wider support.
Things like the new koffice opening dialog were just the beginning for me I guess. http://bugs.kde.org/show_bug.cgi?id=121233
That bug doesn’t have a lot of votes, so perhaps folks don’t care. I may very well be in the minority with my distrust of KDE’s current direction, and that’s fine. I’m only conveying my worry it doesn’t seem like it will be worth it for me anymore. I’m done asking for a tree in Dolphin. Let the chips fall.
You know a good file manager? 2xexplorer.
> I’m done asking for a tree in Dolphin
one was committed to svn today.
Aaron, you’ve gone way out of your way to be civil to me and answer questions, even as I rant. I really appreciate it.
I think I’m just in a bad mood because I’m not seeing the big picture. I can’t decide if I dislike the idea of another file manager, dislike the idea of it not going far enough in taking over file managing, or what. That and usability studies make me cringe, as I never seem to like the results.
I just need to step back and breathe for a while, knowing Konqueror will still be there whatever happens.
I’m almost sorry a treeview is in there now
I’m going to try to train myself to wait and see how things turn out instead of agitating from the outside for pet features. If you guys have a plan, stick to it and don’t let the whiners influence you too much. Just don’t give us a Deus Ex 2!
…why in god’s name would it be Finder?
Blech.
What I don’t understand is why Dolphin design could not been done modifying konqueror while still maintaining konqueror functionnality.
Having 2 file manager is strange.