As proposed in another thread it makes sense to harmonize search, filter, and highlight functions. Dolphin, as a core KDE SC application, is one candidate to prove the concept.

Dolphin makes use of the filter function (literally, and as called in the HIG), and has a search function. It does not have a highlighter; most probably the control itself provides another kind of navigation similar to auto-complete: typing the first letters jumps to the first item that consists of this pattern. We shouldn't touch this behavior just in order to make search consistent.

As proposed by the HIG the filter should be placed above the control. It has to use the standard hotkey ctrl+H (since used by KMail or we still use ctrl+I and change KMail).


Figure 1: Filter bar above.

When user enters text, the list below is reduced instantaneously to items that match this pattern. The filter is case-insensitive. The line edit is cleared on changes (e.g. directory up/down) unless the 'lock' is closed. In this case the filter term remains active too.

Second operation, search, has a rather uncommon widget (cf. this blog post) with limited functionality, and it is badly integrated with the sidebar. For example, you cannot look for files the were created in 2013 only, and choosing Documents or Pictures from the sidebar is not linked to the appropriate radio button (but works in the same way). And, when the filter bar will be moved to the top, the position would interfere.

Idea of the HIG was to externalize the Search function. It opens another dialog with the full feature set, such as in Amarok.


Figure 2: Search in Amarok as available right now.

This dialog has to get adopted to Dolphin by using the proper features, whatever options Baloo offers. And it makes sense to refine the interaction. For instance the accessibility is limited, which could be improved when drag 'n drop is supported by the dual list pattern. Furthermore it makes sense to add self-defined presets that can be reloaded later.

Figure 3: Future Dolphin search dialog.
As now, search generates a new result list. Access to this result list can be added to the sidebar until the next search is performed. By doing so the association between the result list and the navigation will be fixed.

Putting all together, to reach consistency as proposed in the HIG, Dolphin has to change the following points:
* Move filter bar from bottom to top
* Change hotkey from ctrl+I to ctrl+H (or KMail and every other app applies ctrl+I)
* Reimplement search

On a side note: in Konqueror ctrl+F shows the 'highlighter bar' in case of a web site. But for a local address the same shortcut opens kfind. On the other hand, perhaps its worth to consider to update kfind and to use it in Dolphin.

Please let me know your opinion.

Great idea to unify the experience across applications, maybe something like a KDE HIG framework should be coded, that contains important UI bits precoded to make it easy to offer consistent style without reimplementing the same search dialog from scratch for every application. In the end application coders would simply include the KDE HIG framework header and type a simple class name and connect signals and slots for their application.
That way even more components can be centralized and bug fixes could simply go to the framework and all applications just need to simply be recompiled to benefit from the changes.
I am not sure what direction KDE wants to go, but I am pretty sure qml right? I think creating a new framework from scratch and orienting its need on existing use cases sounds like a good idea. A consistent, c++/qml framework could be created, where the designers can work with qml to make the best design wise and all coders would benefit from it.
I think it would be important for such a framework to be easily reusable outside KDE, so it should without any doubt be a trier 1 framework that can be simply used on top of any Qt application to make it also attractive to Qt only programmers.

Heiko Tietze wrote:As proposed in another thread it makes sense to harmonize search, filter, and highlight functions. Dolphin, as a core KDE SC application, is one candidate to prove the concept.

Dolphin makes use of the filter function (literally, and as called in the HIG), and has a search function. It does not have a highlighter; most probably the control itself provides another kind of navigation similar to auto-complete: typing the first letters jumps to the first item that consists of this pattern. We shouldn't touch this behavior just in order to make search consistent.

As proposed by the HIG the filter should be placed above the control. It has to use the standard hotkey ctrl+H (since used by KMail or we still use ctrl+I and change KMail).

I'm only going to comment on the shortcut keys and my vision there. It's just a brainstorm idea, but might be worth a consideration.

Both filtering and more advanced searching should imho be available under one shortcut key:
CTRL+f

By default it should show a very simplistic filtering mechanism that either:
- removes the lines that don't match the stuff the user typed in
- highlight the lines that do match what the user has typed in (here all lines would stay)

So far for the possible filtering definitions that make sense to me.

For searching the user should also press "CTRL+f". In the filter input field there should be an "advanced" option which would then allow the user to specify more options.

I'm proposing this because you "mostly" want to find something that is in your current folder (thus filtering). However, every app has a different filter/search mechanism which makes the right tool for the job a bit difficult to find. I for instance didn't even know about dolphin's "filter" input till about a year ago. I was always using "ctrl+f" where i actually wanted "ctrl+i". Ctrl + i (or ctrl + h) have absolutely nothing to do with filtering. What does the "i" or "h" stand for? I can vaguely imagine the "i" standing for "input", but "h"..? No clue there.

