This topic is the attempt to factor out one aspect of viewtopic.php?f=285&t=121288 since that discussion is mostly about the search dialog now.

To make it easier to imagine what the Dolphin window will look like if the filter bar is moved above the view, I have created screen shots of the current state of Dolphin and two modified versions, both in the "breadcrumb" mode and the "editable mode" of the location bar (F6 can be used to switch between both - alternatively, Ctrl+L can be used to switch to "editable mode" and select the URL):

The current state:


This violates the HIG according to Heiko, and should therefore be changed.

Filter bar on top (proposal from viewtopic.php?f=285&t=121288):


With this solution, the location bar will move down as soon as the filter bar is opened.

Moreover, I somehow have the feeling that having two line edits next to each other (if the location bar is "editable") may be a source of confusion, and I'm not sure which one should better be placed on top, so I also tried the other option:

Filter bar between location bar and view:

It should definitely be placed under the breadcrumb in my opinion, since it changes the current view, and not the URL. As the HIG states:

Show the filter pattern above the list of items.

However, I think I personally prefer its current location at the bottom for the following reasons:
1. As you show in the screenshot, it looks cluttered to have two text boxes on top of each other.
2. It separates "search" from "filter".
3. Filtering should only act on the current view. For this reason, I like how currently the view stays the same when you show the filter bar. If you were to move it to the top, the icons in the view would be pushed down every time you showed the filter bar (and up again when you close it).

I'd prefer and am used to the current placement (one gets comfortable with what uses over time) but if it was changed I would prefer under the location bar making it consistent with the search dialog and it seems a more logical placement visually with the data dropping thru the filter.

One of the reasons I like it at the bottom is that I keep it displayed and would find my focus being stolen by the red x (as is the purpose or making the "x" red).

On a related topic I do miss the "filter by type" drop down in Konqueror

Hans and google01103: One of the reasons to think about moving the filter bar to the top of a list was to distinguish it clearly from the 'highlighter'. Do you think that avoiding clutter (I admit it looks weird) is more important than consistency? I don't ask provocative, sorry of it sounds so.

Another example for lists with filter would be Amarok. Highlighter are found in text handling tools like Kate or as well Konqueror.

re: consistency - as I'm sort of late to these discussions so I need to ask has the placement of search been discussed in regards KDE apps in general as Kate, Digikam & Konqueror have their's on the bottom. It just seems that currently there is a lack of consistency on the placement of the search field within KDE SC apps so not sure consistency is paramount unless it changes universally

Not sure about highlighters in Dolphin as I like the idea of having the filtered subset and being able to operate on all or just some of the filtered files, highlighting even with automatic selection would be more cumbersome especially on filtered list that needed to be scrolled. I'm not sure what advantages highlighting in file management brings.

google01103 wrote:re: consistency - as I'm sort of late to these discussions so I need to ask has the placement of search been discussed in regards KDE apps in general as Kate, Digikam & Konqueror have their's on the bottom. It just seems that currently there is a lack of consistency on the placement of the search field within KDE SC apps so not sure consistency is paramount unless it changes universally

The HIG distinguishes between a filter (which reduces a list of items to those that match a query) and a "highlighter" which highlights a string within an open document, as they work in a fundamentally different way.
Other examples of filters (besides Dolphin and DigiKam) are the quick search in KMail (and many other Kontact applications), the collection or playlist filters in Amarok or Juk, the filters in Kickoff, the Add Widgets dialog or the Activity Switcher, or the contact list filters in KTp and Kopete. Except for KTp, all of those filter bars are above the list to be filtered.
Examples of highlighters are the search in Kate, Okular, browsers, LibreOffice, Calligra. All of those are placed below the document view.
Once you distinguish these two, the seemingly inconsistent positioning turns into a clear pattern, with only Dolphin, DigiKam and KTp standing out.

Not sure about highlighters in Dolphin as I like the idea of having the filtered subset and being able to operate on all or just some of the filtered files, highlighting even with automatic selection would be more cumbersome especially on filtered list that needed to be scrolled. I'm not sure what advantages highlighting in file management brings.

That was a misunderstanding. We want to keep the filter in Dolphin, don't worry

Heiko Tietze wrote:Hans and google01103: One of the reasons to think about moving the filter bar to the top of a list was to distinguish it clearly from the 'highlighter'. Do you think that avoiding clutter (I admit it looks weird) is more important than consistency? I don't ask provocative, sorry of it sounds so.

Another example for lists with filter would be Amarok. Highlighter are found in text handling tools like Kate or as well Konqueror.

