Version: 1.2.1 (using Devel) Installed from: Compiled sources Qt: 4.6.0 KDE: 4.3.80 (KDE 4.3.80 (KDE 4.4 Beta1)) "release 9" Konversation: 1.2.1 When I move mouse over channel topic, user list or channel tabs, mouse cursor disappears.
It's a Qt 4.6 bug (one of many - the buggiest Qt I remember in years and years).
Can't reproduce it with KDE 4.3.4 and Konversation from SVN
Notably it doesn't happen consistently, just intermittently. Started with 4.6rc1 :-(.
Anyone knows if this was fixed upstream ?
It's still happening in Qt 4.7 Technical Preview 1 at least.
SVN commit 1125863 by smartins: Workaround the disappearing mouse cursor bug so we can use to-do view without having to restart korganizer. CCBUG: 231177 CCBUG: 217592 MERGE: none M +3 -0 kotodoviewquickaddline.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1125863
*** Bug 231177 has been marked as a duplicate of this bug. ***
*** Bug 244128 has been marked as a duplicate of this bug. ***
There's been a small breakthrough: A user has finally found a reliable way to reproduce the problem (though for him, as for some others, the cursor changes into the text cursor instead of disappearing entirely). 1. Make sure you have the large paste warning dialog enabled (it is by default) 2. Select several lines of text in the chat text view 3. Try pasting them into the input line using middle-mouse (not Ctrl+V) 4. Close the large paste warning dialog that appears using the ESC key (this cancels the paste) 5. Cursor is now screwed up above the tab bar/tab list Armed with the above and the knowledge that the Qt bug was so far as we remember introduced some time between Qt 4.6beta and Qt 4.6rc1, someone could bisect Qt to find the offending revision.
Some months ago i bisected the korganizer "disappearing cursor" bug down to Qt 4.5 and gave up, was still reproducible. I then noted that creating a QDialog instead of a KDialog made the bug go away, so i trimmed KDialog until it was ok, and that led to KDE's r989720. That commit introduced the bug (or exposed a Qt bug).
Let me amend the above steps to reproduce a bit: 1. Make sure you have the large paste warning dialog enabled (it is by default) 2. Select several lines of text in the chat text view 3. Place the mouse cursor in the input line 4. Type several characters - this causes the mouse cursor to disappear, due to KDE's hide-cursor-when-typing feature 5. Paste the previously selected lines into the input line using middle-mouse (not Ctrl+V) without causing the cursor to move so much that it is unhidden in the process 6. Close the large paste warning dialog that appears using the ESC key (this cancels the paste) 5. Cursor is now screwed up above the tab bar/tab list
*** Bug 247284 has been marked as a duplicate of this bug. ***
I tried Sergio's suggestion: reverting KDialog to r989719. Unfortunately this did not make the bug go away in konversation. Note: I reproduced the bug with the steps from Eike (from #c11). I built konversation from git just a few hours ago (d2c114f67f6db1f0eae7edecdaf0486ca317970a was the last commit). First I tried to revert the changes from r989720 (and just those changes): => bug still occurred. Then I tried to revert to r989720-1 (=r989719): => bug still occurred.
Thank you Martin. That's unfortunately what I feared; the old and new KDialog code should be functionally equivalent. The hunt continues ...
commit 0a5bc983c817c24783b9578b0ed236bc3a9c3645 Author: Eike Hein <hein@kde.org> Date: Mon Sep 20 12:35:44 2010 +0200 Work around bug 217592 (the infamous cursor disappearing act). The underlying ongoings are that there are two widgets involved, the KTextEdit and it's viewport(), both of which KCursor installs an event filter on, which on keypress events sets a blank cursor on the KTextEdit. On a FocusOut event, such as occurs when the paste warning KMessageBox is spawned and assumes focus, KCursor then calls unsetCursor() on it. Qt's behavior however seems to have changed in such a way that unsetCursor() doesn't affect the KTextEdit's viewport(), which QTextEdit originally set the I-Beam cursor on. So we do it manually here. But in the end either the Qt behavioral change has to be addressed, or KCursor has to be equipped to deal with it, since this obviously can happen in all KDE apps (and does, as seen in bug 231177). CCBUG:217592 diff --git a/src/viewer/ircinput.cpp b/src/viewer/ircinput.cpp index 05653a8..a282e63 100644 --- a/src/viewer/ircinput.cpp +++ b/src/viewer/ircinput.cpp @@ -501,6 +501,9 @@ bool IRCInput::checkPaste(QString& text) QString bytesString = i18np("1 byte", "%1 bytes", text.length()); QString linesString = i18np("1 line", "%1 lines", lines+1); + // Work around bug 217592. + viewport()->setCursor(Qt::IBeamCursor); + doPaste=KMessageBox::warningYesNoCancel (this, i18nc(
Upstream (Qt) bug report with test case: http://bugreports.qt.nokia.com/browse/QTBUG-6185
The Qt bug has been fixed now and the fix will hopefully be included in Qt 4.7.1.
*** Bug 271880 has been marked as a duplicate of this bug. ***