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
Point 1) So you admit that breadcrumb is unable to address some situations that were adressed by the previous solution.
Point 2) It's maybe because I'm a real life user? For once, I recieve an answer different from "dot dirs shouldn't be accessed by browser as they are often system directories".
Point 3) /home is chmod 711. This means you can cd in that directory, but you can't readdir you must know the file/directory name you want to use. thus as a user, you don't need to browse /home, but you may be interrested in browsing /home/username.
I should have stated directory you can't browse but can navidate thru.
Anyway: question still there: How do you navigate using breadcrumb method to a path were some upper directory has 711 permission and you're not the owner?
Dolphin <> Konqueror
I have now set-up Dolphin as default file manager, and have following observations: -
+ Is fast
+ A bit lighter than Konqueror
+ 'breadcrumb'-style directory selector
+ Very simple
- Missing embedded views > I disliked them one they were made a part of Konqueror. I still have disabled embedded views for all uses except viewing tar/zip files.
- Tree view > Actually i did not noticed it after usage of 2-3 days, only came to know about it on this page itself!
About Konqueror: -
+ You all know ;)
- 'breadcrumb'-style directory selector
- Profile Management
I'll use Dolphin if it replaces its -s with +s, otherwise continue with Konqueror.
dolphin is easy and fast beacuse it lacks all advanced features :>
rubbish. I could go on to point out all the advanced features, like kioslave support, split views, intelligent file sorting, an,d so on that it has. but seeing as you probably wouldn't listen anyways it would be a waste of my time.
Well, in my opinion Dolphin is a bad idea. Why do we need another file manager. If I want to use a "real" file management tool, I will take Krusader. Dolphin is useless and looks just like a copy of Nautilus. The universality of Konqueror was the only reason why I have taken KDE as my desktop environment on Debian.
Good thing Konqueror isn't being removed, only not the default for file management (still the default for web browsing).
Yes! Improve Konqueror! Don't split our resources on two projects when all the Dolphin features could be implemented also in Konqueror but not vice-versa!
Point is, you can't implement one important feature from dolphin in konqueror: it's simplicity. Now I won't be using dolpin a lot, I love konqi. But I think it can be helpfull for many users out there, so why not? All other OSses and DE's have a sperate filemanager and a seperate browser (yes, MS since IE 7) and I guess there are reasons for that ;-)
>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.
This is because your konqueror is badly configured ;)
gnumdk@flanders:~/.kde/share/apps/konqueror/profiles$ grep XML *
filemanagement:XMLUIFile=konqueror.rc
webbrowsing:XMLUIFile=web.rc
gnumdk@flanders:~/.kde/share/apps/konqueror/profiles$
And here my file manager:
http://hibbert.univ-lille3.fr/~cbellegarde/konq_file.png
here my web browser:
http://hibbert.univ-lille3.fr/~cbellegarde/konq_web.png
Huh, I use the up button almost exclusevely for webbrowsing, where it makes perfect sense for me - it's one the really cool things in Konqueror that I miss immidiately in any other web browser.
Did you accomplish this with just the profile functionality? I have tried to do similar things with no success. It seems that any change made to the toolbar or menu is inherited by all profiles. So what am I doing wrong?
Try e.g. to have different icons sizes for different profiles.
Toolbar saving is broken (design flaw obviously) and has to be fixed.
...that the baby may be thrown out with the bathwater.
The integration found in Konqueror was the most important factor when I choosed KDE (and that I kept on using it).
There is a real risk that newcomers will use Dolphin and Firefox instead of Konqueror, just because "usability experts" say that Konqueror is too complicated.
There sure are things that can be improved - like profiles, menus just to name a few - but I just can't see the point of dividing the best part of KDE. Make it better instead.
After reading all comments (180+ comments, WOW!!!) and watching some KDE-GNOME wars, in my opinion why people keep calling Konqueror "bloated" is because there is no clear separation between webbrowser + filebrowser, e.g: why do you need "configure spellchecking" and "print" in a filemanager? (some of them are "greyed", but still there). But besides that, many people like Konqueror for universal viewing application / swiss army tool. Anyway, I have two ideas in my brain:
1. Improve profiles handling in Konqueror (like many others have suggested).
2. Set Dolphin as file manager, and make sure that it will have all killer features of Konqueror and set Konqueror as full featured Webbrowser.
Personally, I prefer Konqueror like in 3.x series (but I wish they had better profiles handling), however, given that there are people who wish to actively maintain Dolphin, I 100% agree with this decision. I also really love the KParts embedded things, as I really like to "torture" my Konqueror ;), for example if I'm given few links to pdf files, I just use my middle click mouse for every links and few seconds later I have all pdf documents ready :D
From a KDE freak
"1. Improve profiles handling in Konqueror"
Which is an extremely hard task, which no one seems to be willing to to.
"2. Set Dolphin as file manager, and make sure that it will have all killer features of Konqueror and set Konqueror as full featured Webbrowser."
Which is rather the way it's going to be (it seems). The only feature dolphin will miss compared to konqueror will be to embed other views/kparts/applications.
"Which is an extremely hard task, which no one seems to be willing to to."
Did you forget the ":)"?
"Improve profiles handling in Konqueror (like many others have suggested)."
I agree. And session management would also be neccessary for powerful use.
> 1. Improve profiles handling in Konqueror (like many others have suggested).
just because lots of people who are completely unfamiliar with the code and probably lack the expertise to write complex software in the first place say something doesn't make it true. it just makes them loud.
the suggestion sounds easy to the innocent ear, but it's anything but. in fact, it would, imho, actually make konqueror worse once all was said and done.
> I just use my middle click mouse for every links and few seconds
> later I have all pdf documents ready
yeah, i do this too. love it =) konqueror will maintain this feature, of course.
I don't use lonqueror as my default browser, there are better more secure and often more convenient options, but it is at least a decent browser and if it can be trusted not to 'give away the farm' I don't see a real advantage to an app that simply removes a convenient functionality that is almost trivial to it's
I like the up button on websites - should be (an option) in all browsers.
Granted, up one level may often get you a forbidden message, but up again may take you to somewhere interesting. Naturally you could select the branch of an address by hand, backspacing to the slash, but the up button is very convenient here.
I love the x button of konqueror's location bar. Another option that all navigators (file/web) should have, but don't (save for a firefox plugin) - especially with a linux-like clipboard system (middle click to paste selected would fail if the location bar couldn't be cleared without selecting, right?).
I hate bread crumbs. Too slow compared to konq's predictive entry or cut and paste. I'd rather navigate in a bash shell than use bread crumb buttons.
I am thankful that many apps that use "breadcrumb" navigation offer a location bar alternative by pressing "Ctrl-L" (a nearly universal key-combo the Gimp! an most media players.)
As most people like to keep Konqueror and some hve said that DOlphin will be the Filesmanager of Kde, i suggest du opposite :
Keep Konqueror and the Power and let the User switch to Doplhin if he wants..
you can profile the konqueror default to look like doplhin though
That's definitely not my opinion. The power user, if he or she is a real power user, will be capable of switching to konqueror if he wants to do so. The "normal" user often isn't.
Instead I'd like to suggest Dolphin as default, with Dolphin having a menu command
Open in Konqueror,
and Konqueror having a menu command
Open in Dolphin,
which both just close the current app, opens the other, asking if one would like to make it the new default.
A big problem for me are dolphin's icon sizes. I either can use 64 (too small for my display/my eyes) or 128 (too big, takes up too much space). There are a lot icon themes out there with icon sizes 96x96 and 72x72. Konqueror can show those sizes. Why not dolphin? I hope this will be corrected in the next/KDE4 version.
I hope they have all icons as SVG, and you can zoom pixel by pixel... :D
I think the development of Dolphin as a dedicated file manager is a good idea. However, with Konqueror as it is now, one can easily configure different interface appearances for different uses and save them as separate view profiles. One then just opens the view profile suitable for the purpose to which one is going to put Konqueror.
I'm continueing to play with dolphin and since I can't find any official bug tracker I'm going to post a some suggestions.
1) Bookmarks, there are a few things that could be better with dolphins implimentation of bookmarks:
Firstly you can only access bookmarks from bredcrumb mode, you should have the ability to use bookmarks from the editable url bar. In this mode useing a bookmark should copy the full url of the bookmark to the address bar.
Secondly in bredcrumb mode bookmarks hide the file tree below them, if you browse into /home/me the bredcrumbs will say "home" and nothing but "home" this is annoying if you want to go back up to another part of the filesystem, and IMHO it will slow down a new user from fully learning his way around the Linux filesystem. I think it would be better if you show the full path from / instead
thridly the folder / is called root. That dosn't feel right to me, and again it may slow a user down in learning his way around the filesystem
Finally there is no way, that I found, of makeing a new bookmark without going into configure dolphin. A simple "bookmark this folder" should be found under tools, as well as hotkey and optional toolbar button for the same.
2) file/folder names sometimes cut to a new line in the middle of a word, this is horrid (sorry to be so blunt but it really is), perhaps you could copy konquorers code for this, konquoror dose get it right
3) I think the breadcrumbs could be implimented a little better,
firstly you have folder > folder, wouldn't it make more sense, and fit in better with Liunx to have folder / folder?
and the current system of clicking on a folder then seeing everything in that folder in a drop down menu is nice, but I think if you click a folder it should cut to that folder, and if you click the arrow (or the slash) then you get the drop down menu.
4) Just a small suggestion, there is two seprate hotkeys for switching to bredcrumbs/editable url. There should be one hotkey that switches to whatever one you're not useing.
Note: If you replace the arrows with slashes, and rename root to /, then you'll end up with two slashes in a row, a solution could be to have no name at all for root and then let the following / stand in for the name.
First thanks for your constructive input!
> 1) Bookmarks, there are a few things that could be better
> with dolphins implimentation of bookmarks:
The bookmarks handling in Dolphin will be completely reworked for KDE 4.
> Secondly in bredcrumb mode bookmarks hide the file tree below them
We plan to make this configurable, as there are a lot of pro and cons on both sides, whether a hiding of the physical file hierarchy should be done or not.
> thridly the folder / is called root. That dosn't feel right
> to me, and again it may slow a user down in learning his way
> around the filesystem
We'll discuss this.
> Finally there is no way, that I found, of makeing a new
> bookmark without going into configure dolphin.
Currently it's possible by using the context menu, but I think we'll introduce a "Bookmark" menu to stay consistent with other applications using bookmarks.
> 2) file/folder names sometimes cut to a new line in the middle of a word,
> this is horrid (sorry to be so blunt but it really is)
You're right, it is horrid :-) Will be solved for sure in KDE4, the code for this is shared by Dolphin and Konqi.
> 3) I think the breadcrumbs could be implimented a little better,
> firstly you have folder > folder, wouldn't it make more sense,
> and fit in better with Liunx to have folder / folder?
The look of the breadcrumb will be improved anyway. I'm not sure whether it's better to use "/" instead of ">", but let's see :-)
> and the current system of clicking on a folder then seeing
> everything in that folder in a drop down menu is nice, but
> I think if you click a folder it should cut to that folder,
> and if you click the arrow (or the slash) then you get the
> drop down menu.
There had been some usability tests concerning this point and the outcome was that arrows as drop down have not been perceived very well by the users (it was not clear for the people which directory was shown: the directory before the arrow or after the arrow; also accidentally clicking on the arrows happened).
We are not sure whether the current approach is the best, but we're working on it :-)
> 4) Just a small suggestion, there is two seprate hotkeys
> for switching to bredcrumbs/editable url. There should be
> one hotkey that switches to whatever one you're not useing.
We'll discuss this. I personally also would like a toggle key for this.
Best regards,
Peter
Thanks for replying :) again you're post is filled with good news and I look forward to seeing the results of you're discussions in KDE4-alpha.
Two points I'd like to respond to directly
>> 2) file/folder names sometimes cut to a new line in the middle of a word,
>> this is horrid (sorry to be so blunt but it really is)
>You're right, it is horrid :-) Will be solved for sure in KDE4, the code for >this is shared by Dolphin and Konqi.
Thank goodness :) I'm delighted to hear it.
>There had been some usability tests concerning this point and the outcome was
>that arrows as drop down have not been perceived very well by the users (it was
>not clear for the people which directory was shown: the directory before the
>arrow or after the arrow; also accidentally clicking on the arrows happened).
How long were users exposed to dolphin before the results were recorded? I ask because the confusion of what directory was shown should clear up with a little practice, suggesting that they didn't use dolphin for long. And IMO the real usibiltiy test is not first impressions, but how useable is it after you've had it for a while and learnt you're way around.
> How long were users exposed to dolphin before the results were recorded?
> I ask because the confusion of what directory was shown should clear up
> with a little practice, suggesting that they didn't use dolphin for long.
> And IMO the real usibiltiy test is not first impressions, but how useable
> is it after you've had it for a while and learnt you're way around.
In this test Dolphin was not involved at all. The test has been done at Akademy last year and the result has been posted to kfm-devel: http://lists.kde.org/?l=kfm-devel&m=116377940524940&w=2
Best regards,
Peter
Thanks, I'll read up on that
> should clear up with a little practice
it's a matter of human visual cognition and limitations on fine motor skills. in other words, for most people it would take upgrades to the software in our heads.
Did you mean the accidental cliks? Because I can't see how how being confused as to weather the directory shown was before the arrow or after the arrow is related to fine motor skills.
We're in the 3rd millenium and it's time to think about future of computing and what is the purpose of computers.
Many people seems to make confusion between "computing science is an end itself" and "computer science is a mean to reach its ends".
Most people, hopefully use their computer as a way to achieve a result no matter the technology behind.
I mean, no matter how data is stored (files, database, remotely, localy, ...), no matter what application will manage data (one multi-profile, several dedicated)...
But one thing is sure, data is converging toward multimedia in a seamless access way. trying to spearate datatype access is just adding difficulties...
Example are digital camera: they host videos, photos and audio comment. How do you keep track (and link to the photo) of audio comments with a photo-only mangement software?
How do you see photos related to an audio comment in a audio only software?
The way to go is to render seamless the access and the management of the data just like multiview did in the past on Amiga but with new technology.
A file manager like dolphin is useless when entering a maildir directory (you see useless files, you can't know what to drop, you can't move directories, ...) while a data browser like konqueror could manage the content, move sub-parts and such provided the correct profile and kio is there. (yes kio will exist in dolphin, but it is not designed for such philosophy).
What would be great benefit and great step forward in KDE would be to have a more intuitive seamless data management like the following:
You could have .directory (at the root of specific directories) containing specific profile skinning the browser for optimised browsing according to the content of the directory it resides in. By default, when a new homedir is created, the ~/Video directory would be setup for video browsing, the ~/Mail directory would be setup for Mail browsing, the ~/Photo directory would be setup for photo viewing and so on...
The the data browser would have ONE UNIQUE database used for linking related content (which is impossible with separated apps).
Example, you recieve a mail with a attached photo, the attachment is moved to the Photo library and linked to the original mail (right now, you save the attachment and keep the mail having 2 copies of the attachment in 2 locations and 2 different formats (yes some non kde apps can drop attachment, but the link is lost; fowarding suc a mail will miss the original attachment)).
- Pluging a digital camera would allow to download content in apropriate directories keeping link of audio comments to associated photos.
Later, starting amarok (a profile of the data browser) and seeing updates in the audio directory (subsection comments), would allow to see associated photo for the comment (just like the album photo is associated with a music file).
Later, starting digikam (another profile of the data browser) would allow to hear comment in the photo.
Then how about sending an e-mail with some photos. and the magic includes (at your wish) the related audio comments).
- What about representing maildirs as a file system. A mail (the leafs) would be represented as directories. Entering the directory would display the mail, but staying above could alow to drop files in the virtual folder which is the mail; adding an attachment.
You need to make room on you filesystem...
With the above representation and filelight view, no need to start multiple applications to make space. just remove data whatever it is (a mail subfolder that is obsolete, a file, ...)
You want to remove all records (whatever they are) that are older than a year (problem many companies have regarding the Sarbanes-Oxley law).
No need to start many apps anymore (like file browser, mail browser, exif browser, archive browsers ...)
Just look at the iPhone GUI. did you heard of any file browser? no, there is a media browser.
Speaking of file sohuld raise no more often than speaking of kernel modules. Reserved to Computer Science, not Computer users.
Failing to see this evolution will lead to fall behin future Mac OS-X and Vista. (yes winfs and related app will raise one day)
PS: Having a database based filesystem would help but is not a showstopper.
Think that Microsoft (and far before, Be Inc.) thought about such data representation and the winfs project is not dropped....
Think also about google web based applications that hide the data storage model too.
Programmers are not end users, but they create software they do not use to achieve a task, but to achieve a goal. Gimp vs Krita is perfect example. Gimp was desing by Skilled Graphic computer science programmers: you need to be computer science skilled in order to find how to draw a strait line. Krita was designed by Graphists that have computer science skills: that makes a big difference!
Is KDE4 leading toward skilled computer science programmers leaving out computer end users?
Just my 2 cents.
http://nepomuk-kde.semanticdesktop.org
There is no need for a "data browser" and a conversion of all applications into profiles/kparts.
Seems realy cool project, but while it will (seems to) address the problem of keeping audio comment of photos downloaded from a digital camera I don't see how it could address a common database for media management.
I mean:
- digikam will manage photos
- amarok will manage musics
- kaffeine will manage videos and other multimedia contents
Then, If I use an authoring software to create a DVD, this software will have two choices for media library:
- Have its own library (just like all windows authoring software I know): very likely to happen, and thus some code to write and maintain, plus inconcistencies to manage.
- Have to link with all the above software API (if possible) and manage the different concept of thoses APIs for a similare representation: unikely to happen.
Maybe I didn't read enough though
I've been using GNOME for a long time and recently formated and reinstall a just-KDE Debian Etch to tryout KDE. I'm one who uses both Windows and Linux depending on what I'm doing.
Now, since I switch between two desktop, I won't be interest in spending any extra time to look at diff applications on different platforms. The result is, I uses Azureus for BT, Firefox for browsing, Thunderbird for mail client, etc.
The best thing that KDE users think about KDE is its tight integration (I think, at least). But you should also realise that there're a big group of people who prefer a more "object oriented" approach.
I don't mind to have the library that Konqueror bases on to sit on my computer if it's meant to share code with some other programs (e.g. file manager). But I just do not need Konqueror itself since I uses Firefox and I really don't want Konqueror to be on my computer.
May be KDE should consider not having Konqueror a dependency, but a default option? That way, we who uses *other stuff* can have *one application for each task*. I know KDE4 is aiming for *one app for each task*. And I like the same thing. Doesn't hurt to give us another option huh.
You will be able to use Konqueror in KDE 4 on Windows, I think. :)
Will Dolphin in KDE4 include a directory tree side panel?
I tried the last KDE3 version and the panel only has info and bookmark views, and no tree view, that I need often...
I can't help but wonder why so many filemanagers completely ditch proper tree views...
> I can't help but wonder why so many filemanagers completely ditch proper tree views...
Because programmers are using shell completion as a daily basis and only use their development for testing...
I'm 100% with you on the necesity of a Tree View. I personally don't care for any other sidebar...
> Will Dolphin in KDE4 include a directory tree side panel?
Yes, a directory tree side panel will be supported. I committed an initial version just some hours ago...
Best regards,
Peter
Awesome! I hope it works better than konqueror's!
Konqueror is an awesome file manager. It's got the best thumbnail support, the largest number of views (file size view, tree view, etc), and support for an infinite number of panes, for instance. I would like to see a uber-breadcrumb widget address bar, though.
Konqueror is a mediocre web browser. It's competing with Opera (my 1st choice) and Firefox (a close second). I'd like to see it catch up to Opera's level, however, because I'd like my browser of choice to be open source.
I honestly think Konqueror should be split into a separate File Browser and Web Browser, because they are two completely separate functions. For emphasis, let me emphasize:
___________________________________
|*
|* FILE MANAGING and WEB BROWSING are two
|* COMPLETELY SEPARATE FUNCTIONS!
|*
___________________________________
Splitting Konqueror into two apps would help developers refine these two functions. Having a "web" profile and a "file" profile is a hack. Rather than have two faces for the same app, let there be two apps!
On a separate note, isn't it wonderful how we have as many different proposed solutions as we have people? We can dump Dolphin, use Dolphin, use Krusader, use Konqueror, and so on. That's the great thing about open source: we have so many choices!
> FILE MANAGING and WEB BROWSING are two
> COMPLETELY SEPARATE FUNCTIONS!
I always used to believe this too, but it isn't really true. A web-browser is just a file-viewer which works over http. (Or you could say that a file-viewer is a web browser for local documents!).
In both cases, we have a window, some navigation buttons, a URL-bar, and (usually) multiple tabs. No need for multiple applications, mainly duplicate code, and wasted RAM.
However, when konqui changes context (web/file etc), this ought to change the widget layout automatically.
For example, the [home] button should change context (and probably the icon too) to distinguish /home/me from http://myhomepage.com.
In my view, the "Profiles" thing should be split up into 2 functions:
a)Automatic context switching between GUI and File manager.
b)Something for advanced users, who might actually want multiple home-pages, or file-management profiles.
Currently, it mainly works as (b), but is most commonly used as (a).
>> FILE MANAGING and WEB BROWSING are two
>> COMPLETELY SEPARATE FUNCTIONS!
>I always used to believe this too, but it isn't really true. A web-browser is >just a file-viewer which works over http. (Or you could say that a file-viewer >is a web browser for local documents!).
Exactly my point. I've always thought that this was the point of Konq.
And I love it - if I wanted it different, I would use Firefox and Krusader (you always have to have Firefox around anyway, since there are webpages that Konq can't handle, and Krusader is a great file manager).
"A web-browser is just a file-viewer which works over http."
For example GMail is something like file viewing?!?
Can you explaim me the similarities of the _use_cases_ of "file management/browsing" and "browsing/commenting dot.kde.org"?
Face it. The days were web browsing was (mostly) just viewing static HTML are over. Welcome to the world of Web 2.0!
Yes, GMail is just slightly fancier than a series of static HTML pages. Konqueror is a universal viewer that doesn't care about protocols. If Konqueror didn't embed other kparts then you'd have a point that embeded khtml didn't make much sense, but you can view PDFs, videos, text documents, html files (regardless of how much java script they have) over ANY kio slave, whether thats file, HTTP, sftp, nfs, smb, etc!
Konqueror isn't JUST a file browser like Nautilus, Explorer, and Finder are. It's much closer to an object viewer, regardless where the object is located (in a database, on the local system, or on an http server), or what type of object it is (text, picture, video, audio, html, etc).
So again, being able to view view all of those other formats regardless of format and protocol but NOT html over http wouldn't make any more sense than being able to only 'browse' files and view html over http.
Being able to to view documents regardless to the protocol is a feature of KIO-slaves. So it's not only konqueror, but any application (and kpart) that can do this. Simply try it with any open/save filedialog.
It may be nice for you, that konqueror can display most objects. For me it's more convenient when konqueror delegates the viewing to other applications. Having konqueror always morphing parts of it's interface is simply disturbing me...
and file viewing since when is file-viewing file-managing? dolphin can't view files. thats the point. most websites are like documents, not like a filesystem. a tabbar, navigation buttons and a url input are nothing major that needs to be duplicated. in fact because of different meanings of these elements many need different implementations for any mode anyway.
you end up with many functions only usefull in one mode. you don't rename websites. you don't move them. you can't view websites like a tree. you don't create new websites in a browser. you don't open thins in a webbrowser and you don't have multiple actions for a website.
web browsing and filemanagment are not related at all. in the end webbrowsing isn't related to anything anymore. because of the direction the web is heading, it isn't simple document-viewing-with-hyperlinks like it used to be. many websites today are web-applications.
"you end up with many functions only usefull in one mode. you don't rename websites. you don't move them. you can't view websites like a tree. you don't create new websites in a browser. you don't open thins in a webbrowser and you don't have multiple actions for a website."
Thats mostly just a limitation of the HTTP protocol. If the websites were over any other protocol, you could without any problems. Web Browsing and File Viewing+Management ARE related, web browsing is simply a limited sub set of the functionality.
"Web Browsing and File Viewing+Management ARE related, web browsing is simply a limited sub set of the functionality"
Which subset?
Sorry, but I don't see the similarity. For me those are completely different use cases.