I haven't had time to read the whole discussion, so I apologize if I bring up points that have already been discussed.

Personally I don't see the need to distinguish those two - the filter and highlighter both achieve the same thing, they let me find something in the current view. On the other hand, the find function in Dolphin is completely different - it changes the items in the view.

If I were to make a general rule of thumb, it would be something like this:
- If it is a "dynamic" filter/highlighter bar (gets shown and hidden often), show it at the bottom to not disrupt the view when shown/hidden.
- If it is a static filter/highlighter bar, show it at the top (e.g. Amarok, lists in System Settings, Add Widgets).

I've also been thinking about showing the filter bar in a "popup" similar to the search in Chrome (I think a comment in the blog post mentioned this as well), but it has the problem of hiding elements and would probably look strange if shown all the time.

Hans wrote:If I were to make a general rule of thumb, it would be something like this:
- If it is a "dynamic" filter/highlighter bar (gets shown and hidden often), show it at the bottom to not disrupt the view when shown/hidden.
- If it is a static filter/highlighter bar, show it at the top (e.g. Amarok, lists in System Settings, Add Widgets).

Sounds reasonable to me. But what do we do with the search or rather the resulting query parser - it would be inserted at the bottom, and what if both features are available (KMail: following the idea the filter inputs is below the list of mails, and highlighter is below mail content)?

Hans wrote:If I were to make a general rule of thumb, it would be something like this:
- If it is a "dynamic" filter/highlighter bar (gets shown and hidden often), show it at the bottom to not disrupt the view when shown/hidden.
- If it is a static filter/highlighter bar, show it at the top (e.g. Amarok, lists in System Settings, Add Widgets).

That rule is logical, but I'd find it quite hard to tell which filter bars should be "dynamic" and which should be "static". It seems to me that currently it comes down to whether the filter bar is shown by default or not. If it's hidden by default, users are used to the application's appearance without it, so they hide it again after using it. If it's visible by default, people are used to it so they don't bother to hide it (if that's even possible).
Compare Kopete and KDE Telepathy, for example. Both are instant messengers, they are for exactly the same tasks.
Yet, Kopete shows their filter bar by default, above the list, whereas KTp only shows it on demand, below the list. There is no logical explanation for the difference, it was just the devlopers' different taste.
Showing a filter bar above the content on demand of course has the problem that the content below gets moved, whereas when it's shown below the list just scrolls a bit more.

To be honest, I don't see an important point for "dynamic filter bars" at all. They are not so big that they are annoying. I didn't ever mind the filter bars in Kopete, Amarok, KMail etc.

So unless we find a clear rule for deciding which filter bars should be static or dynamic, I'd vote for consistency so that users always know where to expect the filter bar.

Hans wrote:If I were to make a general rule of thumb, it would be something like this:
- If it is a "dynamic" filter/highlighter bar (gets shown and hidden often), show it at the bottom to not disrupt the view when shown/hidden.
- If it is a static filter/highlighter bar, show it at the top (e.g. Amarok, lists in System Settings, Add Widgets).

That could work as long both of those can be opened and closed exactly the same way.

- If I press Ctrl+I to do a filtering, I want to be able press Ctrl+I to hide the filtering and return to previous state with new selection (if I made such).
- If I press Ctrl+F to do a search, I want to be able press same combination to hide search.
- If I click button in toolbat to open search/filter, I want to be able to click that same button to hide it.


Remove the "Close" button from those panels if it gets opened via button or shortcut. If user knows how to press a shortcut, then repeating it will close it.
If user clicks button in toolbar, its state needs to be "pushed down" and re-clicking it would hide the function again.

Seeing a close button, seeing it front of input box or next to search button is bad.
It isn't just disturbing now, it tricks (or forces) user to move hand on mouse to get the dialog closed from different place than it was opened.

Fri13 wrote:That could work as long both of those can be opened and closed exactly the same way.

- If I press Ctrl+I to do a filtering, I want to be able press Ctrl+I to hide the filtering and return to previous state with new selection (if I made such).
- If I press Ctrl+F to do a search, I want to be able press same combination to hide search.
- If I click button in toolbat to open search/filter, I want to be able to click that same button to hide it.


Remove the "Close" button from those panels if it gets opened via button or shortcut. If user knows how to press a shortcut, then repeating it will close it.
If user clicks button in toolbar, its state needs to be "pushed down" and re-clicking it would hide the function again.

Seeing a close button, seeing it front of input box or next to search button is bad.
It isn't just disturbing now, it tricks (or forces) user to move hand on mouse to get the dialog closed from different place than it was opened.

