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.
A brief history lesson so you can get an overview of how file management has evolved with KDE: In KDE 1.x, KFM (the KDE File Manager) was born. It was a very rudimentary, very basic file manager with limited web browsing capabilities. Below is a shot of KFM browsing files (from the kde.org screenshot archive) so you get an idea of how it operated.
While it's obvious that KDE has come a long way since KDE 1.x, it is still easy to see which parts of KFM have inspired Konqueror's contemporary design, which was introduced as part of KDE 2.0. KParts technology revolutionized the way we used our File Manager application, turning Konqueror into a full fledged web-browser, and more. Here's a shot of Konqueror from KDE 3.5.6, and you can see that while the user interface is much improved, the same basic concepts remain visible from the KFM days.
Konqueror really shines as a beacon of KDE technologies in the KDE 2.x and 3.x series, showcasing the best parts of KDE technologies. Konqueror showcased the power of KDE's IO slaves, allowing true network transparency when managing your files over FTP, fish (SSH), HTTP, and much more. Konqueror is so advanced that you can enter an FTP URL into a HTML upload form and it just works as you would logically expect it to (as far as I know, it is the only browser which allows this). It also featured KParts, which allowed it to embed just about any sort of viewer required, directly into the interface, embedding things like KPDF, KWord, image viewers, and most importantly, the ever-improving KHTML page renderer. This is important, since even Konqueror's icon views were implemented as pluggable parts, making just about any kind of icon view possible.
So, Konqueror is a really powerful tool that can do just about everything you and your system can possibly want, and with this power comes unlimited configurability and extensibility through control modules and plugins. However, what often happens in Konqueror when you are browsing the internet is that Konqueror still wants to behave as a file manager and not a web browser. This split behavior is easily noticed through elements such as toolbar buttons. For example: the "Up" arrow is still available on the toolbar even when browsing Google Maps, but it is totally irrelevant in this context; another is having a web bookmarks toolbar visible while sorting icons in your /home folder.
Introducing Dolphin: Dolphin is a new File Manager for KDE 4 which is dedicated 100% to file management, and is not intended to be a one-size-fits-all tool as Konqueror currently attempts. It is intended to optimize your file management related tasks, and present an easy to use file manager for casual KDE use. That doesn't mean it won't be powerful or configurable, only that Dolphin is being built for a single purpose.
Dolphin isn't a total rewrite however, and is not intended to compete with Konqueror, rather the two applications will be complimentary. Dolphin uses the already existing IO slave facilities of the KDE platform to perform remote or local file management, meaning that it will be capable of doing all of the 'remote management' type activities that Konqueror has already matured. Dolphin just won't show web pages or PDF files embedded as Konqueror does.
And Konqueror will benefit from Dolphin as well. Konqueror is not going to disappear for KDE 4, although its user interface may yet see some adjustments as its primary utility will not as the default file manager. Of course, Konqueror will still be available for file management tasks as it has been in the past - there will be no changes in this regard. Changes made to KDE's icon view parts through the development of Dolphin will also help to improve Konqueror's icon views, as they both share these libraries. As stated before, Konqueror loads all of these icon views as pluggable libraries called KParts - improvements to the underlying KParts automatically benefit all users.
So lets take a look at Dolphin and Konqueror as they currently exist in KDE's Subversion repository. Please keep in mind that these snapshots represent developer work-in-progress builds and, while publicly available, are not representative of the final appearance or intended functionality of either applications, nor are they recommended for everyday use.
Konqueror currently looks something like this, and the icon views only half work. The problem is that these file views are simply direct ports of the KDE 3 codebase. Konqueror will eventually receive the same fileviews that Dolphin is currently using.
You can tell from Konqueror's default configuration of using tabs, and various other related interface choices that Konqueror is now mostly a web browser that also happens to do file management. While Konqueror's roots are truly derive from file management, it is more frequently operated as a browser these days by many KDE users. Konqueror does a great job as a web browser, underpinned by the fact it now implements CSS 3, including the highly-anticipated 'opacity' tags.
So while Konqueror continues to improve as a browser, it will continue to maintain KDE 3.x file management standards, providing a baseline functionality, and will be improved as code is shared between itself and Dolphin.
Dolphin is a whole different animal. It is a 'real' file manager - it's interface has a lot of elements which are specific to a file manager and cannot really be justified in a browser. This is best demonstrated with a screenshot.
Notice the implemention of a 'breadcrumb'-style directory selector, which works well for file management in a lot of cases, but is totally useless if you need to enter a URL when using a browser, and so becomes the sort of widget which is only useful when dealing with file hierarchies. Breadcrumb widgets may be familiar to anyone who has used OS X's Finder or GNOME's Nautilus. Another comment about the above screenshot: clicking and holding a breadcrumb item displays a list of directories that are at the same level as the one clicked, allowing for more efficient navigation.
However, using the breadcrumb widget is not essential, and if you are more comfortable with a Konqueror-style location bar, this mode of operation is easily configurable, as seen above. In fact, much of Dolphin is configurable, illustrated below.
This screenshot evidences the amount of effort KDE is spending trying to make configuration layouts sane while still providing as many options as reason allows. Also note the improved appearance of the configuration dialogs in KDE 4. Of course, this is going to be revisited somewhat as the dialog is too tall for some screens at the moment. After the Oxygen visual components go live, this dialog will be even easier on the eyes.
So, Dolphin's functionality is not entirely new, other than it presents itself in a new way. It can be seen as a hybrid between the power of Konqueror and the structure of Nautilus. Dolphin still builds on a strong KDE base, reusing existing technologies like KIO slaves and so forth. Right-click actions that were available in Konqueror will still be mostly present (except that Dolphin will necessarily load files externally instead of using embedding viewers). And Konqueror can now improve its web browsing experience even more, doing so without losing the file browsing support that has been there since KDE 2.0.
When KDE 4 is released, Dolphin will be configured as the default application for the local file:/ protocol, as well as the default file manager listed in the applications menu. Konqueror will ship as the default web browser, and will still be usable as a file manager to those that prefer the historical lifestyle. Users of KDE will have the ability to set the default file browser, much like how KDE 3.x can use third-party applications such as Krusader as the default file manager. Stay tuned for more information as Dolphin and KDE evolve towards 4.0.
Firefox may have started as a 'lightweight gecko browser' but it definitely is not lightweight anymore :) If we do the same thing to KHTML, it'll eventually end up as heavy as Konq is anyway.
Right, people will continuously ask for new little features until it's not a lightweight browser anymore, and if new features aren't added for the sake of staying "light", the browser will be criticized for not having sexy features. It's a no-win for developers. The combination of Konq and Dolphin should satisfy everyone just fine.
So the light browser of yesterday grows heavy, creating an opportunity for a new light browser to start. The browser renews itself like a Phoenix ;)
...then changes it's name - at least twice ;)
You could just ship official pluggins that are disabled by default, letting people chose their weight.
"But, I see one problem with this setting. There isn't an easy to use browser for KDE. One that takes away many of the less used functions but offers a better usability."
Konqueror _is_ easy to use. Its usability is great in simple web browsing. I did put it under some "powerless users" (because if there is power users, then there is powerless ones) hands and they were very successfull with it.
One tool for one job. I like this idea. That's why I do have two konqueror windows open. One for web-browsing, and one for file management (maybe I should switch over to dolphin or krusader). I nerly never mixed those two modes in one window. And I always start separate programs (kpdf, gwenview, ...) for viewing filecontents. That's why I'm very pleased with the decision of having a dedicated file manager.
So having a dedicated web browser would be a logical step. I would really appreciate such a program. And it should use webkit (well - a webkit/khtml unity). Always synchonising webkit and khtml is a waste of resources. One codebase would be a real benefit.
An easy way to start such a progam could be to streamline konqueror (web-mode). My first starting point would be the settings dialog (removing all file management elements).
I'm not sure I agree...
If by "real browser" you mean HTML renderer only, I can't agree. There are many pages out there that have links to FTP sites. And when you click them, what do you expect to see?
1) a new window gets opened and you see your file manager
2) you see an HTML rendering of the contents, with very little that you can do there
3) you see the FTP contents like your file manager, but in the same window
My personal preference is #3. I don't see why Konqueror shouldn't load the file listing parts to display FTP.
My personal preference would be #1
#2 is very limited (can be seen with firefox)
#3 desires a full file management. Ok, it currently exists and is nice. But at the costs of bloat of konqueror. And yes, konqueror is (after several trimming attempts) still bloatet (best example is the settings dialog).
Well, in KDE 4, you can have #1 (default) and who wants it can have #3. Isn't KDE great?
I think there are two very different usage patterns for FTP:
A) to download files from (read-only access)
B) to manage files on a remote server (read/write access)
For type B I agree a file manager is more useful than a web browser. But for type A switching to a file manager interface is not useful, since the user is not planning to manage files, only view or download them.
What make ftp so much different from NFS, SMB or AppleTalk?
Aren't they all invented to access remote files? Why bothered at the first place to develop NFS to make remote files feel and look like local files?
And please think again why we now have 'fuse' to mount wdav, ftp, ssh, tarball and even svn so we can access these contents in our familiar file manager?
#1 is how it is handled on Mac OS X: you click an FTP URL in Safari, it is added as a location/mount and a Finder window is opened. It works, but the switch to a different application feels a bit weird to me.
Since both Konqueror and Dolphin would be using KIO and thus have to ability to handle FTP, why not simply open FTP URLs in the same application in which they are activated? So if you click an FTP hyperlink in Konqueror, the site is opened in Konqueror (#3), but if you type an FTP URL in Dolphin, it is opened in Dolphin.
Is a left-pane Tree View planned? I think a Tree View is the #1 requirement for a file manager -- it makes orienting through the filesystem hierarchy and moving files around so much easier.
I'm looking for this feature as well. The breadcrumb widget is good for navigation, and the split view for moving files from one directory to another. But I don't think it's a power user thing to be able to drag a file/directory directly to another directory, right?
As Dolphin still isn't in its final form, I'm hoping to see more changes soon.
Hm, how about allowing the user to drag into the breadcrumb?
Of course it would also need a way to navigate into sub-folders while dragging like Konqueror works today.
Also, it should be possible to drag from any part of the breadcrumb.
Nice idea's, I hope the dolphin dev's pick it up. Anyway, treeview is coming ;-)
I've never used treeview in all my life in a file manager and I'm quite happy with it. So your #1 requirement is not mine.
There is a reason if in every file manager treeview panel is hidden by default (if present at all)
Yes, it is planned to support a tree view in Dolphin (an additional dock will be offered). It seems to be one of the most requested features :-)
I hope that Dolphin's treeview will recognize the main view such that if I change the directory in the address bar, the tree view autoamtically changes as well.
This is the only thing bugging me on konqueror which does not recognize anything.
I can't reproduce this behavior in Konqueor. If I click on a folder in the main view, the tree-list view changes to the appropriate folder as well. Same thing if I type in the directory manually in the location field.
KDE 3.5.6 Kubuntu 6.10
It does not work:
Ok, Home-Folder Tree view seems to work, but not:
o switching to upper directories does not switch to "root folder view".
o switching KIO-slaves does not update the tree views (for examples in the service->media tree on "media:/...path/")
I can reproduce the problem in Konqueror where changing the location in the URL field doesn't update the tree view on the left. I think part of it has to do with the "Home" sidebar being selected, as opposed to the "Root" sidebar. For example, /tmp is not under "Home", so there is no /tmp node to highlight.
I think this whole problem can be resolved if there is _NO SIDEBAR_, but instead just a Tree View with a root node at "/". Kind of like MS File Explorer does it.
One year on:
Thanks a lot for this you jerk. Dolphin's dirtree now changes it's (undisplayed) root depending on where you are in the filesystem. So it's basically impossible to use it to copy things from one device to another.
Old way: Be wherever in the filesystem. Type in a location on a different device. File pane goes there but dirtree doesn't react so you can copy a file from the file pane and paste into a folder in the old location.
Impossible now. Typing in a location isn't available by default. The dirtree changes its (non displayed) root so you can't paste to the old location, but that's ok since you can't paste things in the dirtree anyway.
Dolphin is ass.
Also when you browse to a hidden directory, Konqueror's tree view can't follow you.
Another missing thing from Konqueror's tree view is the ability to rename a folder pressing 'F2'. It's often annoying to have to click in the right view just to rename a folder when you already have it selected in the left (tree) view.
> Yes, it is planned to support a tree view in Dolphin (an additional dock will be offered). It seems to be one of the most requested features :-)
Great to know! I don't think there's a need for multiple hierarchical trees like the "Home" and "Network" in Konqueror. But I definitely like Simon Edward's idea __and patch__ for how to integrate KIO slaves into a single hierarchical tree:
Could this be used in Dolphin?
This is basically what Nautilus does. Not Dolphin though.
I use the TreeView a lot too. I would really miss it in a file manager like dolphin. The only way I don't miss it, is a MidnightCommander/Krusader like interface.
Having a TreeView should definitely be an option.
I'm in the other camp. I keep the left pane tree view turned off 100% of the time, as I consider it a nuisance and of limited use. Konqueror's split panels are many times more useful and powerful. Split panes give me a much bigger target when moving files around, while the tree view is more like trying to hit the head of a needle from the roof of a two story building.
For me file manager is one of the center key item of an os and I could not imagine working with files without a tree view. Konqueror tree view is great and as I was reading that Dolphin was to become next default file manager of KDE I had to try the current version and I was shocked to find out that there was no tree-view.
Then I searched some and found somebody mention here that tree-view is under construction in Dolphin - what a great news! Otherwise Dolphin seems to be a very lightweight and promising tool for managing files and I'm sure it will get alot of improvement before we will see it with KDE4.
I have literally *combed* the internet looking a file manager I could use on Linux that has a tree view.
Having come from windows (read explorer) years ago I was looking for something that had the same functionality, tree view to the left that had Local folders, network folders, hot plug and devices all at the top level and drillable. I was *amazed* that of the *dozens* of file managers *none* seemed to do this. Then I finally discoverd that with configuration Konqueror could at least almost do this , but in a fragmented fashion, arrrghh! wtf. How can there be two dozen fms that do twin pane view but no *decent* tree views?!!?
To date I have found nautilus's tree view (ugh), Xandros done well but only on their system (ugh),thunar now on the scene, is the closest thing to a tree view that roots a top level for the main areas, home folder, system folders, and media.
For the love of all that is holy, *i* *am* *begging* you, please make your tree view a 1st class citizen.
It makes me *shudder* to cite anything windows as a positive example, but if you will make a tree view as functional as Explorer or Xandros fm, I will wash your car for the rest of your life, I will pay cold hard cash, seriously name a bounty and I will attempt to raise it. You need anyones legs broken I'm your man.
Just name it.
And to the people that feel a need to post to this thread to say that they don't want/need a tree view because a twin pain view is sooo much superior, I want to reach right through my monitor and strangle you all.
YOU ALL ALLREADY HAVE *DOZENS* OF FMS TO CHOOSE FROM! STOP TRYING TO DISCOURAGE THIS!!!
Sorry for the shouting, my doctor says I am making progress. :)
But seriously, I am begging and I will raise a bounty.
just say the word.
Will you really...:)
Well, there's always Konqueror! It still has its file manager part working in KDE 4.1. And guess what, just like in KDE 3.5, it STILL has tree view in KDE 4.1!
Here's how to get the tree view in Konqueror:
1) go to file manager mode (not web browser)
2) in settings menu, enable navigation panel
3) click on the red "root" icon
4) tadaa! tree view
I'm using Konqueror instead of Dolphin now, I mean, I didn't find the same in Dolphin, and this is near august 2008 instead of the 2007 where this thread started...
Konqueror still rocks!
It ***IS*** available in the current svn. Just right-click on the top of the 'Places' bar and choose 'Folders'.
Finally! :-) The problem with just one tool for different purposes is that it's extremely difficult to apply security mechanisms such as AppArmor or systrace. I really want to be able to restrict konqueror with some good profile in systrace or AppArmor but in that case it becomes useless as filemanager. Now Dolphin can take over that part! Great work!
But you'll still need abilities like "Save Image As..." and printing to PDF in a web browser, so it should not be completely isolated from the local file system. Maybe it could use some kind of internal privilege separation though.
The solution klik and zeroinstall might use, where the file save dialog is actually another application granting access to the file the user selects is imho pretty smart. Find more info on http://plash.beasts.org/
I think Dolphin could add file metadata editor or color tag feature for usability.
A whole Nepomuk project working on it ;-)
Speaking of khtml.. what's the status of merging webkit?
Webkit and KHTML share code back and forth. Basically, Webkit is KHTML but with all the Qt and KDE library calls being abstracted away. So, other than that code, the rest is shared pretty easily between the two projects. As improvements and fixes hit Webkit, they make their way into KHTML as well. And vice versa.
So, Konq using webkit would actually be a disadvantage, since we'd basically be abstracting away our own Qt and KDE library calls. Using KHTML makes more sense, as we can then do things like the above mentioned trick, letting you put ftp or fish urls into an HTTP upload form. Using webkit, this would probably vanish.
Rendering components are almost entirely shared. Many thanks to Apple, Nokia and other webkit using organizations for remaining true to the open source community.
> Webkit and KHTML share code back and forth
yes. they also don't share a lot of code back and forth.
> As improvements and fixes hit Webkit, they make their way into KHTML as well.
> And vice versa.
this simply isn't true. bug compatibility is another big issue as the diversity there makes it harder for web developers to produce sites that work with khtml.
> we'd basically be abstracting away our own Qt and KDE library calls
the overhead of this is negligible and is dwarfed compared to the benefits gained from a single code base. e.g. more developers, a larger user base, more websites tested against our browser, etc...
> Using webkit, this would probably vanish.
> Rendering components are almost entirely shared
it's not that close.
I stand corrected :)
>> Webkit and KHTML share code back and forth
> yes. they also don't share a lot of code back and forth.
Both statements are wrong.
Code is routinely merged back from WebKit to KHTML.
In contrast, code is never officially merged from KHTML to WebKit, because of the strong corporate NIH syndroma that dominates the WebKit project.
WebKit people do take code from KHTML tree from time to time,
sadly they just never give proper attribution as we do.
>the overhead of this is negligible and is dwarfed compared to the benefits
>gained from a single code base.
This is a silly dellusion.
A *single* code based is not a *shared* code base.
Apple owns WebKit.
Wrong. There are a number of very well known KDE/Qt developer's with full commit and review access to WebKit.
Full commit and review
Lars Knoll (original creator of KHTML)
Full commit and review to Qt port
This can only improve if more KHTML developers get involved with WebKit!
don't get things all mixed up.
Having Qt be the only portable backend for WebKit (as the win port and the gdk port are basically dead now) is attractive for Trolltech.
So of course they are going to have a few people hanging around.
They do want WebKit to work with Qt.
They even opened a 'Trolltech lab' page just for it.
However those commiters, from their own admission, have absolutely no bearing on the project. They can't decide anything, just like Nokia.
Everything is owned and steered by Apple.
People should just understand once and for all that WebKit is an external project that has no relation with KDE whatsoever.
They might produce a great browser working in KDE4, and that'd be swell and all.
But in no way does it invalidate the necessity for KDE to ship it's own independant engine.
"Having Qt be the only portable backend for WebKit [...] is attractive for Trolltech."
And for KDE as well. And make no mistake, the Trolltech folks are just as interested in the benefits to KDE as well as Trolltech. Look in the svn repository and you'll find a __WEBKITKPART__!!
"However those commiters, from their own admission, have absolutely no bearing on the project."
Not so. Lars Knoll has full commit and review access. And the views and insight of these developers IS being heard and addressed. See the recent thread on webkit-dev for instance.
"People should just understand once and for all that WebKit is an external project that has no relation with KDE whatsoever."
Then what on earth is the WebKit KPart doing sitting in Apple's svn repository? And why are _KDE_ developers actively working on it?
"But in no way does it invalidate the necessity for KDE to ship it's own independant engine."
Maybe not right now, but who knows what the future will hold...
> See the recent thread on webkit-dev for instance.
nothing new there.
> who knows what the future will hold...
my thought exactly.
> code is never officially merged from KHTML to WebKit,
pot, meet kettle. how many times have we seen webkit patches rejected because they aren't "good enough" and then reformatted / rewritten? it goes both ways and both projects have their own internally consistent reasons for doing so.
> WebKit people do take code from KHTML tree from time to time,
> sadly they just never give proper attribution as we do.
i hope you're not claiming they strip copyrights. that said, instead of trying to find one place everyone can work together you're using it as a reason to keep the non-functioning status quo. which seems amazingly .. odd.
> A *single* code based is not a *shared* code base.
you're right. but it can be. unfortunately:
> Apple owns WebKit.
that attitude will prevent you from being part of that solution. it's not that apple doesn't "own" webkit, it's that using that as a final destination description is defeatist and unnecessary.
when those working on unifying things actually arrive with their working solution after all that effort, i really hope we are all able to recognize it.