Fri13 wrote:

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.

From what I understand of Baloo's architecture, it is quite different from nepomuk in exactly this regard. In this case digiKam developers would have a 'baloo plugin' that searches the digiKam database and provides the result via the Baloo API - it wouldn't be taking anything over. For example - Nepomuk used to duplicate mails from Akonadi in it's database, Baloo just uses Akonadi if it needs the mail - it only has a Xapian database for search (which is directly used by Akonadi to search stuff in its database). The two are essentially intertwined. I guess it is worth a discussion how Baloo and digiKam could benefit from each other, but I would bet that a solution would not involve trowing any code away on the digiKam side and re-implementing stuff in Baloo. More like digiKam offering Baloo access to its database so other applications can use Baloo's API to find stuff in it.

See http://community.kde.org/Baloo/Architecture

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

And not just behind it, the search bar needs to be able get closed with same way as it was opened.
If you press Ctrl+F second time then it gets closed.
If you click "Search" button in toolbar, then it gets closed.

The red close button at start of the search bar is confusing and very annoying as you need to move/use mouse to close the bar instead use same method as you got it open in first place.

And I would say that it needs to be gone... When user press Ctrl+F then acivate same time the toolbar button. When user clicks the toolbar button then open then user see as well that the button is pressed down.

In some situations "Open" and "Close" buttons needs to be separated, like in elevator for doors. But search panel isn't one of them if it requires mouse movement, or eye movement when searching the button to close it or the close button is on the way when doing the search.
It needs to be like KickOff menu. Click once to open and second time to close. Press shortcut to open or close. Or combine them.
MUCH more familiar functionality immediately.

jospoortvliet wrote:For example - Nepomuk used to duplicate mails from Akonadi in it's database, Baloo just uses Akonadi if it needs the mail - it only has a Xapian database for search (which is directly used by Akonadi to search stuff in its database). The two are essentially intertwined. I guess it is worth a discussion how Baloo and digiKam could benefit from each other, but I would bet that a solution would not involve trowing any code away on the digiKam side and re-implementing stuff in Baloo. More like digiKam offering Baloo access to its database so other applications can use Baloo's API to find stuff in it.

See http://community.kde.org/Baloo/Architecture

So Nepomuk was the reason why opening something what was searched first, was slow or impossible because it first needed to create a new copy and then if data was saved, it was saved to new copy instead to original one? And with Baloo we got around that thing?

DigiKam got the Nepomuk integration, but main developers didn't like the Nepomuk in the first place AFAIR from the reason that Nepomuk duplicated features and limited the possibilities. But it is the topic what needs to go to digiKam devel mailing list.

Fri13 wrote:

markg85 wrote:And not just behind it, the search bar needs to be able get closed with same way as it was opened. If you press Ctrl+F second time then it gets closed.

I don't expect that closing any dialog, let's say the save dialog via ctrl+S, works in the same way it has been opened. You may argue that this function works in an extra, modal dialog and all other are 'features panels' that are rather shown or not. So which one works as you say?
I'd rather expect that Escape does it's job. And for the filter panel we do not want to close it at all (if filtering is one of the high priority features).

Fri13 wrote:So Nepomuk was the reason why opening something what was searched first, was slow or impossible because it first needed to create a new copy and then if data was saved, it was saved to new copy instead to original one? And with Baloo we got around that thing?

Sounds about right, yes. Baloo doesn't use one big database - any app can decide what database to use and how. Baloo offers some convenient options (SQLlite, Xapian) but you can use whatever.

DigiKam got the Nepomuk integration, but main developers didn't like the Nepomuk in the first place AFAIR from the reason that Nepomuk duplicated features and limited the possibilities. But it is the topic what needs to go to digiKam devel mailing list.

Yeah, it is - as your icon suggests you care about digiKam it is perhaps a good idea to bring it up with a link to the Baloo documentation

Of course, it'll be a subject at Akademy, too.

Thanks everyone for the useful input, and sorry for the late reply.

Heiko Tietze wrote:

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.

I've created a new topic about the filter bar placement issue because this discussion is mostly about the search dialog now, and I think that discussions are easier to follow if they are about one issue only: viewtopic.php?f=285&t=121393

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.

I'm not sure if this is a valid use case, but it's definitely possible now, and I prefer to be careful when removing any features because a storm of protest is sometimes the result. In any case, the additional flexibility that a separate dialog offers is probably worth more than this "feature".

What I also like about the separate dialog is that it might give us a possibility to provide feedback to the user if the current location is not indexed by Baloo (such that only limited search options are available), and maybe even offer to open the Indexer configuration, such that the location can be added.

Right now, the user just notices that most options are not available if the location is not indexed, but does not know why. And the current search widget, which looks a bit crowded already, is probably not the best place to add further information and access to Baloo's configuration.

Fri13 wrote:

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.