What a user wants is "find" or "filter" so the user will try "ctrl+f" first. Another reason is that basically all apps out there use ctrl+f for "searching" and "filtering". It kinda depends on how you define both terms. If we look at chrome for example. ctrl+f brings up a input field where it's highlighting anything on the current page that you type in that field.

If we look at konversation, it opens a "find" line when pressing "ctrl+f". It's acting the same like chrome's ctrl+f. Aka, it highlights the stuff in the current content that matches what the user typed.

Another argument against ctrl+i is the different meaning it can have. In both konversation and kwrite there is also ctrl+i, but there is means indentation.

markg85 wrote:Both filtering and more advanced searching should imho be available under one shortcut key:
CTRL+f

What we'd have to solve then is applications which have both, for example KMail: There you can filter the list of emails, but also search within the currently shown email. One could make the effect of Ctrl-F dependent on whether the list or the mail preview currently have focus, but that would probably confuse more than it would help.

Thanks for the detailed presentation of your ideas and the nice mockups, Heiko!

Note that I have hardly been involved at all with implementing the search and filter features in Dolphin, but I definitely appreciate all efforts to make them better.

I know that it has even been suggested a few times that the features are merged or that one of them is dropped. I agree that it may be confusing that both exist, but I know from user feedback (e.g., bug reports) that both features are used by many users for different purposes. In any case, this does not mean that I'm completely against radical changes (I'm not looking forward to the angry bug reports though which will certainly come if we remove anything that some people use regularly ).

About the shortcut for filtering:

I agree that making the shortcuts in all KDE apps consistent makes sense, but at the same time, changing default shortcuts can be painful for users who got used to a certain shortcut and use it frequently.

In principle, one could keep the 'old' shortcut as a secondary default shortcut in order to prevent breaking users' workflows, but this would pollute the space of available shortcuts.

By the way, is there a reason why Ctrl+H is considered better than Ctrl+I? I do not know why Ctrl+I was chosen in Dolphin, I'd have to do some source code archaeology to find out. If it turns out that there was no good reason for Ctrl+I and that Ctrl+H is more common, then changing it might indeed make sense.

About the idea to move the filter bar up:

That might make sense, but should it really be above the location bar, like in your mockup? If the location bar is in 'editable' mode, then there will be two line edits next to each other - the upper one would be the filter text, and the lower one would show the URL. Maybe they should be swapped, such that the URL is shown above the filter text?

About the separate "Search" dialog:

This looks like a nice idea! In particular because it makes a much more flexible search possible - the current widget looks a bit packed already, and we should probably not add more stuff to it.

I see a possible disadvantage though:

Right now, the search starts (with a small delay) as soon as any text is entered (even without pressing Enter), and the search text can be changed quickly if the search results are not what the user wants. With the separate dialog, starting a search, and especially changing a search, would take considerably more effort.

Have you thought about this?

BTW since you mentioned KFind, Ctrl+F actually did open KFind a few years ago


Thanks again for your ideas - I'm looking forward to further discussions on these topics (I might not be able to reply during the weekend though).

freininghaus wrote:...is there a reason why Ctrl+H is considered better than Ctrl+I? I do not know why Ctrl+I was chosen in Dolphin, I'd have to do some source code archaeology to find out.

Please don't change your occupational field!
We just had to choose between KMail and Dolphin (most other filter in terms of reducing a list have the input always visible). And actually I think it worth to take a look if we can have one short-cut for filter as well as highlight. I like this idea since we want to make the simple filters really simple. And users do not care about the subtle difference between filter types.

freininghaus wrote:About the idea to move the filter bar up:...Maybe they should be swapped, such that the URL is shown above the filter text?

