On Wed, Sep 12, 2012 at 9:50 AM, Andrej N. Gritsenko <[email protected]> wrote: > 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.
What things should a scheme handler provide? 1. dir listing 2. query info of a specific file (optional) 3. monitoring 4. and?? A fm_scheme_handler_register(const char* scheme, FmSchemeHandler* handler) may be added. >>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. This sounds good, but makes things more complicated than it should be, and introduces performance hit. GFileMonitor works based on file paths and does not provide info of the files to its users. You get notifications for file addition, but you don't have the info of the newly added files. You have to query the info of them yourself. Another interesting fact is, the GFile you get in "change" callback of GFileMonitor only contains "search://xxxxx", and you need to find a way to map that to a physical file path, and schedule yet another thread to query the info of that physical file. About the performance hit, we already query the file info during the file searching process (stat, mime-type sniffing, ...etc.). It's a waste to query for the file info again in the file monitor callback. Returning from DirListJob immediately is a bad idea and can confuse the users of the API if cancellation of the job does not stop the searching. A much cleaner and simpler way IMO is fm_dir_list_job_set_notify_for_every_file(job, TRUE); If the flag is true, it emit "file-found" signal for every found file. Otherwise, it only fires "finished" signal as usual after all files are loaded. FmFolder handles the "file-found" signal when the fm_dir_list_job_get_notify_for_every_file() returns TRUE, and only handles "finished" signal if the flag is FALSE. A monitor for a search URI is a dummy one and does nothing. In this way, we keep the API as clean as the original ones, and only query info of all files once in one single thread (the dir list job thread). There is no need to map search:// URI to physical file paths since the physical paths are in path fields of FmFileInfo objects. For users of FmFolder, there is nothing different as the interface remains the same. The only thing changed is the FmDirListJob and the change is very subtle and backward compatible. This solves the problems immediately and introduce no additional performance penalty, inconsistency, or backward incompatibility. Only minimal documentation needs to be added too. I agree with your idea about not doing all things in a fake FmFolder object. Regarding to the implementation details, I really hope that you can accept the proposal in this mail. I'll do it in an experimental branch first. This is the best one I can come up with and I'm a little bit reluctant to make things more complicated than this. Libfm should be an easy to use thin layer on top of glib/gio only and we're not going to do a vfs. (Well, if gvfs did a good enough job, we don't need to worry about so many things, but unfortunately it didn't) :-( Thanks >>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 ------------------------------------------------------------------------------ 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
