[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: About the KRunner webshortcut plugin...
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2010-05-17 23:47:21
Message-ID: 201005171647.43406.aseigo () kde ! org
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]