With the Gestalt law of proximity in mind we have to keep input and output close together. The proposal indeed adds a visual break resulting from the sequence of input with lowered bevel (the filter bar), text without bevel (breadcrumb in normal mode), and beveled output (the file list). (Actually I'm re-describing my proposal because I thought I have done it the way you propose and you expect it vice versa). But isn't the filter bar closed by default in Dolphin? That means the breadcrumb jumps up when the filter is opened. I'm curious about what visual experts think about this issue.

freininghaus wrote:About the separate "Search" dialog:... Right now, the search starts... as soon as any text is entered (even without pressing Enter), and the search text can be changed quickly if the search results are not what the user wants.

Is this really a valid use case? I guess it's a nice-to-have but never used feature. But you are right, we didn't consider this option.

Many thanks for taking the time.

Heiko Tietze wrote:

freininghaus wrote:About the separate "Search" dialog:... Right now, the search starts... as soon as any text is entered (even without pressing Enter), and the search text can be changed quickly if the search results are not what the user wants.

Is this really a valid use case? I guess it's a nice-to-have but never used feature. But you are right, we didn't consider this option.

[/quote]

I think there are valid usecases for not wanting to open the dialog again just for a small adjustment of the search query, for example if I only realize when I see the empty result set that I made a typo in the search string.

Okay, here is a rather radical idea. It will probably sound scary at first to everyone who reads it, but I think it should at least work as a basis for discussion:

When just a simple string is entered into the filter bar, it just filters on the currently visible items.

However, when a search query (prepended with a keyword such as "Search:" or something) is entered, it performs a search with Baloo. This can be used directly by power users who can compose those queries manually. For all others there is the Search dialog as proposed by Heiko which builds the query for you and inserts it in the bar. Then if the user notices for example that they made a typo somewhere, they can quickly modify that specific part of the complex query string.

These are the advantages and disadvantages I see:
+ The query is visible next to its results
+ The query can quickly be adjusted without necessarily having to open the dialog again
+ Power users can do without the dialog altogether
- No clear separation between filter and search (other than the keyword)
- The prominently visible query strings may scare users

If people here find the idea generally worthy of thinking through, we might come up with ways to ameliorate the disadvantages without sacrificing the advantages. After all, this is just a rough idea.

The good news is that the query that colomar talks about doesn't have to look that scary... Anybody remember this one?

This would make truckloads of sense - have a nice, easy to use search dialog that puts together one of these slightly harder but still intuitive query lines... Easy to adjust, not scary, but nice and colorful And steckdenis is still active and even recently lamented he hasn't yet updated this query builder widget to Baloo. Well, time to get started

jospoortvliet wrote:The good news is that the query that colomar talks about doesn't have to look that scary... Anybody remember this one?

Wow, that's really cool! I just invited him per email (if I found the right one).

Hi,

Heiko Tietze did a good job, I'm the developer of the query parser you are talking about. I'm most than happy that you find my work interesting!

The great news is that the parser itself has been merged into Baloo yesterday, and will be available either this summer or in Frameworks 5. The parser handles every type of query supported by Baloo (but Baloo supports less filters than Nepomuk did, and the super-complete filtering dialog shown at the beginning of this thread comes from Nepomuk), and can be translated (the second screenshot of http://steckdenis.be/post-2013-09-25-the-end-of-the-google-summer-of-code.html shows how the parser handles French).

The query parser also comes with a "query builder widget", that is shown integrated into Dolphin in the blog post you link. The review request for that is https://git.reviewboard.kde.org/r/112589/ (but it will need to be updated as Baloo is not completely compatible with Nepomuk). The UI of the query builder widget is an experiment and made to show all the features of the parser. Maybe something way nicer can be done .

steckdenis wrote:...but Baloo supports less filters than Nepomuk did, and the super-complete filtering dialog shown at the beginning of this thread comes from Nepomuk

Do you refer to the Amarok dialog? Is it possible to use your query parser without Baloo, to get it work in application that have a search but does not use this engine? Because the basic idea is to have a unique search in all KDE SC apps.

The query parser lives in Baloo and depends on Baloo Core (Baloo Core is a very lightweight library that only defines what is a query and what is a term). You give the parser a string, and it returns a Baloo::Term, that contains the parse tree of the string. If you want, you can use this Term yourself, without using any of the Baloo search functions. What I wanted to say is that the query parser cannot represent what cannot be put into a Baloo::Term, because it uses Baloo::Term as its abstract syntax tree.

So, it may be possible to use the parser without Baloo, but I think that what the Baloo developers want is to make Baloo the "unique search in all KDE SC apps". Baloo is quick and lightweight, built around Xapian, and does not use fancy servers like Nepomuk did.

I agree: We don't want applications to build their own complex search engines anyway. Search is done by Baloo, period.

colomar wrote:I agree: We don't want applications to build their own complex search engines anyway. Search is done by Baloo, period.

Can you explain how Baloo is better to do search query than what example digiKam does with SQL database?
Can Baloo really implement ALL the needed features what IPTC and EXIF standards include and other features what digiKam offers like "Fuzzy Search"?
Meaning user can draw a sample to canvas and then digiKam will query photos what looks similar?
Or that user selects a photograph and say "Search this kind photos" and they are presented to user?

Or features like geographical location by allowing user to narrow area on map to show photos from that area, combine them with the any other metadata from photos from date, type, rating, person, format etc?

It is easy to say that Baloo can do everything, but it is only related to textual data what can be indexed in specific manner and then present that index in simple manner. But when it is required to have very complex visual information from hundreds of thousands large files, Baloo seems to drop out quickly from the game.
And can Baloo do the search from external source (memory card) without storing any data locally and before data is imported? Example input memory card and do a search based above queries (geographical etc)?

Of course if Baloo can do it, it would be good marketing material for KDE.

Searches based on an application's own database probably can do more than Baloo, that's true.
Would it be possible to make search strings created by Baloo Core work with these databases?