About the KRunner webshortcut plugin...

[Dawit A]

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:<query> => Search on google for <query>". 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.