searchbar (Re: KTextSelectionExtension::findText...)

[David Faure]

On Saturday 09 October 2010, Dawit A wrote:
> How does typing parts of a URL or a page title work ? By looking
> through the existing cached page or scaning bookmarked urls ?

Not the cache, but the history, and the bookmarks, yes.

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

Well, if we keep the two lineedits separated, then IMHO this is a job for the 
search bar, not for the main location bar.

I see the main location bar as a way to type *URLs* (with as much as needed, 
like completion from history and bookmarks, as well as shorturi filters etc.)
and the search bar as a way to type *Search strings*.

Internet keywords or whatever they're called nowadays (gg:foo) are a shorthand 
for a long url, technically they are not bare search terms, so they're ok in 
the location bar.

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

Yes, but in the search bar ;)

It would change the workflow there from "open combo, select engine, type" 
(which probably only few people take the time to do), to "type, choose best 
offered search engine in popup that opens all by itself", that would be nice 
indeed.

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

I think you're confusing kdelibs and kdebase. I'm not talking about libraries 
here.

Say that in kdebase-4.5.1 we add a new signal or event to konqueror, and in 
kdeplugins-4.5.1 we change the searchbar-plugin code, to use that signal or 
event instead of whatever it was using before.
If you use kdebase-4.5.0 with kdeplugins-4.5.1, the plugin won't work anymore, 
since it's listening to something that isn't emitted.

If the plugin is in kdebase, such problems cannot happen. OK, except on 
distros which split up even kdebase-apps into smaller bits ;)

But I'm OK with that, we'll just preserve runtime behavior for all 4.5.x 
releases, and then allow ourselves to break it with 4.6.0, and not support 
people using kdeplugins-4.5.4 with kdebase-4.6.0, or vice-versa.

This is already much better than the current situation where even new kdelibs 
methods are a problem, for lack of proper branching.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).