On Tue, Sep 11, 2012 at 11:43 PM, Andrej N. Gritsenko <[email protected]> wrote: > Hello! > > PCMan have written on Tuesday, 11 September, at 13:54: >>I'm ok with glib 2.22. I want to deprecate that module because it's >>not maintained and is less tested. Every machine I have got newer glib >>versions so I'm not able to test that module. It seems to work as >>expected since there're no related bug reports. >>But since that gio extension point no longer exists in glib 2.27, it's >>reasonable to mark the module as deprecated with compiler flags. > > AFAIK it works as deprecated already since it's disabled in Makefile > if glib is 2.27 or above, isn't it? And its header also never installed > nor documented so in fact it as good as nonexistant. > Correct me if I'm wrong, please - does that module just add mime-type > x-scheme-handler/* to gio? So what may be wrong in providing such simple > module still for a bit older systems?
It clashes with the module comes with gvfs. The gvfs one reads the settings from gconf and that's why we have our own module. Mine writes the settings to x-scheme-handler/* instead, just like newer glib/gio did. Anyway, it looks simple enough and could not be too buggy. However, we don't support protocol schemes other than http and mailto while gnome supports more. Other programs which try to write protocol handler config to gconf does not work since we don't load gconf. Well, it's not our bugs, though. So there is no need to fix it. >>Libfm only provides file searching mechanisms. >>The UI to present search result should be in pcmanfm. >>The work done during GSoC 2010 is of poor quality. >>Its API is very complicated and the implementation is buggy. >>There were some memory leaks, too. >>Some API cleanup and redesign are needed and I'm doing it now. > >>The main idea is to present the search result in a FmFolder object. >>So FmFolderModel/FmStandardView can be used to show the result, a >>simple and quick hack to get things done. >>However, this special FmFolder has no associated FmPath or FmFileInfo >>for the folder. >>Hence if we add the fake FmFolder object to a tab of FmMainWindow, it >>will crash because it's not a complete FmFolder object and it has no >>associated path. >>That's why the search result was shown in another window rather than >>as a tab of FmMainWindow in 2010. >>Now I got a new idea. We can generate fake FmPath and FmFileInfo >>objects for the search result. >>The path looks like this: search://<md5 checksum generated from search >>criteria>/. >>Besides, we fill in most fields of FmFileInfo with empty value for the >>virtual folder. > > I still got no time to inspect the code for vulnerabilities. But what > I can tell you - I don't like the idea to use invalid FmFolder object for > the result. I think the correct way is to make valid FmFolder with valid > FmPath where path should be some virtual URI 'search://.....' and with > other valid info too. Not sure about md5 checksum though. The better way > would be some pattern. And then we should make search URI scheme handler > and not try gvfs handlers. Probably make that place modular with fallback > to gvfs may be a good approach (so it's about your idea to replace trash > handler by own one too, and also to handle applications scheme instead of > hardcoding it). This way we'll never have to call search API directly > from widgets because everything will be done by FmApth and FmFileInfo. > BTW, that way we can request pcmanfm to open a window with search result > from commandline too - I believe it's too complicated and unreliable to > do that any other way. > In short - I would like to exclude fake FmFolder object from the new > search engine at first step, then make handling schemas modular (second > step), then make a handler for search:// schema at third step (so libfm > will start to support search immediately after that), then make a little > dialog to make search URI by a convenient way from GUI. Only last one is > Gtk+ or whatever of course. That's my original idea. Providing APIs to registering different handlers for uri schemes. Then, launch the search with a beautiful URI like this. 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. Besides, in this way we need to collect the required parameters in the search dialog. 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. 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. 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. 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. 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. Having a customized FmFolder object for the search result as a virtual folder is much easier. 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. 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. 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. Cheers! >>Then, we can put the search result FmFolder in a model, a view, and >>then in a tab of FmMainWindow, just like other physical folders. >>The md5 checksum is not only used for generating a fake path. >>It can be used as a key to cache the search result and can be used as >>the name of the cached file. >>We can save the search result in ~/.cache/libfm/search/<md5 checksum> files. >>So it's possible to load the cached result later in the UI. >>The only problem with this approach is, when should we delete the >>cached search result? >>Before termination of the program in fm_finalize()? But if pcmanfm is >>killed with SIGKILL, then there is no way to clean the cache. > >>Any suggestions? > > I don't think we should use caches for search since it will be rarely > used by most of users but we get those described problems instead. So it > is a big headache which we should avoid as much as possible. At the most > we can use some kind of stack of limited size (10 items for example) for > last used searches for which it's better to reside in memory. > > With best wishes. > 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
