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?
>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.
>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