I agree, the close button is more distracting than it is helping.

Making Ctrl+I hide the filter bar probably makes sense (we would also have to adjust the text of the action dynamically from "Show Filter Bar" to "Hide Filter Bar" then, or add a checkbox to the action in the menu).

I'm not sure if removing the close button is really a good idea though. Advanced users know how to close it, but others might not. In my experience, it is not uncommon to see inexperienced users who have messed up the GUI of applications or the entire desktops in some way and do not know how to revert the change. Removing the close button won't help if someone did not remember where in the menu they clicked to show the filter bar, or if they hit the shortcut accidentally (I don't know if this is a common phenomenon, but sometimes I hit some shortcut accidentally which triggers a feature that I never heard of, and then I have to spend some time to figure out how to revert that change).

freininghaus wrote:Making Ctrl+I hide the filter bar probably makes sense (we would also have to adjust the text of the action dynamically from "Show Filter Bar" to "Hide Filter Bar" then, or add a checkbox to the action in the menu).

I'm not sure if removing the close button is really a good idea though. Advanced users know how to close it, but others might not. In my experience, it is not uncommon to see inexperienced users who have messed up the GUI of applications or the entire desktops in some way and do not know how to revert the change. Removing the close button won't help if someone did not remember where in the menu they clicked to show the filter bar, or if they hit the shortcut accidentally (I don't know if this is a common phenomenon, but sometimes I hit some shortcut accidentally which triggers a feature that I never heard of, and then I have to spend some time to figure out how to revert that change).

Several KDE PIM applications have filter bars which can be switched on and off, none of them have a button on the filter bar to do so. And I don't think an entry in the "View" menu would be too hard to find. It would change our understanding of that filter bar slightly, though. Currently, the filter bar in Dolphin is clearly meant to be a temporary thing, whereas in KMail, for example, the filter bar stays there unless users explicitly decide they don't like it. It's just always there by default.
If we combine filter and search in Dolphin, I think it makes sense to have it more permanently.

Take a cue from Nautilus here: use more padding and different colouring. It does look stuffy and confusing with location entry enabled simultaneously. Using those two means for separation could work wonders.

freininghaus wrote:I'm not sure if removing the close button is really a good idea though. Advanced users know how to close it, but others might not. In my experience, it is not uncommon to see inexperienced users who have messed up the GUI of applications or the entire desktops in some way and do not know how to revert the change.

In usability studies it is found that people then simply reverse their actions what they did. And if they can't reverse their actions and is required or suggested to do something else, it gets complex. That's why even simple actions are hard to many like selecting a file and then de-selecting a file. They do selection with pointing and clicking file and then they want to de-select the file in same manner by pointing and clicking. So when requiring to click to empty space between files to de-select the file it creates a huge problem as there is no any kind visual hint that needs to be done as it isn't the way how they ended up to select the file in first place.
And that was reason why the KDE got feature to select and de-select files with + and - icons top left of the file icon itself. It is clear and easy to average user to select one or multiple files and then de-select them one by one as well.

Of course experienced users know how to de-select file but even they mistakenly click then files what they did not want to click etc.

Removing the close button won't help if someone did not remember where in the menu they clicked to show the filter bar, or if they hit the shortcut accidentally (I don't know if this is a common phenomenon, but sometimes I hit some shortcut accidentally which triggers a feature that I never heard of, and then I have to spend some time to figure out how to revert that change).

They do remember it unless they mistakenly went to the menu and clicked the option. And that example you gave works for everything as if user does unknowingly something by mistake, then reversing it is challenge to anyone no matter of the skills as they first need to knowledge what just happened, why it happened and then find way around.

The shortcut accident is very flawed actually. Normal people have even hard time to press two keys simultaneously like Ctrl+X and Ctrl+V. Should we remove those shortcuts as well from default because Cut function is very destructive?

Many argued that Ctrl+M shortcut to hide menubar is very terrible because it is so easy to trigger it. Now look the combination, you would need to use Ctrl first for something, what average user doesn't do. And once you learn Ctrl+C and Ctrl+V shortcuts the M letter is two buttons further to right. Ctrl+P and Ctrl+O shortcuts are as well totally different part of keyboard.

And if the shortcut is destructive (Ctrl+X and Ctrl+S) or hazardous (Ctrl+Q or Ctrl+W), then that shortcut can simply be empty by default and allow user to enable it if wanted.

But now the Ctrl+I shortcut is one what can be opened with keyboard but to get it closed quickly with keyboard is tricky.
But we need some useful shortcuts and standard shortcuts globally and per application window.