On Saturday, May 15, 2010 11:37:28 Aaron J. Seigo wrote: > On May 14, 2010, Dawit A wrote: > > If this was done because there is some feature or functionality missing > > from the KURIFilter class, then the missing functionality needs to be > > added there. This blatant misuse of the configuration files need to stop. > > i think the problem is that KURIFilter is not well known :) Well in some cases perhaps, but for example khtml_ext.cpp and even the copied code in kwebkitpart_ext.cpp use this class but still end up reading the configuration file because of functionality not available in this class. > i took a look yesterday at using KURIFilter in the krunner plugin and the > questions i eneded up with were: > > * threading: is it safe to run KURIFilter outside the GUI thread? Yes... > is it safe to have two KURIFilter classes in different threads making the > same calls? Partially because KURIFilter uses the Singleton pattern, but does not serialize (use mutex lock) its creation when KURIFilter::self() is invoked. Obviously, this is something that can easily be remedied by using a mutex locked in self(). :) Additionally, the plugins themselves have some member variables that they reload by listening for configuration changes through dbus. Not entirely sure whether or not this would impact re-entrancy or thread safety, but I am inclined not to think so based on what I looked at... > even better, is it safe to use one KURIFilter class in multiple > threads? (the latter isn't a requirement; the first two are) As far as I can tell the answer to this question is also yes, provided the above issue is taken care of. I do not know if I intended it to be thread safe when I wrote the class, but almost all the functions, even in the plugin implementations, are thread safe and re-entrant. The exception being what I mentioned above... > * information for the user: the runner plugin advertises what it is capable > of, e.g. "gg: => Search on google for ". KURIFilter gives a > list of plugins with QStringList pluginNames() const, but how do we go > from that to a rich set of information (KPluginInfo or KService objects > would be perfect) Yes, after looking at the KRunner webshortcut plugin, I was working on a patch to remedy that... It is just a matter of adding a way to set and get information about the search term and the search engine in the KURIFilterData class. > * documentation: the filter types are strings; two are documented in the > apidox and one has to know frm the name of them what they do > (kshorturifilter and localdomainfilter). is there documentation on what > kind of filters exist and what they do? Well that is a little more difficult because KURIFilter was designed to be extended through plugins in the future without the need to add stuff directly to the code in kdelibs/kio/kio. Anyone can design their own user input filtering plugin much like KRunner's plugins. Anyhow, I am only aware of the uri filter plugins provided by default in kdebase/runtime/kurifilter-plugins. Perhaps some sort of documentation should be included in the documentation of the KURIFilterPlugin class as to what each of those do... Regards, Dawit A.