Please do not take my comments as the final word. Think of it more like a brain dump, which can be changed. Also, while I am technically the "maintainer" of Baloo, I would prefer decisions to be taken by everyone. I'm not too keen on having the final say.

There are 2 parts to Baloo - The Query Interface, and File Handling. File Handling takes care of all the indexing and provides a search plugin for the query interface. This "File Handling" currently only handles text based stuff. It does not handle any kind of geographical data. It does not handle any of the fancy digikam features that were described. From my point of view, I'm not even sure it should. Those are very specialized use cases, and Digikam is better at that stuff. Baloo has to handle all kind of files.

If someone wants to combine Baloo and Digikam, then I suppose they would need to expose all these Digikam features via a search plugin for Baloo. Is that a good idea? I cannot say. It depends on how that would be useful. If one wants to be able to do all these fancy searches through images, perhaps an API provided by Digikam would be better instead of generic search interface provided by Baloo. It is at the end of the day, just about the API.

Thank you for your input, Vishesh!

What we care most about: Would it be possible to use steckdenis' query parser to create queries for, e.g., DigiKam? If so, it doesn't matter all that much whether it uses Baloo underneath or their own search implementation. If that's not possible, we cannot make query parser + Amarok-like dialog the default search mechanism via the HIG.

Should search and filter (basically a simple search on file name) be separate or should filter be considered the default with an advanced button brings up the full search dialog? Obviously the current implementations are different as search doesn't dynamically reset the results as you change the query and filter (to me) is much faster

google01103 wrote:Should search and filter (basically a simple search on file name) be separate or should filter be considered the default with an advanced button brings up the full search dialog? Obviously the current implementations are different as search doesn't dynamically reset the results as you change the query and filter (to me) is much faster

My idea was to merge the two: Just filter on the current view if simply a filter string is entered. Start the full search dialog with a button or enter a full search query manually to start the full search. This is just one idea out of several, however.

colomar wrote:

google01103 wrote:Should search and filter (basically a simple search on file name) be separate or should filter be considered the default with an advanced button brings up the full search dialog? Obviously the current implementations are different as search doesn't dynamically reset the results as you change the query and filter (to me) is much faster

My idea was to merge the two: Just filter on the current view if simply a filter string is entered. Start the full search dialog with a button or enter a full search query manually to start the full search. This is just one idea out of several, however.

Apologies for not fully reading your post (or the thread, jumped into it a bit haphazardly), obviously I agree this would be a good way to go

google01103 wrote:Should search and filter (basically a simple search on file name) be separate or should filter be considered the default with an advanced button brings up the full search dialog? Obviously the current implementations are different as search doesn't dynamically reset the results as you change the query and filter (to me) is much faster

This isn't the only difference - note that the filter bar only filters the files that are currently shown in the view, whereas the search also finds files in subdirectories (and provides many more options).

Therefore, I don't think that one can consider the search feature an advanced version of the filter. Both features do fundamentally different things. I see that this is not obvious to many users though, so one could even ask the question whether a default file manager should have these competing features which obviously bear a lot of potential for confusion. I was not involved with the development of these features, but I know from user feedback at bugs.kde.org that both features are used a lot (for completely different things), and any attempt to merge them will most likely make a large group of users unhappy . Moreover, one could argue that the "Filter" feature does at least not cause any trouble for users who do not know about it (only if they try all options in the menu or hit the shortcut accidentally).

Nevertheless, I greatly appreciate all contributions to this discussion, and I hope that we can improve the features in future Dolphin releases. Moving the search widget to a separate dialog could be a good starting point.

Heiko Tietze wrote:<skip>
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.

Big fan of Kfind for searching as it has pretty much all the control you'd want and the initial tab is not overwhelming with options.

As I read now several times the proposal to merge search and filter in dolphin I want to utter my thoughts on this.

I filter search results quite often. For example I search for file content and filter on the file name. That might be because the current interface allows to select either content or name, but I also like the way it works. For me search is a rather mysterious thing as it looks into stuff I currently don't see and the results can be surprising sometimes – you may know the experience when you search for something and stumble over stuff you completely forgot. Filtering on the other hand reduces the list of stuff I see and has instant feedback. True, baloo search is super quick (at least for me), so the last point might be not so important anymore.

What I want to say is, if filter and search is accessed via the same interface, please keep combinations like the above in mind. Searching can be an iterative process in which the possibility to quickly (shortcuts) and easily (no complex search queries, no endless checkboxes) reduce the list of results can be really helpful.

HmpfCBR wrote:What I want to say is, if filter and search is accessed via the same interface, please keep combinations like the above in mind. Searching can be an iterative process in which the possibility to quickly (shortcuts) and easily (no complex search queries, no endless checkboxes) reduce the list of results can be really helpful.

You are right, an iterative/faceted search approach has to be possible.