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.
Comments
> how many times have we seen webkit patches rejected because
> they aren't "good enough" and then reformatted / rewritten?
Are you serious?
Each time we have taken the pain to merge even so little as a heavily elaborated-upon *one liner*, proper attribution of the initial work has been given. Always.
Being disrespectful to people's work is just not our way at all, and I find it very offensive to see such a statement in the mouth of a fellow KDE contributor.
> i hope you're not claiming they strip copyrights.
In my book "giving proper attribution" is not about stripping copyright notices.
> that attitude [...] it's not that apple doesn't "own" webkit
How could I argue on that irrational, head-in-sand "let's have a positive attitude" couplet?
yes indeed, I have principles of probity, freedom and humanism that I'm not ready to whipe my bottom with for the sake of "market penetration".
Sorry 'bout that.
Really like to know what you are talking about...
What, _precisely_ do you consider 'giving proper attribution'??
Must Apple provide a paragraph of blustery thanks to the KDE community every time it gives a press release on WebKit?
Really, what is this you are talking about??
Nope, just that the few times they have adopted patches from KHTML, it would be nice if the changelog said: "patch adopted from KHTML" or "Patch originally by Germain Garand ported for WebKit by WK-Fanboy1" instead of "Patch by WK-Fanboy1 approved by Hyatt"
Another example could be instead of writing: "The code for generated counters in KHTML is not good enough, so we have to start from scratch" and then port all my code with some variable renames. They could write "The code in KHTML is good enough, but we renamed some variables for clarity"
"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)."
Just so you know, FireFox has an add-on called FireFTP which is pretty nice too. And you are right, it is a little different. It has to be added and it has its own address field. See http://fireftp.mozdev.org/
you missed the point. here's the use case:
you're at a website and filling in a form. it has a location for uploading a file. you can put any url in there and it will fetch that url and upload it. it could be another http address, fish://, ftp:// whatever.
it's not about being an ftp client, it's about being network transparent even when it comes to things like web form upload fields.
even cooler, try this:
you have a html upload file. now split-screen (on the statusbar, rightmouseclick -> split screen hor/ver) and go in the one screen to your fish or samba files share or an ftp site. now just drag'n'drop the files into the input location, and hit 'submit' or whatever... things will just work. Now, you can't even do that with a LOCAL file in windows (try drag'n'drop a file to a attachment bar like under the response message you could write to me, won't work)...
Even better, in the kde file dialog you can chose a ftp bookmark an save your image thru FTP!
I'm using this often when downloading photos from my digital camera, resise them in a batch and upload the results to my blog without having to do a local copy....
Olivier.
"clicking and holding a breadcrumb item displays a list of directories that are at the same level as the one clicked"
Judging by the screenshot, you are wrong. It seems to display contents of the item you clicked... Yeah, confusing. The breadcrumbs is a dandy idea but we managed to copy the most brain-dead implementation to KDE.
The closest analogy to how one would expect this to work would probably be a pull-down-list HTML widget. In Dolphin, you click on path element, and instead of choosing a replacement for the item clicked, you add to the path as result...
please test this with users. i wasn't sure which way to go so i camped out at a coffee shop one day (aaah! caffeine!) and coerced people to try various things out. this was one of them. i'm not so much interested in arm chair theorizing, but if you have real data i'm interested in looking at it.
btw, this also works nicer with, say, $HOME since it showing other homes would be a bit odd and unexpected. as i found out at the coffee shop.
Interesting new way of doing cheap usability studies :-)
Usability studies> Probably time for me to leave then. One of those produced the koffice startup/new file/file open dialog: the sole reason I still use koffice 1.4, and something that causes wonderful first impressions everywhere:
"Krita's startup window is downright annoying: I'm not interested in selecting RGB or CMYK or Grayscale at predefined dimensions or just a custom Document."
"The only thing IMO GIMP's UI does better for me, is creating a new image, their dialog for that purpose is a lot easier then krita's."
both not me, from http://osnews.com/comment.php?news_id=17366&offset=0&rows=15&threshold=-5
well, then, it just shows people differ. I love the new startup window: you can immediately select previous files you have been working on, or create a new one, easy as pie. Love it, really. I wish this kind of startup dialog became the default in ALL kde apps (codeine has something similair, exept in a seperate window).
Indeed the dialog is no improvement at all. Why do they place functions all over the place? Have they ever heard the principle to group functions?
Right now it looks like game: hunt the button (featuring Krita).
Use Case 1: just give me a new document
question: where is the button?
answer: on the right side somewhere in the middle of the same window
Use Case 2: open existing document
question: where is the button?
answer: on the left side at the bottom and the bottom right side in the new window with the dialog
Use Case 3: open recent document
question: where is the button?
answer: recent documents are in the top left corner and the button is on the right side somewhere in the middle of the top half of the screen of the same window
BTW The corresponding bug report is here:
http://bugs.kde.org/show_bug.cgi?id=121233
I hate Bread Crumbs and this is one reason my I don't use gnome. The file dialog needs tons of clicks to go to a place. Not speaking about entering directories starting with dot.
BTW, how doeas it manage the devices:/ or media:/ copared to the file:/ in a "Bread Crumbs" way?
- Who conducted the usability study?
- Did non computer Science people participated?
- did Windows users participated to the study?
- Where are the results?
- Is it a compilation of wishes from computer skilled reporters in a bugzilla database?
Have read all the thread, no answer at all about this "usability survey"
I though I was reading a gnome thread :-D
Am I lost? surely a konqueror usability desing problem.... ;-)
Looks like you introduced that tag too late in your post. It should have been at the top.
I guess you forgot.
> how doeas it manage the devices:/ or media:/ copared to the
> file:/ in a "Bread Crumbs" way?
get ready to gasp in delight: it shows the protocol in a drop down combo box at the front as if it were part of the breadcrumb! *gasp*!
you could've found that out by trying it, but i'm sure that would've been less fun, right? ;)
> Who conducted the usability study?
i did. why?
> Did non computer Science people participated?
at the coffee shop, none of them were comp sci people. i also tested it at home on some friends in the industry, just to make sure i also hit some people from the geek crowd.
> did Windows users participated to the study?
and macos users too!
> Where are the results?
notes in a notepad. i also constructed experiments and fixes on the fly and had people try out the changes.
> Is it a compilation of wishes from computer skilled reporters
> in a bugzilla database?
no, but keep digging. i'm sure you'll find a reason to discount the idea. it's obviously what you want to do.
oh, wait, i know! i did it on a tuesday. and usaiblity studies done on tuesdays don't count in canada. totally forgot about that! *smacks the forehead*
I don't like "breadcrumbs"(*)
With this system you don't get a clear panoramic view of where you are in the file system and what other ramifications are there in it.
I feel trapped, blind, when forced to use this paradigm in GIMPs open dialog.
Besides that, you often end clicking many times just to select a folder (firstly to open menus and see if what you want is inside there, then when you find it, another time to select it), I think this isn't a progress in usability, but the other way round.
Please just don't make it the default option in Dolphin or in any other KDE part.
(*) I'm curious, what a name! Can someone explaint from where it derives? :)
Basically it means that instead of being able to eat the whole bread, you only get to eat the bread scraps... Some people like bread crumbs, but as you pointed out you don't get the full thing.
Interesting. I always thought it has to do with the tale of Hansel and Grettel, where the kids would leave bread crumbs behind them while walking through the forest, so they could find their way back later on. The widget does something similar, showing you the path you followed to arrive where you are, so it sounded like the same thing to me.
Hey! Hansel and Grettel? If I recall well, it was another tale called Pulgarcito (in spanish as I knew it in my infancy, don't know it's name in english, sorry) that left bread crumbs to mark it way. :)
"With this system you don't get a clear panoramic view of where you are in the file system and what other ramifications are there in it."
Should be no different than the location bar in that respect.
"Besides that, you often end clicking many times just to select a folder (firstly to open menus and see if what you want is inside there, then when you find it, another time to select it), I think this isn't a progress in usability, but the other way round."
And with the current location bar you CANT even do that... Whats your point? "Breadcrumbs" are an alternative view the the KLineEdit currently used (which you can instantly turn into the KLineEdit if you want to rewrite parts of the path and not use the breadcrumb method!).
Also just so you know, the 'breadcrumb' feature in Dolphin is already much more advanced than the version in the gtk file open dialog.
Well, yes. You're right. The text location bar, doesn't give any panoramic view of the file system at all. I was saying that because I feared someones were proposing the "breadcrumbs" system as a replacement to the tree view system we already have. So in this respect it made sense to comment that.
I think I wouldn't mind having the breadcrumbs AND the tree view together in the screen either.
So go ahead with the breadcrumbs if you maintain the tree view also! :)
> get ready to gasp in delight: it shows the protocol in a drop down combo box at the front as if it were part of the breadcrumb! *gasp*!
whahoo, awesome, so if I missclick on media:/ when www.google.com is in the path, what is the result?
> you could've found that out by trying it, but i'm sure that would've been less fun, right? ;)
Didn't tested it because I wasn't aware of this move. More over, according to posts, dolphin is far from having most of its functionalities, so why testing a thing were many changes are already planed?
Regarding the survey you've certainly forgotten the tag right? Do you realy think that your coffe shop represents the whole effective and potential KDE userbase?
As for Bread Crumbs (the initial subject of this thread) I still don't have answers to some basic usability questions:
- How do you browse automounted entries that are not yet displayed?
- How do you browse a directory if the parent directory is 711 chmoded?
(typicaly /home so a user can't see other home directories and permissions)
- How do you browse directories that begins with a dot?
- How do you copy/past a path?
- What if the number of dirs exeeds the height of the screen in the dropdown menu?
> but if you have real data i'm interested in looking at it.
Sorry, someone had to ask, but: where is *your* real data? Doing some (informal) tests is nice but pretty much useless unless you document it... Who was tested, what was the test design, how did you proceed, where are the problems? Maybe there is another design that works even better than the ones tested. Unfortunately without the data we can't tell (and can't redo the test with alternative designs).
It dosn't seem too bad to me. Then again I'm never leaving the good old keyboard url bar
I think this is a very wise and well-considered direction to go. I have used Konqueror as my default web and file browser after years of experimentation and I'm very happy with it.
I think Konqueror can only benefit from having less burden placed on it to perform two usually different, but occasionally overlapping roles. And a dedicate file browser can focus on UI issues not present in a web browser.
Yet when you enable konqueror and dolphin to enjoy the same core technologies, you get a system that is powerful *and* makes sense.
Now if Cervesia and the svn support in Dolphin could find similar accordance, it would be VERY impressive and more importantly, very useful. But the way KDE4 is being designed, this looks likely.
I LOVE fish BTW. It's very productive for me - secure, drag-n-drop, network-independent file operations. FTW.
The ultimate lesson is, sometimes you need a complete, featureful interface for a given KIO. But convenient, integrated operations in other or more general purpose programs are incredibly powerful. Eg. shouldn't "extract to" be a context-click operation from a zip file in a browser?
KDE4 looks very promising and capable of competing with any proprietary OSen in this regard. Architecture and framework enables all.
I'm curious: is there are reason to use fish:// rather than sftp://? I know fish:// can work with telnet too, but every non-Windows host supports SSH nowadays.
fish:// is useful if the remote host's SSH server doesn't have SFTP enabled.
For example, my Nokia N800's mini-SSH server.
After I found fish, I NEVER bothered with any other method of sharing files (like samba, nfs, sftp or whatever). Fish is THE most usefull and easiest of all for me ;-)
I mean, how simple could it be? Enable SSH (mostly very very easy, apt-get install ssh on debian and it gets enabled as well, or add it to rc.conf on arch or whatever) and then just fish://user@host [enter] and you're there...
I should have added: fish:// doesn't work if you don't have a shell on the remote machine. But sftp might.
> I'm curious: is there are reason to use fish:// rather than sftp://?
Even stranger, fish is really slow. I used FileLight on a remote system. With sftp:// it's done pretty quick, with fish:// it's so much slower. Examining the tree took a few hours instead of 15 minutes with sftp://
Wow, how slow must the gnome fish-variant be, then... I read a blog by a gnome guy complaining it was way slower than fish:// in KDE ;-)
FISH uses the remote system's shell, while SFTP doesn't (it uses special features of SSH) so SFTP is faster (I think only if you're doing lots of things at once, like what file light would do). I generally use SFTP but sometimes it just buggers out (I really need to try and figure out why sometime) so then I can fall back to fish which just always works.
Fish is will work pretty much everywhere that you have a shell, sftp requires the SSH to have sftp enabled in the configuration (which is pretty common from my experience). So its really a compatibility vs speed trade off (and the nice thing is you get both for free in KDE).
sftp is far from being fast or even quick:
Bug 129331: sftp very slow compared to commandline sftp client
http://bugs.kde.org/show_bug.cgi?id=129331
Personally I would like to see profiles to be able to save different toolbar configurations, I think that would solve almost anyones complaints about konqueror as a file manager.
unless of course you get those that think the profiles are per tab(or a I'm browsing local why is it still web browsing?) instead of an application instance wide setting.
While I'm happy for the change. I don't really see any compelling reason to even use dolphin. currently I have 6 tabs, 3 local, 3 websites. I've never found konq's ability to browse my files to be lacking in anyway. and have always loved the ability to have a web page up in the same window.
I daily need both local and web up at the same time and would rather have them together than appart. as they are very related. (1 local is for my media, 1 web for my media database, 1 local for the website's source code, 1 web for the php api.)
I cringed when I saw the 'breadcrumb' bit but was very relieved that it had the option to use the standard.
ehm... profiles DO save toolbar configurations. There is the simple browser profile there by default, with a kubuntu-like default all-in-one toolbar...
Like many I was skeptical about Dolphin when it was first announced to be the default file manager. When told I could set konqueror as the default I wasn't worried, and that it would be my first task to do once I had KDE 4.0 installed.
This article convinced me to try dolphin, that screenshot shows a lot of useful ways to navigate through directories and files, it just might be useful. I'm going home tonight and trying out dolphin!
Sunil
Please keep in mind that the version of Dolphin you are getting from SVN is still very much a work in progress. Please don't judge it entirely on it's current state, as it will be much improved by KDE 4.0. So for instance, the config dialog won't be as tall :P
Why is KDE making this kind of decisions? The more KDE tries to copy half-baked Gnome applications, the worse for KDE users. Konqueror was just perfect as it was in KDE3.
And please do not tell me "you can still use Konqueror as your file manager in KDE4" as people are not going to do that: 99% of people just use defaults, therefore 99% of work goes to improve whatever is default. Manpower is scarce and Konqueror was already lacking developer time; this Dolphin is not exactly going to improve the situation.
> Why is KDE making this kind of decisions
because kde is for more than you and me. it's for everyone. we're trying to cater to a broader audience. sort of like what we've done with every release of kde every made compared to the one before it.
> The more KDE tries to copy half-baked Gnome applications
*sigh* you can think that's what you're doing if you want. you're also completely wrong. the goal is not to copy gnome applications. it's to take good ideas where they exist and bring them together with our own and produce something even better.
i know it's *astounding* but works for you or for me may not actually work for everyone. we can stick our head in the sand if we wish, but that doesn't change reality (whatever that might be).
that said i've used nautilus in the last few months while doing various bits of research for dolphin. it's a pretty poor file manager, imo. so with that in mind, read what you wrote again and think about it.
> Konqueror was just perfect as it was in KDE3.
i'm very happy you feel this way. konqueror will still be there in kde4 as it was in kde3; hopefully even better actually. but your assessment of it as the "right tool for the job" is not universal.
but tell you what, as soon as we start making the Pau Desktop Environment we'll make konqueror not just the default, but the only file manager you're even allowed to run. how's that? ;)
> because kde is for more than you and me. it's for everyone.
Yeah, the typical 'users are idiots' canard. Linus unleashed a crapstorm by expressing his opinion of that design philosophy in Gnome, but I happen to agree.
Even if one believes that the average user's brain explodes when he sees his filesystem represented as a tree (wtf) that doesn't explain why Dolphin is set up to prevent people from doing so if they please. Sure I can use Konqueror, but once there is a "usable" filebrowser at some point the the simplification brigade will be pushing for filebrowsing functions to be removed from konqueror to make it a better webbrowser, and given your own comments on the unworkability of improving konqueror's handling of different profiles things will have to move in that direction, leaving me with a non dirtree filebrowser.
Even if that doesn't happen, do you really expect me to believe that work on filebrowsing won't be concentrated in the default filebrowser? Konqueror is being left out in the cold vis a vis file browsing, saying anything else is disingenuous, so telling me to continue using it is sadistic. I'm given a choice between a neglected, unwanted (by the devs anyway: they replaced it) filebrowser, or the braindead app that manages to be "simple" by taking away how many people are used to doing things, and adding a new way (like that won't confuse anyone).
For trying to woo the mythical masses of idiots waiting to jump into a complicated powerful Unix like OS and needing to dumb things down there is a one word response: Explorer. If anyone thinks Midnight Commander is something more familiar to all the Windows users I dare say he/she is mistaken. Even if the dirtree isn't visible at times, it is always a click away.
Sorry this has me so steamed. The dumbing down of Deus Ex 2 (apologies if you aren't a gamer) had me worked up in a similar way. The sequel to the complicated (and loved, and oft regarded as one of the best games ever) Deus Ex was "simplified" (dumbed down) to appeal to a console audience. It flopped, and the legacy of the original was tarnished. Using a single ammo type for every weapon, removing skill points etc didn't attract an audience, and it helped alienate those who liked such features in the original.
Removing dirtree (as an option even) will not attract an audience. It can do the opposite.
I'm a long time KDE user, but the longer goofy bugs are ignored, the more usability studies inspire retarded changes and the more I am written off in a quixotic attempt to appeal to the mythical Joe Sixpack who is interested in using a powerful, complicated Unix like system, the more I am pushed away. I'm just one person, but such an emotional, intensely negative response from me probably isn't an isolated incident.
Adding dirtree would assuage me, but that simple thing will never be done, as you know better, and this is indeed typical of the Gnome modus operandi you claim not to be emulating. I'm sure you're sick of hearing this from me, but soon you won't have to.
> Adding dirtree would assuage me, but that simple thing will never be done, as you know better, and this is indeed typical of the Gnome modus operandi you claim not to be emulating. I'm sure you're sick of hearing this from me, but soon you won't have to.
Read up a bit. You will be assuaged.
Dolphin is not yet in it's finished for. That has been mentioned in the article. It still lacks a few features, that may (or may not) be added. Nothing is set in stone yet, except that it will be the default file manager for KDE 4.x.
+1
Even the Amiga had a multiview. But KDE seems to choose the Atari TOS way;
Be carefull, there are hidden anciant trolls ;-)
More seriously:
- Dolphin lacks features not written yet
- Despite that it will be the default browser
- Not widely tested
Better make sure it is rock stable
Olivier.
Relax!
Peter Penz already stated in the comments, that a dirtree will be added to dolphin.
"I'm given a choice between ... , or the braindead app that manages to be "simple" by taking away ..."
You seem to think, that dolphin is about "simplification". I guess that's wrong. Dolphin is about "concentration". It concentrates on being a program for file management. It will (or should be) as powerful as konqueror. It will (should) offer nearly everything that konqueror offers for file management.
But dolphin won't mess the user with UI-elements originated from file viewing or web browsing (have a look at the settings dialog).
I'm pretty confident, that dolphin will be even more powerful on file management than konqueror. Simply because neither programmers nor designers will have to make any concessions to non file management tasks.
I really hope you're right on that.
Don't sit in the corner hoping. Go do something about it.
Test Dolphin, test Konqueror. Make sure they are on par. Make sure they are rock stable. And if features are missing, volunteer to write them or convince a developer to do it.
KDE developers are not totalitarian power-hungry fascists. Quite to the contrary: we're very open to new developers. We're receiving a nice influx of new blood due to the KDE 4 development process.
So, why not you too?
(this reply is directed at everyone, not specifically at the parent poster)
Speaking of testing Dolphin, I recently grabbed v0.8.2 from FreeBSD Ports and gave it a spin in KDE 3.5.5. It seems much more lightweight and capable of doing what I want than Konqueror. I also like the sidebar where I can view Network Shares and trash:/ -- which reminds me. I've tried to find a Bug Tracker for Dolphin to submit a feature request for the ability to Empty Trash (maybe from the right-click menu inside the window pane like Konqueror has, or even just an Edit action under the main menu) from within Dolphin. I cannot seem to find one on the Dolphin homepage, nor is it listed in the KDE Bugzilla drop-down form for applications when you go to create a new query. In fact, searching for the word "Dolphin" only produces 12 tracker results, 1 of which could actually be considered relevant. Is there some other place I could pitch this idea or would I be wasting my time? Because while I was at it I also wanted to mention in case nobody had yet noticed that when the mouse is over a file with a really long description the text wraps to a second line but the bottom half of the second line is cut off by the window border--regardless of whether you resize the window or not. I don't really ever read those little descriptions so it doesn't bother me, but I can see how it might make Dolphin be viewed as "not ready for primetime."
>Test Dolphin, test Konqueror. Make sure they are on par. Make sure they are rock >stable. And if features are missing, volunteer to write them or convince a >developer to do it.
I'm doing all that, I've been playing around with dolphin and I did post the missing featues I noticed
http://dot.kde.org/1172721427/1172833833/
Heck I'm playing around with Dolphin right now, I'll be posting a new thread right after this post with a couple of problems I found.
I also plan to test alpha releases of KDE4 (not dev snapshots though)
Ben, please do not think your dot comments will get noticed by the Dolphin developers. This is not the appropriate forum to post such things if you want to have any chance someone who can act on it will hear you.
Go post on the list.