Hello!
I have written on Tuesday, 11 September, at 18:43:
> 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.
After some thinking I see it perfectly clean: it is a class FmFile
(implemented in a file src/base/fm-file.c) which mimics GFile somehow and
libfm uses FmFile instead of GFile so nothing is changed beside that API
migration and even further - no parts in libfm will never be concerned of
applications://, or search://, or trash:// anymore, everything go simple
and reliable, and only module which represents applications:// will have
dependency on menu-cache for example.
I still hate very much the idea to involve everything not only in the
search but in trash and application handling (and in the future it will
be more of that I'm afraid so libfm code will be complete hell to use and
support). It's already involved in many places so I want all those parts
to disappear and be concentrated in one place. You know, glib came to
that long time ago, why we should repeat their wrong steps again instead
of use thier good steps?
What do you think?
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
