Re: muCommander search

[Maxence Bernard]

Hi Andrey,

I have finally taken the time to play with the search prototype you sent and to formulate my feedback. First of all, thank you for your contribution and the work you put into it, it looks and feels very good. A search functionality has oft been requested in the forums and I too believe it would be a very nice addition to muCommander.

Over time, I have been toying with the idea of implementing a search functionality. Even though I never quite started working on it, I have come up with an idea for it that I think would fit well into the current design and would be quite powerful. So I'd like to take a moment to share this idea with you and ask what you think about it.

Simply put, the search would be backed by a 'search://' filesystem where all the search parameters would be expressed in the URI. For example :

search://localhost/file/home/andrey?filename=^moon&content=safari

would search Andrey's home folder (/home/andrey) for files whose filename start with 'moon' and content contain 'safari'.

A search dialog like yours would help create the search query graphically, adding search criteria and combining them with AND / OR boolean operators.

When done, the user would press 'Search' which would send the corresponding search URI to the active folder panel where the results would be displayed.

Comparison

To try and compare both approaches, I have made a list of pros and cons, feel free to add to it :

Approach #1 : Integrated search dialog, query form and search results in the same dialog

Pros:

+ Potentially easier to use, at least initially

+ Easier to modify the search query and re-run it

Cons:

- Less powerful / versatile

- More search-specific code

Approach #2 : Search dialog to help create the search URI, results displayed in the main folder panel

Pros:

+ Search queries can be saved (bookmarked) and replayed later

+ Search results can be navigated, copied, packed, ... just as regular directories

+ Search results can be sorted by date, size, ...

+ Search results can easily be sent to another window ... just as regular directories

Cons:

- Potentially harder to get used to, at least initially

- Would require a bit of work (but not too much) to properly display search results and their parent folders in the main folder panel.

- No incremental results: search results would only be displayed when the whole folder has been searched (actually, we could easily have incremental search results)

Note that once the search filesystem and the query construction dialog have been implemented, the extra effort to display the results directly in the search dialog (like in your prototype) would be minimal. The search dialog could allow results to be sent either to the search dialog or to the folder panel.

What do you think about the search filesystem approach, do you also think it would make sense ?

If you do, we could easily split the work (if you want to), as there is a clear separation between the UI and filesystem.

Please let me know your thoughts!

Cheers,

Maxence

On  Jun5 ,2008, at 11:43 PM, Andrey Opletin wrote:

Hi guys,

I have wrote add-on for muCommander. This is search task.
Solution based on SearchForm class. See attachment.
I didn't make control on muCommander GUI for search action and remained for your decision.
I hope that add-on you will accept and next build muCommander will include it :)

Source code and flash demo is in attachment.
<muSearch.swf><SearchForm.java>

If you have any wishes and ideas - you are welcome :)

Thanks  

[Maxence Bernard]

Hi Andrey,
Thanks for the quick reply!

> 1. I think about URI is unusable feature. I think what search can get
> advanced features, AND/OR, search in pics, search in docs, search in
> arch, search by size... and URI will be very hard.

I really think we can make it work. After all, Google does represent
search queries as URIs, and it can handle pretty complex search
queries (http://www.google.com/advanced_search). If Google does it,
I'm sure we can do it :)
If you're still not convinced, I'm willing to draft a tentative URI
format as a proof of concept.

> 2. Now search run in some thread and user can stop it, suspend it, go
> to file i.e. User can view search result in runtime now. If we can use
> file panel for search we lost it feature.

Granted, we'll have less control over the search execution in the file
panel. But we can however display results in pseudo 'real time' (i.e.
as they are being found) in the file panel -- what I called
'incremental search results' in my previous email. For this, we would
use the existing folder auto-refresh feature, which automatically
refreshes the current folder when changes have been detected (that is
when the last modified date of the folder has changed).
SearchFile#ls() (SearchFile being an AbstractFile implementation)
would return at most after a certain amount of time (that can be
controlled as a property), for example 2 seconds. That means the first
results would be displayed in the file panel after 2 seconds, then the
panel would be refreshed every 2 seconds as new results are found ...
This wouldn't be as 'real time' as real time can be, but close enough
I believe.

> 3. I undestand your idea and I can propose solution. I can add buttons
> for move search results on file panel from search dialog.
>
> What you think?

I was thinking along these lines too, we can offer the best of both
worlds with the following :

1) the search engine is provided by the search filesystem (search://)
2) results are by default displayed directly in the search dialog
(just like your prototype)
3) by the press of a button, the user can send results to the current
folder ; the implementation of this being just a matter of changing
the current folder to the search:// query

This would offer an uncompromised solution from a user's perspective,
simple yet powerful.

Can we agree on this? I can draft a search URI format and, if you
want, take care of 1) (search filesystem implementation) or at least
provide guidance.

Cheers,
Maxence

[Maxence Bernard]

Hi Andrey,
Great to hear, please let me know if I can be of any help.
Implementing a filesystem can sometimes be tricky so feel free to let
me know if you're bumping into an issue and I'll be glad to assist you.

Also, if you feel like drafting the URI format and sending it to this
list, this would help spot issues before starting the implementation
and may save some time down the road.

Cheers,
Maxence

On Jul2 ,2008, at 9:46 AM, Andrey Opletin opletin wrote:

> Hi,
>
> I will do it.
>
> Tnx

[falstie]

Hi Maxence and Andrey,

Very cool, that you are implementing search functionality.

I think your ideas sounds good. It could be worth considering not
making the search window a modal window (as in Altap Salamander). In
that way the user can go back to the search result and choose another
file or directory to be shown in the table. Another way to achieve the
same, would be to save the last search result and display this when
the user opens the search dialog.

Kind regards,
Nikolaj