First of all, thanks for taking the time to file this report.

Please note:

(a) Handling the endless stream of incoming bug reports and feature request is already *extremely* challenging for our small team of volunteers. It doesn't really get any easier if multiple unrelated issues are reported in one single report. Please don't do that. Thanks.

(b) bugs.kde.org is *completely* unsuitable for discussing user ideas. Few people read incoming reports. In particular, users who do not approve of your ideas to change the behavior are very unlikely to read this report and comment here. A much better place to discuss ideas is the KDE Brainstorm section of the KDE forums:

http://forum.kde.org/viewforum.php?f=83

If an idea that is discussed there is very popular, and no user finds any obvious flaws, feel free to tell us about it, either here or on the mailing list.

Moreover, I don't really want to question your abilities to judge what changes might improve the usability, but maybe a discussion on the usability mailing list is the best way to find out about that (preferably, after the idea has been discussed in the Brainstorm forum).

Most of what you suggest here has already been discussed. I'll add some links that I still remember below. Please try at least a quick search of the existing reports before filing new reports in the future. This really makes our work easier :-)
 
(In reply to comment #0)
> Allow for side-panels to be also arranged side by side.
> - For instance: "Places" left and immediately at its right side "Folders".
> This would in some cases result in a better overview and even faster
> navigation.

It is unclear to me why this improves usability so much that the additional complexity in the user interface and the code (AFAIK, Qt does not support this way to arrange dock widgets at all, so you would have to request that feature from Qt itself) is justified. Feel free to discuss it in the forum, but note that (if I'm not mistaken) there is nothing we can do about it unless it's implemented in Qt.

> Allow for separators (or some other kind of structure) in "Places".
> - This would improve orientation.

Then please explain exactly what kind of workflow you have in mind for adding these separator (How should it work? What should the user do to add a separator?) when you suggest this in the forum.

> When closing a split view, the in-active window should close, not the
> active. 
> - It is almost always the active window that one focuses on and for which on
> wants more space.

Has been discussed extensively already. See, e.g., bug 312834.

> Like the search-bar the filter-bar should be placed at the top, not at the
> bottom of the window.
> - In general, search-/filter-bars at the bottom of a window don't seem to be
> ergonomically sensible solutions.

See the discussion in

http://forum.kde.org/viewtopic.php?f=285&t=121393
 
> A browsing-history in the address-bar would be helpful
> - Sometimes this would be a faster way to go back to a certain address -
> compared to hitting the "Back"-button many times.

Already requested, see bug 171037.

> In the "Details"-view I would prefer to (optionally) see the size of folders
> instead of the number of elements.
> - This would better help to see where cleanup is profitable.

I can't find the link now, but this has been discussed as well. The feature may seem nice at first sight, but please note that this would require that your entire home directory, including all subfolders, is scanned file by file every time you open Dolphin. This would require an amount of disk activity that is not acceptable for the vast majority of users.

> An option to set the view-mode for all (sub-) windows simultaneously to
> "Compact" etc. would be nice.

Please describe situations in which this would be useful, and how you would like to see this implemented in the user interface when you start a forum discussion about this issue.

> In addition to the vertical split-view a horizontal split-view should be
> offered as well.

Already discussed: bug 168592. The bottom line is: if horizontal splitting is important for you, there is a file manager which uses Dolphin's code and which has this feature: Konqueror :-)

I'm closing this report now - I hope that you can understand that. Thanks.

Some additional comments:

> AFAIK, Qt does not support this way to arrange dock widgets
It does, see http://doc-snapshot.qt-project.org/qt5-dev/qmainwindow.html#dockNestingEnabled-prop I am not sure, however, if enabling this leads to worse usability.

> Allow for separators (or some other kind of structure) in "Places".

See bug 169751. Note that currently the implementation of the Places panel in Dolphin and in the file dialog are separate, they might get merged in the future. See bug 309620 for more details.

> A browsing-history in the address-bar would be helpful

Bug 171037 is related, but does only mention saving of the history, not a way to access the entries quickly (e.g. keeping the back button pressed for a longer time, a popup menu could open, or by using combined buttons as in Konqueror).

(In reply to comment #2)
> > AFAIK, Qt does not support this way to arrange dock widgets
> It does, see
> http://doc-snapshot.qt-project.org/qt5-dev/qmainwindow.

Thanks, I didn't know that.

> html#dockNestingEnabled-prop I am not sure, however, if enabling this leads
> to worse usability.

I'm not sure either - even the Qt documentation warns that "dock nesting leads to more complex (and less intuitive) behavior when a dock widget is dragged over the main window".

> > A browsing-history in the address-bar would be helpful
> 
> Bug 171037 is related, but does only mention saving of the history, not a
> way to access the entries quickly (e.g. keeping the back button pressed for
> a longer time, a popup menu could open, or by using combined buttons as in
> Konqueror).

Sorry, I did not check the reports closely enough because I (unsuccessfully) tried to finish my reply before the World Cup match last night. I think bug 157819 is a better match for the suggested history improvement.

(In reply to comment #1)
> First of all, thanks for taking the time to file this report.
> 
> Please note:
> 
> (a) Handling the endless stream of incoming bug reports and feature request
> is already *extremely* challenging for our small team of volunteers. It
> doesn't really get any easier if multiple unrelated issues are reported in
> one single report. Please don't do that. Thanks.
> 
> (b) bugs.kde.org is *completely* unsuitable for discussing user ideas. Few
> people read incoming reports. In particular, users who do not approve of
> your ideas to change the behavior are very unlikely to read this report and
> comment here. A much better place to discuss ideas is the KDE Brainstorm
> section of the KDE forums:
> 
> http://forum.kde.org/viewforum.php?f=83
> 
> If an idea that is discussed there is very popular, and no user finds any
> obvious flaws, feel free to tell us about it, either here or on the mailing
> list.
> 
> Moreover, I don't really want to question your abilities to judge what
> changes might improve the usability, but maybe a discussion on the usability
> mailing list is the best way to find out about that (preferably, after the
> idea has been discussed in the Brainstorm forum).
> 
> Most of what you suggest here has already been discussed. I'll add some
> links that I still remember below. Please try at least a quick search of the
> existing reports before filing new reports in the future. This really makes
> our work easier :-)
>  
> (In reply to comment #0)
> > Allow for side-panels to be also arranged side by side.
> > - For instance: "Places" left and immediately at its right side "Folders".
> > This would in some cases result in a better overview and even faster
> > navigation.
> 
> It is unclear to me why this improves usability so much that the additional
> complexity in the user interface and the code (AFAIK, Qt does not support
> this way to arrange dock widgets at all, so you would have to request that
> feature from Qt itself) is justified. Feel free to discuss it in the forum,
> but note that (if I'm not mistaken) there is nothing we can do about it
> unless it's implemented in Qt.
> 
> > Allow for separators (or some other kind of structure) in "Places".
> > - This would improve orientation.
> 
> Then please explain exactly what kind of workflow you have in mind for
> adding these separator (How should it work? What should the user do to add a
> separator?) when you suggest this in the forum.
> 
> > When closing a split view, the in-active window should close, not the
> > active. 
> > - It is almost always the active window that one focuses on and for which on
> > wants more space.
> 
> Has been discussed extensively already. See, e.g., bug 312834.
> 
> > Like the search-bar the filter-bar should be placed at the top, not at the
> > bottom of the window.
> > - In general, search-/filter-bars at the bottom of a window don't seem to be
> > ergonomically sensible solutions.
> 
> See the discussion in
> 
> http://forum.kde.org/viewtopic.php?f=285&t=121393
>  
> > A browsing-history in the address-bar would be helpful
> > - Sometimes this would be a faster way to go back to a certain address -
> > compared to hitting the "Back"-button many times.
> 
> Already requested, see bug 171037.
> 
> > In the "Details"-view I would prefer to (optionally) see the size of folders
> > instead of the number of elements.
> > - This would better help to see where cleanup is profitable.
> 
> I can't find the link now, but this has been discussed as well. The feature
> may seem nice at first sight, but please note that this would require that
> your entire home directory, including all subfolders, is scanned file by
> file every time you open Dolphin. This would require an amount of disk
> activity that is not acceptable for the vast majority of users.
> 
> > An option to set the view-mode for all (sub-) windows simultaneously to
> > "Compact" etc. would be nice.
> 
> Please describe situations in which this would be useful, and how you would
> like to see this implemented in the user interface when you start a forum
> discussion about this issue.
> 
> > In addition to the vertical split-view a horizontal split-view should be
> > offered as well.
> 
> Already discussed: bug 168592. The bottom line is: if horizontal splitting
> is important for you, there is a file manager which uses Dolphin's code and
> which has this feature: Konqueror :-)
> 
> I'm closing this report now - I hope that you can understand that. Thanks.



All my suggestions are based on long experience with "Idoswin/Idoswin Pro(c)" (by Ingo Eckel). So I know such features are useful. Configuration is easy.

You may want to take a look at it, says more than thousand words. I think it's freeware now.

I'm not affiliated with Idoswin or its developer in any way. But I think it's great software - hand in glove for me from the start.

OM

p.s.: If you don't want suggestions/wishlist here, take that choice off the dropdown-list.

(In reply to comment #4)
> All my suggestions are based on long experience with "Idoswin/Idoswin
> Pro(c)" (by Ingo Eckel). So I know such features are useful. Configuration
> is easy.

No, configuration is not easy at all. "Just add a new option" always looks like the easy way to solve a problem. But even if we ignore completely that every new configuration option introduces new code paths and thus makes extensive testing considerably more difficult, such that the code quality will definitely suffer in the long term (always keep in mind that the number of people who work on Dolphin is very small, and they are all volunteers who can contribute just a few hours a week): every new option makes the user interface more complex, and the more options we have, the harder it will become to use the application.

I'm not saying that we won't add any new options, but since adding an option can be harmful for both usability and maintainability, we have to evaluate if an option is useful enough for a large part of our user base before we can consider adding it. This is why I suggsted that you propose your ideas in the Brainstorm forum and discuss them with other users.

> p.s.: If you don't want suggestions/wishlist here, take that choice off the
> dropdown-list.

Well, in some cases it may make sense to file a wishlist report. Sometimes, there are ideas for small changes which are uncontroversial, and which are very unlikely to annoy other users and/or harm the quality of our software. For everything else, you are exptected to provide evidence that the idea will be beneficial for many users, which is impossible to do here at bugs.kde.org. Discussing it with other users and/or the usability team is necessary.