Review Request: Modify the KUrilFilter API once more to accomodate unforseen use case...

[David Faure]

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


isAlwaysReturnPreferredSearchProvidersOn is quite a mouthful. And yet, I would use "Enabled" instead of "On", to be more Qt-like.

Thinking about all this, there are really two use cases for KUriFilter: "the user's text -might- be a candidate for uri filtering" (e.g. konqueror or krunner), and "the user wants this to be uri-filtered, including web-search fallback" (e.g. konversation's popupmenu; pasting onto khtml; any use case not based on a location bar, really, where typos can't happen (*)).

Your setter is really about choosing between these two modes. Maybe it could have a better name, like setForceFiltering()? or more precise: setWebSearchFallbackEnabled()?

(*) iirc one of the reasons why the fallback-to-web-search was disabled in konqueror's location bar is that typing /ect instead of /etc would trigger a google search for /ect, unexpectedly.

Even the need for setWebSearchFallbackEnabled() would have been unexpected to Eike, but well, we have to cover both use cases and the only way to do that is to have a setter; and for compatibility it has to be off by default.

=> Ship It, but with a better method name if possible.

- David


On 2010-08-27 23:09:20, Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5172/
> -----------------------------------------------------------
> 
> (Updated 2010-08-27 23:09:20)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> The attached patch does the following:
> 
> #1. Adds setAlwaysReturnPreferredSearchProvidersOn/isAlwaysReturnPreferredSearchProvidersOn to ensure that the kuriikwsfilter plugin returns the preferred provider search engine list when no default search engine is specified. Currently it fails to do so and that behavior will not change unless you set the flag using the aforementioned function. 
> With this change instead of having to do the following:
> 
> KUriFilterData filterData(foo);
> filterData.setAlternateDefaultSearchProvider("google"); // hmm... would google be there ?
> if (KUriFilter::self()->filterUri(filterData, QStringList() << "kuriikwsfilter")
>   // do something here...
> 
> With
> 
> KUriFilterData filterData(foo);
> filterData.setAlwaysReturnPreferredSearchProvidersOn(true);
> if (KUriFilter::self()->filterUri(filterData, QStringList() << "kuriikwsfilter")
>   // do something here...
> 
> #2. Deprecates the newly added function filterSearchUri(KUriFilterData&) in favor of one that accepts an enum filterSearchUri(KUriFilterData&, SearchFilterTypes types). That way instead of the caller having to know what "kuriikwsfilter' or 'kurisearchfilter' plugins do, they can specify "NormalTextFilter" or "WebShortcutFilter" or an OR combination of both. This change makes it possible to do search filtering without having to worry about which filters to use. For example, the last if statement from the above example would become:
> 
> if (KUriFilter::self()->filterSearchUri(filterData, KUriFilter::NormalTextFilter))
>    // do something here...
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kuriikwsfilter.h 1168549 
>   /trunk/KDE/kdebase/runtime/kurifilter-plugins/ikws/kuriikwsfilter.cpp 1168549 
>   /trunk/KDE/kdelibs/kio/kio/kurifilter.h 1168902 
>   /trunk/KDE/kdelibs/kio/kio/kurifilter.cpp 1168902 
> 
> Diff: http://reviewboard.kde.org/r/5172/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100830/b8895aa9/attachment.htm>