Hi Andras, 
 
I have problems to reproduce this bug. I have KDE CVS (20030318) and Qt 3.1.1. 
I tried to reproduce it in stand-alone mode and embedded in Konqueror. 
 
Is the tooltip not shown at all? Or does it just flicker or disappear when you have 
the cursor at a special position? What is your screen resolution? 
 
Bye 
Christian 

Subject: Re:  Tooltip disappears if the log message was too long

Hi,

  I've updated yesterday from the CVS and made some more investigations. The
problem appears not exactly when the tooltip is too long to fit to screen,
but if it appear nearby the mouse pointer and you drag the mouse over the
tooltip. In this case the tooltip disappears. The flickering is seen because
when the tooltip is too long, it appears under the mouse pointer, not
somewhere in the right, and if you move the mouse down, it quickly
disappears, but as the mouse is still above the same item, it appears again,
and if you move a little, it disappears again and so on.
 If you move the mouse up (or towards the upper-left corner of the screen),
this won't happen as the tooltip never appears above the mouse pointer. It's
always below or slightly right, but below the pointer.
 And you can see the problem only when the CVS log view is in Tree view mode.
In List mode the tooltip is always far enough below the mouse, so you cannot
drag over.
 I think the only solution would be to show the tooltip some more pixels
below the mouse pointer, so you cannot drag the mouse over it and cause it to 
dissappear.

Andras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+hYZfTQdfac6L/08RAsr8AKCGYOA7Rw3p8ajzLCHx9cqIubHZlwCeNfgT
i4PxZV5j1LNfAkbz2k5+0kc=
=xu6g
-----END PGP SIGNATURE-----

Hi Andras, 
 
Thanks alot for the update and further investigation. I could reproduce the behavior 
you described now with CVS HEAD and KDE 3.1.1.  
 
I'll try to fix it for KDE 3.1.2. 
 
Christian 

Still reproduceable in KDE 3.2

A pathological testcase is
/kdelibs/khtml/rendering/render_line.h rev. 1.2

The comment is so large that the tooltip covers the whole screen and flickers and flickers and flickers...

*** Bug 70759 has been marked as a duplicate of this bug. ***

CVS commit by cloose: 

Replace TipLabel class with a real QToolTip subclass. This fixes the original problem of BR #55871
and also cleans-up a little bit the code of the LogTreeView class.

The problem with the too big tooltips still exists.

CCMAIL: 55871@bugs.kde.org


  A            logtreetooltip.cpp   1.1 [QPL]
  A            logtreetooltip.h   1.1 [QPL]
  M +1 -1      Makefile.am   1.45
  M +28 -66    logtree.cpp   1.18
  M +4 -6      logtree.h   1.12

Hi Christian,

On Wednesday 18 February 2004 23:14, Christian Loose wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=55871
>
>
>
>
> ------- Additional Comments From christian.loose hamburg de 
> 2004-02-18 23:14 ------- CVS commit by cloose:
>
> Replace TipLabel class with a real QToolTip subclass. This fixes the
> original problem of BR #55871 and also cleans-up a little bit the
> code of the LogTreeView class.

IMHO this is suboptimal. The reason for TipLabel is that it doesn't have 
a timeout. With normal QToolTip it's very hard to read long messages.


André

First of all sorry that I didn't realize that you assigned the bug to yourself.

I know that the solution is not optimal, but:

a) It cleaned-up the code in the LogTreeView class.
b) We probably would have to almost copy all of the positioning code of the QToolTip class to fix the original report.
c) We could hack around the problem of the delay with the setWakeUpDelay() method.
d) We could bug TT to give us something more convinient than c).
e) In order to scan throught the commit messages, the new LogPlainView is better anyways.

As always I'm open to better solutions. That's also the reason why I didn't backport it yet.

Christian

*** Bug 75721 has been marked as a duplicate of this bug. ***

CVS commit by woebbe: 

Here it is the one tooltip to rule them all.

pros:
- tooltip text is truncated if necessary (fixes BR #55871)
- no more drawing glitches if you scroll while the tip is visible
- no more need to subclass for every widget
- less code duplication

cons:
- as QToolTip it has a timeout so it's difficult to read long texts
  (I hope the timeout is configurable in Qt 4)


CCMAIL: 55871-done@bugs.kde.org


  A            tooltip.cpp   1.1 [QPL]
  A            tooltip.h   1.1 [QPL]
  M +6 -0      ChangeLog   1.112
  M +2 -2      Makefile.am   1.46
  M +19 -60    annotateview.cpp   1.16
  M +8 -14     annotateview.h   1.8
  M +15 -57    loglist.cpp   1.17
  M +2 -7      loglist.h   1.14
  M +22 -8     logtree.cpp   1.19
  M +4 -3      logtree.h   1.13
  R            logtreetooltip.cpp   1.1
  R            logtreetooltip.h   1.1
  R            tiplabel.cpp   1.7
  R            tiplabel.h   1.3