[rekonq] Urlbar improvements

[andrea diamantini]

2010/4/13 Lionel Chauvin <megabigbug at yahoo.fr>

> > The "problem" is that I had to change some behavior, in example the first
> > item selection on popup. This to let rekonq use KUriFilter to resolve a
> > typed url WITHOUT suggestions. That is the problem here.
>
> I am not sure I understand what you want to do.
>
> If the first item is not selected, rekonq can't explain to the user what is
> done when he press enter.

For instance, he can't understand why "http://www.kde-apps.org"  is launched
> when he types "kde-apps" and why it processes a google search if he types
> "kde".
>

That's the way firefox works, for instance. I don't say this is the best way
to do. Indeed I said the opposite.
I'm saying that this is the way things work well. And to reenable the other
way, we need to no more fail
on UTF-8 resolutions.


> It should always propose at least one suggestion. KUriFilter can help to
> build
> this suggestion or perhaps not, I didn't study this point. If it is too
> slow
> for process that, why we should keep it ?
>

We have to keep KUriFilter, otherwise we cannot ensure things will work.
In a Qt-only environment you do something like:

QString (typed by user) --> GuessUrlFromUserInput --> QUrl --> load

This chain works with real urls because GuessUrlFromUserInput is good and
fast to "guess" QUrls, but it will fail on "puzzle urls"
eg: "google.com/search?q=" + something user typed, because of the encodings
after the resolution.

In a KDE environment you need something like:

QString (typed by user) --> KUriFIlter --> KUrl --> load

This will work in the same way than the Qt chain and better, because:
- it supports kde web shortcuts (eg: "gg:string" urls)
- it really resolv and/or ping urls instead of "trying to guess" them.

so, typing "ciao", GuessUrlFromString loads non extant "http://ciao", while
KUriFilter try to understand if the host "ciao" exists. If it exists it
loads "http://ciao", otherwise it searches the default search engine for it.
Anyway this costs time, that is hardcoded exactly to 5 seconds waiting for
DNS and/or ping response.


All this to explain why KUriFilter is a must for every KDE network
application. Hope this helps.

Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20100413/e4eecd56/attachment.htm