Review Request: Make KUriFilter viable for apps that only want to do search filtering...

[Dawit Alemayehu]

> On 2010-05-18 21:29:36, Aaron Seigo wrote:
> > the API additions look good. and am i right to understand that to get the list of available syntaxes, the krunner webshortcuts plugin might do something like:
> > 
> > KUriFilterData data("<q>");
> > if (KUriFilter::self()->filterSearch(data)) {
> >      foreach (const QString &providerName, data.preferredSearchProviders()) {
> >          const QString exampleQuery = queryForPreferredSearchProvider(providerName);
> >          Plasma::RunnerSyntax s(exampleQuery, i18n("Searches %1 for <q>", providerName));
> >      }
> > }
> > 
> > ?

Exactly except "filterSearch" should be "filterSearchUri". :) Just do not forget to hold a pointer to "KUriFilter::self()" in your class to avoid the problems with Singletons and multi-threading. We do not lock that function when creating an instance...


- Dawit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4040/#review5727
-----------------------------------------------------------


On 2010-05-18 19:49:08, Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4040/
> -----------------------------------------------------------
> 
> (Updated 2010-05-18 19:49:08)
> 
> 
> Review request for kdelibs and Aaron Seigo.
> 
> 
> Summary
> -------
> 
> The attached patch adds functionality to KUriFilter and its helper classes to make it possible to use it for only search related filtering. The intent of this patch is to correctly address the issue that caused applications/plugins to write their own implementation of web shortcut filters because of missing functionality in this class. This has led to behavioral differences between implementations, e.g. Konqueror's location bar vs KRunner. 
> 
> For further discussion of the issues, please refer to the following thread:
> 
> http://lists.kde.org/?t=127370544600008&r=1&w=2
> 
> 
> With this enhacement, KRunner can now obtain information it needs to show the user feedback such as "Search <provider-name> for <search-term>" where both <provider-name> and <search-term> are now made available by KUriFilterData. The enhancement also allows khtml and kwebkitpart to query for all the necessary information they need to display content menu "search" options on selected text instead of relying on the configuration information of a completely unrelated application (read: plugin) which can definitely be changed without notice!
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kuriikwsfilter.cpp 1128173 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kuriikwsfiltereng.h 1128173 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kuriikwsfiltereng.cpp 1128173 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kurisearchfilter.h 1128173 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kurisearchfilter.cpp 1128173 
>   /trunk/KDE/kdelibs/kio/kio/kurifilter.h 1128173 
>   /trunk/KDE/kdelibs/kio/kio/kurifilter.cpp 1128173 
> 
> Diff: http://reviewboard.kde.org/r/4040/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit
> 
>