KTextSelectionExtension::findText...

[Dawit A]

On Fri, Oct 8, 2010 at 9:42 PM, David Faure <faure at kde.org> wrote:
> On Saturday 09 October 2010, you wrote:
>> > But that's the point: if one day we remove the plugin, it will be much
>> > simpler if we remove it from kdebase/apps/konqueror exactly when we
>> > merge its functionality into konqueror, than if it's extragear and we
>> > have to deal with "does this version of konqueror need the plugin or
>> > not".
>>
>> Well to be honest in some ways the searchbar plugin is much more
>> convenient because it provides everything you need to do right there.
>> For example, you can easily change the search provider to use or add a
>> new one. More over you do not have to worry about whether or not
>> something you type would be translated into a URL if it happens to
>> contain anything that remotely resembles a URL or local domain name. I
>> doubt one can easily integrate all of that into a location bar proper
>> without making it a little bit convoluted. Anyhow, I think we still
>> need to keep this plugin around even if konqueror's location bar is
>> enhanced...
>
> I agree, actually.
> I was just wondering if it wouldn't be simpler to have it close to konqueror.
>
>
> For the location bar I wish I could type parts of a URL or page title, but
> indeed that's not the same as a search on a search engine.
> Edulix has done some work in that direction, although not easily
> integratable... rekonq too. To be investigated...

How does typing parts of a URL or a page title work ? By looking
through the existing cached page or scaning bookmarked urls ?

Personally one area of improvement I can already see as being easy
enough to implement right away is presenting the user with list of
choices when he/she types a search term into the location bar. For
example, if the user starts typing a search term into Konqueror's
location bar, "KDE SC", a list of possible searches can be provided
based on the webshort settings. By default this would be something
like:

[icon] Search Google for 'KDE SC'...
[icon] Search Yahoo for 'KDE SC'...
[icon] Search YouTube for 'KDE SC'...
[icon] Search Wikipedia for 'KDE SC'...

This visual cue alone should help the user to quickly discern the
typed web shortcut is correct or not. It would also be a good
indication of what action would be taken if the user presses enter.
Little things like that would be helpful I think...

>> > OK, I see your point though, if we go for kdeplugins then we can rely on
>> > it being equal to the kdebase version.... hopefully... not sure that's a
>> > 100% certainty, actually.
>>
>> Hmm... what do you mean by "not sure that's a 100% certainty" ?
>
> Well, technically a user could upgrade kdebase without upgrading kdeplugins,
> or vice versa.
>
> Just like you can already have kdeutils-4.5.1 and kdebase-4.5.2, for instance.
>
> AFAIK the requirements are on kdelibs, i.e. kdeutils-4.5.2 requires
> kdelibs-4.5.2 (there could be new api), but we don't force users to upgrade
> everything at the same time (runtime dependencies...).

Well why would we care if the user upgrades the core
libraries/packages without upgrading the kdeplugins ? That should
continue to work fine, no ? I just do not get why what you described
above would be an issue. The user should be able to use kdeutils-4.5.1
with kdebase-4.5.2, but not the other way around.

> So kdeplugins will make it easier to use new kdelibs api, like kparts
> extensions, but it might still create some "what's the konqueror version"
> trouble. But better than the current situation, for sure.

Just don't see how. Perhaps I am completely misunderstanding your
point here, but the newer libraries cannot remove the older methods or
runtime functionality without causing a BIC ; so how can this become
an issue for kdeplugins ?

Regards,
Dawit A.