-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105984/
-----------------------------------------------------------
(Updated Aug. 20, 2012, 8:02 p.m.)
Review request for KDE Base Apps and David Faure.
Changes
-------
Here is the only other option I personally see to handle all the focus related
bugs. This solution does not use a timer, but has its own minor flaws. Namely
when a new tab is created when a clicks on a link with the MMB for example, the
location bar will gain the focus until the part emits its started signal. This
might be for a brief moment or for extended period depending on when Konqueror
receives the started signal. It does not fix the problem if the part does not
send such signal. To be perfectly honest the timer based solution actually
works much better visually. There is a tiny delay when activating a blank tab
(not creating it), but nothing like what you can observe in this case.
Note that the isLoading() check in KonqFrame::activateChild is still needed for
the session restore case. Otherwise the focus will be on the location bar in
that case as well and as stated previously the calls to emitActivePartChanged()
in KonqViewManager::showTab are redundant calls.
Description
-------
The attached patch address the bug reported in #304933. Right now if Konqueror
is configured to open new tabs in the foreground, i.e. the "Open tabs in the
background" option is unchecked, then the keyboard focus is put on the location
bar instead of the view.
This addresses bugs 304865 and 304933.
http://bugs.kde.org/show_bug.cgi?id=304865
http://bugs.kde.org/show_bug.cgi?id=304933
Diffs (updated)
-----
konqueror/src/konqframe.cpp 10ed7cd
konqueror/src/konqview.cpp db9ffd4
konqueror/src/konqviewmanager.cpp 5352eeb
Diff: http://git.reviewboard.kde.org/r/105984/diff/
Testing
-------
Thanks,
Dawit Alemayehu
