The button was removed because it's built into the lineedit nowadays, you see the little black icon at the right of your lineedit, right? ;)

IMHO this is only a "docu" bug in the Tips & Tricks page.

Created attachment 31172 [details]
screenshot

actually, i don't - do you?

Yes I do - http://www.davidfaure.fr/tmp/clearbutton.png​

This comes from setClearButtonShown(true) in KonqComboLineEdit::KonqComboLineEdit.

If this doesn't work, I suggest to look into KLineEdit. Are you using the default KDE style? Maybe the hacks there don't work with some widget styles or with Qt-4.5.

Oh --- and you need to first type something in the lineedit otherwise there is nothing to clear and the clear button disappears :-)

i already had both the idea with styles and with the need to enter something first ...

ok, got it. sneaky one: when the toolbar button is enabled, the built-in one is disabled. however, that affects only newly opened windows, so i didn't notice it when playing with the toolbar config. and of course i had enabled the toolbar one in the first place because initially i didn't think of having to type something first and from a kde3 user perspective "it just wasn't there".

so ... for one, the button for the toolbar should be eliminated. as it, it is useless anyway, and it adds to the confusion.

second, i *think* that the disappearing delete button is bad usability (changing ui and such). and it's not like space needs to be saved when the line edit is empty anyway ... so it should be just disabled (designer's property editor has something similar, though for a different purpose).

> ok, got it. sneaky one: when the toolbar button is enabled, the built-in one
> is disabled. however, that affects only newly opened windows, so i didn't
> notice

hmm, I think I wrote this code and I'm pretty sure I made it update lively when you apply your settings, precisely so that it wouldn't be confusing... 

[testing]

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 logic looks fine on casual inspection though... gotta looks at that some more.

> so ... for one, the button for the toolbar should be eliminated. as it, it is
> useless anyway, and it adds to the confusion.

I beg to differ as someone who tried very hard to get used to the embedded clear button.

I had constant accessibility problems due to the target being much smaller (14x14) compared to the toolbar button (up to 48x48 - typically 22x22), and just next to the history dropdown button which kept poping on me in the most infuriating manner.

And to top it all, it puts your mouse at the far right in LTR, that is at the opposite point where your input cursor stands - quite disturbing and time consuming.

I think, at least for sloppy hands, the non-embedded clear button remains a killer feature.

> second, i *think* that the disappearing delete button is bad usability
> (changing ui and such). and it's not like space needs to be saved when the 
> line edit is empty anyway ... so it should be just disabled (designer's
> property editor has something similar, though for a different purpose).

couldn't agree more...

Maybe the clear button in klineedit could be made bigger?

Maybe it could optionally moved to the left side (since it's indeed common to have a very wide combobox in konqueror together with a very short URL, so the current position is quite far from the text)?

Cc'ing Aaron since he wrote the clear button in klineedit.

I also do have the Cleat button in 4.2.0

> 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.

Created attachment 76113 [details]
Setting m_opacity to -1 to enforce showing the button

I am suspecting that this bug report is a duplicate of bug report 268898, which means that this issue is fixed in 4.10 and HEAD.