Hello!
PCMan has written on Wednesday, 12 September, at 10:51:
>> 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??
See GFileIface in <gio/gfile.h> for full details. I know it's a lot
but most of things may be not implemented for some scheme. :)
>A fm_scheme_handler_register(const char* scheme, FmSchemeHandler*
>handler) may be added.
That is implementation details and I thought about some fm-modules.c
which gives interface not only for that but for future expansions too.
What I've written was a concept, not details. Anyway implementation of
that should come into 1.1 and we have only 1.0.1 about to be released and
still 1.0.2 is scheduled and I'm not sure if 1.0.3 wouldn't come out if
some bugs were found while 1.1 will be in progress. So we have plenty of
time to find the best solution on details.
>>>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.
Since handler of search://xxxxx lies in exactly one module it can in
fact query that info in running search process. That is again just some
implementation details and we don't have to implement that using GLib's
heavy mainloop but using direct thread access instead which I'm familiar
with you know. And as much as we use the GFile interface for everything
but g_file_new_for_* we have no performance impact - fm_file_new_for_*
for "directory" (which is search pattern) creates search process and
fm_file_new_for_* for "file" will return "symlink" GFile which target is
a physical file. If you want implementation details then example:
GFile * fm_file_new_for_uri (const char *uri);
will check if uri is a schema registered internally and if yes then ask
the apropriate handler, otherwise return g_file_new_for_uri(uri). Simple
as that.
>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.
Good idea. Need a bit of implementation in places which use the
FmDirListJob APIs though.
>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.
Let's do it after 1.0.2 comes out. And in 1.0.2 we have to clean up
the FmSearch and FmJobSearch which we got. Let me know when you finish
your clean up, please, so I can start mine.
>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) :-(
Any GFile scheme implementation is a VFS in terms of GLib you know.
As soon libfm already have implementation for menu:// it already has some
fake VFS. All I've proposed is to make it less fake but more clean and
expandable (so we can add search:// right away) for libfm internal usage
and probably even modularized to allow third party modules.
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
