On Tue, Sep 18, 2012 at 8:19 AM, Andrej N. Gritsenko <[email protected]> wrote: > Hello! > > Have a look into 'search-vfs' branch, please. I've made a VFS draft > out of FmSearchJob class which will be eliminated now together with all > extra functions in FmDirListJob that you've added to support it. All the > work will be done by unmodified(!) FmDirListJob. And other search support > in FmFolder and FmPath should be reverted back as well, of course. It's a > draft still since I just rearranged it but never tried yet to compile. > But please, don't merge all those branches together yet as it will be > complete mess. I'll do that in designated order carefully after 1.0.1 is > released. Thank you! > > I hope you'll like it. :) > > Cheers! > Andriy.
Generally it looks OK but it's slightly more complicated than the original design. Another problem is, attributes passed by the caller of g_file_enumerate_children may not contain file attributes required by the search and could break it. I still have some work in progress on my branch now and will commit them later. Another issue is, I haven't optimize FmSearchJob now. The best way to do the file enumeration is to do it without "standard::content-type" attribute. When the parameters received by FmSearchJob only does file matching by names, there is no need to do mime-type recognition. Mime type recognition is only needed when a file matching our rules is found. Eliminating unneeded mime-type recognition should greatly speed up the search. This optimization, however, is not possible with your new API. The newly added APIs to FmDirListJob should NOT be removed. It's also used by FmDirList itself and does much work to optimize signal emission internally. If you emit the signals too frequently, the UI will flicker and become slow. That's why I group the newly added files and emit the signals periodically. Please also check "search" branch of pcmanfm as well, it uses some new APIs in libfm search branch already. I understand your desire to unify programming interfaces as I want to do that, too. However, some hard-coded things are needed for making the UI better. For example, the UI should be consistent among most operations, but should have some differences for different operations, too. For applications:// folders, it's reasonable to add a "uninstall" option to the popup menu. For search:// folders, it's reasonable to add a column showing location of the files. Though a generic UI works well with a unified API, some special UIs are needed for different cases to make the program more user-friendly. So there must still be some hard-coded things to check types of folders and provide best GUIs for each of them. Thanks for the hard work, but I think before widely adopting your new design, some discussions are still needed. See the "attributes" problems and the lack of optimization I mentioned previously. Do you have a better idea for it? Thanks! ------------------------------------------------------------------------------ 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
