Hello!
PCMan has written on Wednesday, 12 September, at 9:09:
>search://home/pcman/my_folder1;/home/pcman/my_folder2?pattern=*.txt®exp=1&mime-types=text/*/
>This, however, should be done in the level of FmDirListJob,
>FmFileInfoJob, and GFileMonitor, not FmFolder, which is quite a lot of
>work.
I've written a letter about that few moment ago. That should not be
done in the mentioned places.
>Besides, in this way we need to collect the required parameters in the
>search dialog.
Yes, that should be done.
>Then, convert them to key/value pair strings and appand them to the search URI.
>Next, parse the generated URI, and convert them back to values in
>FmDirListJob, FmFileInfoJob, and file monitoring code, which is a
>little bit stupid.
Nope. Never do anything in any of those places. Only search:// scheme
handler should know about that - it should get a directory name as the
search criteria and return results as files for that virtual directory.
>Loading the search result is also different from loading a general folder.
>The files should be shown to the users immediately when then are found.
>FmDirListJob by default notifies the callers once only when all files
>in the folder are loaded.
>We cannot show all of the found files at once after the whole job is finished.
>We need to show every file found when the job is still running.
Simple as bread - return from FmDirListJob immediately after first
file is found but search thread continues to work and informs about each
result via GFileMonitor. Nothing to change anywhere.
>In addition, a search job can be cancelled by the user while it's still
>running.
>With a oridinary FmFolder, there is no need to do this.
>Just close the tab or hit "back" button in the toolbar, and the
>loading should be cancelled.
>Having a "stop" button for loading ordinary folder is really ugly IMO.
The same here: special GFileMonitor is destroyed -> search cancelled.
No problem, simple again.
>Cancelling a running search cannot be done by closing the search tab.
>The user may want to stop the search but keeps the currently found
>files in the UI.
>So there needs to be an API for cancellation.
As I said - cancelling FmDirListJob or GFileMonitor is enough. I can
implement that and I see how to implement that in my head already.
>Another drawback for the search URI idea is, all search settings
>should be encoded and contained in the URI. If there are several
>target folders, the URI can become very long by joining several folder
>paths. This can easily exceed MAX_PATH.
>We don't use the hard-coded limit MAX_PATH in libfm, though.
>Libfm should be able to handle paths longer than that, but it still
>make me uncomfortable to have such a very long URI.
Haven't you seen long search patterns in Firefox? What is so much
uncomfortable in that? User anyway hardly will manually edit the pattern
if there is a convenient dialog.
>Having a customized FmFolder object for the search result as a virtual
>folder is much easier.
That is very dirty hack, very dangerous and vulnerable, which will
require special support in very many places. And you know that yourself.
I hate that idea very much and probably even leave the project if you
insist on that dirty idea. I'm sorry, my friend.
>By building the URI with md5 checksum, its length becomes 32 and
>searches with different settings are guaranteed to have different
>URIs. This provides a good key for hash table lookup, but if we don't
>write the cache to disk, it's less useful.
It's at least unreadable and cannot be used as a commandline argument
you know.
>Moreover, if we don't write the search result to disk as cache, how to
>handle "back" and "forward"?
>When the current tab is showing the search result, the user can chdir
>to another folder. Then the search result is cleared and the other
>folder is loaded.
>What if the user hit "back" button to go to the search result again?
>It can be annoying if we run the search again or just show an empty folder.
>Caching the search result in the memory is possible.
>As the search result is rarely needed and is only useful for
>navigation history, it's a waste of memory. That's why I want to store
>the cache on disk instead.
Good point. The we should use some cache history and remove expired
results from cache. Firefox doing something like that.
>The idea looks simple, but the implementation details actually involve
>many issues.
>A separate search tool not integrated to the file manager UI makes
>things simpler and that's what have been done in GSoC 2010.
>But it's still more elegant if we can reuse the file manager tabs to
>show the search results.
I'm positive on that. And everything that I said above and before is
exactly about the integration. But again, it should not involve hacks on
FmFolder. Keep it simple! :)
Cheers!
Andriy.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Pcmanfm-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
