[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konq-bugs
Subject:    [Bug 183861] "clear location bar" button missing
From:       Thomas Fischer <fischer () unix-ag ! uni-kl ! de>
Date:       2012-12-31 12:16:27
Message-ID: bug-183861-5021-HwOTjwhPBD () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=183861

Thomas Fischer <fischer@unix-ag.uni-kl.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fischer@unix-ag.uni-kl.de

--- Comment #9 from Thomas Fischer <fischer@unix-ag.uni-kl.de> ---
> right, it seems there's a bug in klinedit that prevents it from
> updating the clear icon right away if some text is already
> written in the linedit... removing the text and writing some
> more makes the icon appear.

The button is still there. If you hover with the mouse, you'll get the tool tip
and you can blindly click on it to clear the line edit.
The problem comes from the animation itself (see file klineedit_p.h,
KLineEditButton::animateVisible). Initially, the animation's direction is
Forward (can be either Forward or Backward). Now, when the button is to be
shown, animateVisible(true) is called. In case it was hidden before (by a
previous animateVisible(false) call), the direction is Backward and everything
works. However, under certain circumstances as observed above, a button may be
invisible and the animation direction is still Forward (default value for the
QPropertyAnimation object). The function assumes that this is due to calling
animateVisible(true) a second time while the animation is in progress and
returns immediately (check for the two return statements in this function).
To enforce that the clear button gets properly shown during initialization, I
propose some "dirty" marker so that KLineEditButton knows it was freshly
initialized. The simplest idea I came up with and which seems to work is to
initialize m_opacity with -1 instead of 0 in the constructor.
In animateVisible(bool), the if clause with the return-on-forward is modified
to test if m_opacity is not equal -1. Don't worry about this invalid opacity
value, the enforced animation will set it to a proper value between 0 and 255.

if (m_opacity != -1 && m_animation->direction() == QPropertyAnimation::Forward)
{
    return;
}

This is exactly the same bug I encountered and as reported in bug 294954 (apart
from the cast issue I just commented on). Feel free to use the test program
attached to report 294954 to experiment on this bug report here.
Someone with permissions can set bug 294954 as duplicate or "depends on" of
this bug report here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Konq-bugs mailing list
Konq-bugs@kde.org
https://mail.kde.org/mailman/listinfo/konq-bugs
[prev in list] [next in list] [prev in thread] [next in thread]