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.
I've been using KDE from the beginning and I've always preferred it comparing to GNOME not only by the added functions but also by what I perceived as well thought and integrated decisions on his architecture.
However I don't understand this decision of splitting Dolphin and Konqueror and in my opinion is a clear "shot on the foot".
I don't understand why the decision is not to improve Konqueror as a file browser, making it more flexible and correcting the shortcomings found now, and instead to add "noise" with another file browser.
More, as a user in my daily work, I frequently need the full power of Konqueror both as a file browser, web browser, ftp browser, etc... AT THE SAME TIME (most of the time splitting it in multiple windows). Also is quite convenient (and faster than open a dedicated application) to look at a file directly on Konqueror.
From what I understand Dolphin will be "fancy" but won't support that. At same time I feel that, with time, Konqueror will lag behind as a file browser.
Probably, if this happens, I will switch to a browser that will still give me all that (maybe in GNOME?).
Another consequence of this (bad) decision is that a good number of users will switch from Konqueror (as an all-browser) to Dolphin + Mozilla and drop Konqueror! In the medium term this may slow down the development of Konqueror.
Konqueror does need some improvements (KHTML is not yet able to see some pages - in this case I still need Mozilla). I.e. I would like to remove Mozilla from my disk if possible (one less fat software). But I don't think this is the good way of doing it...
"Just my two cents"
"I frequently need the full power of Konqueror both as a file browser, web browser, ftp browser, etc... AT THE SAME TIME (most of the time splitting it in multiple windows)"
And what if those windows all have different names?
I mean I too need the full power. But I don't need all the power from one single application. I prefer separate applications, concentrating on theris specific task. And have them working together.
If you really want konqueror to do everything, why not extend it to be a music manager too? And another kpart/profile for photo management? And CD buring is a must for a "do-it-all-konqueror". And shouldn't konqueror be able to act as email client too? What about calendaring? Calculator? Games?
Why not rebuild KDE to consist of only one application (konqueror) with hundreds of profiles?
Browsing the web and managing files are completely different tasks (from a user's point of view). And every task should be best done by an application concentrating on this task (one job, one app).
KDE's benefit would be to provide superb integration between these applications.
"(and faster than open a dedicated application)"
Starting the KPart takes more or less the same time. That's my experience...
"Dolphin + Mozilla and drop Konqueror"
I think most people like this, already use konqueror as file manager, and Mozilla as browser. I doubt konqueror will loos users.
Part of the problem is that Tabs are much better at keeping your workspace organised than the taskbar, both visually and in terms of usability. Therefore it is advantageous to have all your workflow views within one application than in separate ones.
Wait...Dolphin won't have tabs? I hope I'm just reading into that the wrong way...
I totaly agree.
when I update my blog, I have 3 views at the same time:
- a web view for the ticket
- an ftp views for content like images/videos/flash players/...
- a local filesystem view
I drag local files to the ftp and ftp files to the blog ticket so I have the URL immediateley.
Having profile according to directories would be even better! That would be the kick ass feature!
- enter the Picture directory and you have the kio_digikam
- enter the Music directory and you have the kio_amarok
- enter the PVR directory and you have the kio_kaffein
- enter simple directory and you have your files
Of course, the profile would not change according to dirnames, but according to a .directory file or such. some default created directorys could contain preset profiles like ~/Music ~/Video ~/Photos, but it shouldn't be hard-coded.
This is a seamless way to represent data. end users want to access data and don't want to bother what app is apropriate for that!
If only I had coding skills.......
"End users want to access data"
I totally agree!
"and don't want to bother what app is apropriate for that!"
I totally disagree!
They want music - they start Amarok and don't care where the files are.
They want photos - they start digiKam and don't care where the files are.
Users care about data, and they associate one application with each data type. But users don't care about where the data is as long as they can easily access them. Having all your music in a database? Would be fine too, as long as Amarok can access/handle it.
Starting Konqueror and going to "~/Mail" for reading mails? No way! Simply start KMail/Kontact.
Having only one application (konqueror) and lots of kparts seems absurd for me.
But ok - some prever to have all their application to be in the web browser (web applications). Maybe it's me who is wrong.
> They want music - they start Amarok and don't care where the files are.
> They want photos - they start digiKam and don't care where the files are.
I disagree on the following point: having this philosophy leads to tons of redundant non linked databases.
Document indexing then becomes a nightmare.
As for reading mail, IMHO, it's better to see mails than seeing useless amount of files...
"Document indexing then becomes a nightmare."
Why? Is there any difference if your photos are stored in "~/photos", "~/documents/images" or "~/.photos/albums" ?
"it's better to see mails than seeing useless amount of files..."
It's better to see photos than seeing useless amount of files...
I think that Dolphin could replace Konqueror in file management operations only if
it will support all remote kioslaves (ftp/sftp/fish/svn etc.) and integrate archive management available in ark (maybe both project should be merged ).
Dolphiin will support kioslaves, and archive management in konquorer is done by kioslaves.
an other wish is the possibility to place MANUALLY the icons , independent from alfabetic orders, and the possibility to remember theyr position of course and theyr dimension and so on, and the same focus policy of windows too would be a great wish
Thanks for your great articles,
and especially for this one about Dolphin,
one of the KDE4 changes I'm really looking
what about fileselectorboxes when you do file->open or file->save? Do we got dolphin style or current style or is this a config option?
Those are neither Konqueror nor Dolphin. The technical name for them is "kfile" (named after the KDE 2 library libkfile, which doesn't exist as a separate library anymore).
All of this thread has been pointing out again and again that Dolphin and Konqueror share the same filebrowsing backends. They are just different shells for the same thing. Like Kate & KWrite, as well as KDevelop, Quanta, Kile, etc. (all of them use the KatePart).
But no one has mentioned yet that the sharing is done three-way: kfile also shares code with both apps. The only difference is that your File|Open dialog is not meant to be a file manager or much less a web browser :-)
"But no one has mentioned yet that the sharing is done three-way: kfile also shares code with both apps. The only difference is that your File|Open dialog is not meant to be a file manager "
Because it's a File|Open dialog, not a file manager. If you want a file manager, you start your file manager.
That is not to say that the dialog will not support *some* file management tasks. I find it handy that I can rename a file inside the File|Open dialog.
It should also support an easy "open the file manager here" option.
There isn't that much difference between both... as I said in a comment further down, it would be a good idea IMO to replace the file selector with a dolphin instance.
I am also a big fan of the "open the file manager here" option. I needed it already many times.
I would also like to see such an option in the "File" menu of applications such as Okular, KWord, Krita, Kate, etc. This option should open the file manager in the directory in which the currently viewed/edited file is located.
Konqueror will still be mostly present (except that Dolphin will necessarily load files externally instead of using embedding viewers).
How come Dolphin has to load files externally instead of using embedded viewers?
That's what I liked so much about Konqueror!
Isn't there any way to embed viewers?
Is is technically or just policy?
I don't know, I think it may be policy.
That said if it isn't technically maby they'll put an option in the config menu.
That's the whole point of having Dolphin: loading stuff externally. It's also IMHO the only line we can draw between a file manager and the web browser.
If you embed HTML files, you soon end up with a web browser: you're going to click links and expect them to open in the same window you are right now.
That said, if you find that feature interesting, keep using it. I reserve the right to not like it: opening text files, PDFs, images, etc. in a powerful viewer is better for me.
BTW, Hint: if you middle-click a file in Konqueror's file view, it opens externally, much as clicking a link on an HTML page opens it a new tab/window.
> That's the whole point of having Dolphin: loading stuff externally.
I thought the point of having Dolphin was to have a different user interface to file management. However, if loading files externally is the only purpose of Dolphin, then Dolphin is entirely unnecessary, since Konqueror already can load files externally.
> if you find that feature interesting, keep using it.
But why shouldn't I be able to use that feature _in Dolphin_?
> > if you find that feature interesting, keep using it.
> But why shouldn't I be able to use that feature _in Dolphin_?
I agree. If I want to do file management tasks, I often want to *quickly* check the contents of a file before I move/copy/delete it so that I am sure that I do this action with the correct file. Waiting until some external application loads and shows the file is not quick, loading the file in a kpart inside the file manager is.
BTW, I do not claim that the efforts done on Dolphin are useless. On the contrary, I think it is useful to have an app that is focused on file management (and not on webbrowsing). Viewing the files in a kpart inside Dolphin is not in conflict with the focus on file management: the purpose of viewing a file in a file manager is *previewing*, not browsing. Therefore the file manager should not show my (web) bookmarks and other stuff that is specific for web browsing (such as web browsing specific options in the configuration dialog). To be more clear: in the file manager, the khtml kpart should be considered as one of many kparts, i.e. equal to the kpdf, kghostview, ... kpart.
On the other hand, Konqueror can be the Universal Browsing Application, i.e. it is a web browser, but if it encounters a "file://..." URL then it can also *browse* your local files. The file management stuff (move/copy/delete/rename) is of less importance here. In this context, the bookmarks and the web browsing configuration options should still be available, even if you are browsing local files.
I have not yet tried Dolphin and I was wondering how it responds to the usability problems we have with Konqueror as a file manager.
- Selecting files with the mouse was always difficult. Aaron had a demo some times ago of making it possible when you hover over a file to have a small menu to appear with several contextual actions, like selecting. Is this idea tested in Dolphin ?
- Looking at the screenshots, I see that in the splitview the little green light that we have in Konqueror to switch panes has gone. This little green light is clearly a usability nightmare. How is it replaced in Dolphin ? I'm wondering also if in a splitview, fading a little bit the inactive pane would not be a good idea. Splitview is also often used to copy something from a local to a remote place. Having a visual clue, maybe with a different background, showing what is the local pane and what is the remote pane would be nice.
> Selecting files with the mouse was always difficult.
> Aaron had a demo some times ago of making it possible
> when you hover over a file to have a small menu to appear
> with several contextual actions, like selecting. Is this idea
> tested in Dolphin ?
It has not been tested yet, but we discussed this internally already. It's to early now for giving a final statement, but we're aware about the problems in KDE3 regarding selections and plan to improve this.
> Looking at the screenshots, I see that in the splitview the little green
> light that we have in Konqueror to switch panes has gone. This little
> green light is clearly a usability nightmare. How is it replaced in
> Dolphin ? I'm wondering also if in a splitview, fading a little
> bit the inactive pane would not be a good idea. Splitview
> is also often used to copy something from a local to a remote place.
> Having a visual clue, maybe with a different background, showing
> what is the local pane and what is the remote pane would be nice.
In the KDE3 version of Dolphin the inactive view uses slightly darker colors and a gray breadcrumb view as indication. In the KDE4 version of Dolphin I think we'll indicate this in a similar way, but we'll use the benefits we got by Qt4 to do it even nicer.
If Dolphin supports per window backgrounds why not make it default to having a large picture in the background of two networked computers?
You could diferentiate between a root opened session of Dolphin and a normal one by putting a large bomb in the root session.
An idea for file selection: By clicking the middle button (or left and right button together or whatever) on a empty section of the dolphin window, we switch to file selection mode: The cursor image changes appropriately and you can [de-]select items with the left button. Same button combination lets you leave selection mode again.
That is a good idea. But it may be better then to have a "Browse" and "Selection" button, similarly as in KPDF.
The file selection dialog basically is a dumbed-down file manager plus filter options plus "open file" button.
So when I heard about Dolphin, I had this (rather obvious) idea: Get rid of the "open file" dialog altogether and replace it with a Dolphin instance. I don't think it would cost much in terms of resources and it would certainly help overall interface consistency, as two interfaces almost identical in purpose yet different in design would be replaced by a single one.
And as an added bonus, all the goodies of the file manager would automatically be available to the file selector.
What do you think of this?
It means that if I double click on the file I want, exactly what will happen?
Thank you for your constructive criticism. If you double-click the file you want, the Dolphin window will close and the application you use loads that file.
That would be very confusing for pretty much all users (if I didn't know about that before hand and I was given an application that did that I'd just close the dolphin window and wonder where the kfile window was (and probably just go to file -> open again and repeat until I figure that its causing dolphin to open, at which point I'd assume that something had just bugged out). It really doesn't make much sense that double clicking sometimes opens the file in its default app, and sometimes closes dolphin and opens it in some other app, it would be quite confusing for I think all users actually.
Well that could be easiliy remedied by setting the window title to "Open file...", showing a large icon of the calling application in the lower left corner where you can drag a file to open, and perhaps by adding a great big flashing "Please select a file NOW" sign that causes seizures. Just think of it as a filemanager window with a different default application set for all files.
Once users get used to it, I expect they will not have a problem with selecting files via the filemanager interface. We shouldn't be afraid to confuse first-time users a bit (only not too much mind you), or else we wouldn't be able to change any aspect of the UI. Ever.
I don't usually do this, but somewhere has written up a Digg article here and I'd quite like to see it bumped to the front page:
The reason I make an exception in this case is that this article is not merely promotional, and it would be good to get some opinions on the Dolphin As Default issue from people who *don't* necessarily frequent dot.kde.org.
[quote]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.
Dolphin in KDE 4.x showing breadcrumbsNotice 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.[/quote]
I think all of these extra filemanagement functions could be implemented in Konqueror when it displays a directory. Take a look at these mockups:
"Navigation Bar Reloaded"
I definitely like the solution of clickable and editable navigation bar in these mockups.
Totaly agree, THIS is the way to go!
Seamless access to data what ever the datatype is or the storage location.
Many people think that a file and a picture are 2 different things. Having a separate file browser and a picture manager won't help ;-)
"Many people think that a file and a picture are 2 different things."
Maybe because they are?!?
A file is only the place, the picture is stored in. Pictures could also be stored in databases for example. A picture manager could access the picture both ways. But a file browser - well ...
If a user wants to handle pictures, she doesn't care about files at all. All that matters is to have an easy way to view/edit/manage/burn/... the picture/data. If it's a file(-system), a database or whatever that stores the data is totally unimportant.
Have a look at iTunes, Amarok or digiKam. Why are they so succesful? I tell you: Because they hide the file system from the user, so he can focus on the actual data and tasks.
That is was I was trying to tell but you misunderstood me.
User doesn't matter how the data is stored, thus I wonder why splitting konqueror to manage data that is stored in a file just because it is stored in a file.
Take the example of a photo album.
you can have a web based copy
a file based copy that you browse via konqueror
a file based copy that you browse via digikam
Now imagines you have bookmarks for your photo albums and forgot wich versions lack a specific photy. You have to start 3 software to find out were is the missing photo.
That's why I also wonder why people want to see pdf files in a specific window? what is the benefit from konqueror windows? both windows provides zoom, navigation, print and such ... so what is the problem??? Wors, in the separate view, if you click on an URL, either it does nothing or it opens a new web browser.
[quote]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.[/quote]
I think tabs are very useful for file management also even if it is more common in web browsers.
I have to agree there I find myself hitting Ctrl+T in windows explorer and then sighing as I realise that I have sold my soul for hardware support to print of an essay :'(
Well konqueror is the best file manager/web browser I have ever used, period.
This is my opinion so I am free to change.
I like the fact that Dolphin does what it does so well, and I can see dolphin and konqueror sharing a very large code base for file management, and of course solid :)
The main pro's with dolphin imho is the fact that it's configurable for file management. As I have heard voiced konqueror 'could' have had a configuration for web browsing and file management that are completely separate however this would probably cause my favourite app to become split.
I like konqueror the way it is, it could be customised to do file management but if I did require a dedicated session for file management on a more complex level I would welcomely give Dolphin a try (as long as it has tabbing or tabbing equivalent ;P)
The idea of a serious app for file management that couldn't allow tabs or better for moving between 2 directories that are far apart i.e. ftp://your.site.here and /home, scares me. Moving files between these 2 directories seems best done with tabs to me or something equivalent.
The nearest comparison to this is using the directory bar, which I have no problem with, just I would prefer to have both directories open in the same program in the same window.
Interesting Idea but could a dolphin window be used to manage files within Konqueror as a tab option like a page can be displayed in explorer in a new tab in windows firefox?
(Probably not but I recon that this could go down an interesting road)
I als think that tabs are an essential element of a file manager nowadays, introduced by (if I'm guessing correctly) Konqueror itself. Taking these out again would take away the ease of file management, not making it less complex or easier to use. Imho it is not a "pro"- feature that needs to be hidden from an average user who is operating with files.
Reasons for tabs:
- it greatly helps unclutter the task bar. Just like it helped collecting the dozen web sites in a single entry for browsers, it is not uncommon to have half a dozen different folders or more opened, which don't need to be spread on the whole taskbar. Also the folders don't need to be accessed via the taskbar (which is at least one additional step), but can be accessed via the already openend window.
- the only other mechanism for handling of multiple places I can see is the bookmarks area. Tabs cannot reasonably be replaced by these. First, they are not as fast and uncomplicated to navigate e.g. when you want to move files compared to a tabbed view, and second, often the folders which you want open concurrently aren't necessarily ones that you deem important enough to dedicate an own bookmark to.
I think tabs are recognized as what they are and included into the workflow during file management through the widespread introduction in web browsers, now that even Internet Explorers has these.
Example: You have the following opened windows: a window with your photo collection and the the folder of your camera in tabs. In another window (to have a logical separation), you have your download folder with new files, a document folder (perhaps you want to move files here) and a working folder with some more/other data and whatnot opened with which you want to work.
The importance of the folders as you have them opened is non-permanent, it is gone once your tasks are done. So bookmarking doesn't make sense.
Also, you want them them accessible exclusive in a normal view (no splitview) without hassle, so what do you do without tabs? Have this functionality cluttered and less useful/accessible in the taskbar? Search for the correct folders and first have to arrange them next to each other? Searching for the window title of the other window again to drag this one around? Surely you don't want to navigate from within one window to the other folders. What if you have separated out files? This work is gone when you leave the folder. Also I don't want to leave that folder simply because it takes time and effort to navigate back to it.
Now that other documents (pictures, pdfs, etc.) are opened in own viewers (-> entry in taskbar), I think it wise to group the folders together, which is quite like the base from which you operate.
Also think of notebooks without mouse. Do I really have to do _window_ management if I want to have more than only one folder opened? I want to do _file_ management!
The only hurdle I can see is a fitting integration of this element into the user interface which which is neither visually disturbing nor doesn't get in your way if you don't use it.
Krusader is a file manager (not a dual-use file manager and web browser like Konqueror) and it also supports tabs. (There are independent tabs for each of the 2 panels.)
Krusader is a dual-pane file manager. Dual panes are not tabs. Those are two different things.
That said, tabbed file managing is something I definitely miss in Dolphin. The single split view feature is just not enough sometimes, specially if you want to keep a certain "view" (like Media or FTP) active at all times.
Read my message again, you can have tabs WITHIN each of the 2 panes! For example, you can open 5 tabs on the left and 3 on the right, and switch tabs on the left and right independently.
Ok hold on guys, if we really want this thing called dolphine, why should i use kde??? there is one already called nautilus which we all think SUCKS! so why copy it to KDE. KONQI is now the B E S T file manager ever... do not waste time on this fishy thing...
Don't you think that the people that have developed konqueror are capable of creating something even better?
I think that people with your conservative attitude should have some more trust in the developers. (Or just keep using konqueror, of course. ;-))
What I see so far, is that this is an attempt to copy gnome attitude in, instead of streamlining konqi and making it easy to use, or is this a too big challenge!!!
by the way, if why not copying the multi panel of finder? if copying is the game, just lets copy the original not the cheap and unsuccessfull imitation.
by the way, I think Dolphine developers as well as nautillus ones should go back and watch nerd.Tv eposode with Andy hetzfeld. he will tell you what happened to nautillus and what is it worth, also what they wanted it to be is exactly what came out of konqui, so all I am saying is that konqi is a peak, and it will be hard to get higher!
Do you think Nautilus has ZERO good features? I'm not a nautilus or gnome fan, but I'm sure it has at least ONE good feature. The breadcrumb location bar seems to be a very good feature (at least for some use cases), so why not copy it? Also the Dolphin devs are planning on adding the multipanel finder style view (thanks to a new class in Qt 4.3 it'll be easy for them).
When ever you get to a peak, you are only at a new bottom, you're never actually to the top. I'm most likely going to stick with Konqueror, but when KDE 4 comes out I'm definitely going to give Dolphin a shot because it has some interesting features.
FYI, the reason Konqueror wasn't simply 'streamlined' is because the people familiar with Konqueror's codebase knew that there was a lot of bitrot in it and it would be easier to improve Dolphin than to make Konqueror's profiles actually work right.
breadcrumb navigation is the worst thing ever created. Concept seems sexy, but which of its fans dit use it intensively on a daily basis?
With this type of navigation:
- when there are lots of sub directories: you have a giant drop down menu while with predictive type like konqueror, the more you type, le smaller it get. It's just like replacing autocompletion in the shell by a curses based interface you controle via arrow keys
- what about directories that starts with a dot?
- what about directories you d'ont have permission to navigate? (HOW do you go throu chmod 711???)
You react as if the breadcrumb bar is the only way to navigate in Dolphin (or in Nautilus for that matter).
- when there are lots of sub directories: most of people w/ this kind of setup type in the direct location anyway.
- directories that starts with a dot: Indeed this is a feature worth asking about. For once, you have an actually rational question.
- directories you don't have permission to navigate: Then you can't navigate into them. Why, can you navigate into them in Konqueror, without running Konqueror as root or changing the directory's permission first?