About the KRunner webshortcut plugin...

Aaron J. Seigo aseigo at kde.org
Tue May 18 00:47:21 BST 2010

On May 15, 2010, Dawit A wrote:
> 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...

ok; we can work around the non-thread-safe self() easily by just calling that 
in the ctor of the KRunner plugin. and if this is true:

> > 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

that would be perfect ... 

> > * 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.

great; when that's done then it looks like the krunner plugin can move over to 
it. since you're already doing this part of the work, if you'd like, i can do 
the krunner plugin porting (not that i have much excess time, but figure it's 
a nice quid-pro-quo, esp as you probably have other areas of the code t fix in 
similar ways as shown in this thread.) let me know ... (and yes, i'd still be 
happy for someone else to do it ;P )

> 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...

that'd be nice :)

Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100517/c99f18a3/attachment.sig>

More information about the kde-core-devel mailing list