Created attachment 69144 [details] Test case to compile Version: 4.7 (using KDE 4.7.4) OS: Linux Under certain circumstances does KLineEdit not draw or place its clear button correctly. The attached screenshot and test case (small program to compile) demonstrate this. The first case is an editable KComboBox where the internal line edit is set to read-only. The clear button is shifted vertically by about half the line height and horizontally about 100px indented from the left side. Clicking the button still works (clears text) even that the button is misplace and the line edit is set read-only. This the first line the attached screenshot. The second case is a plain KLineEdit, where the clear button seems to be not drawn. Clicking is still possible (by guessing the position), it clears the text and the "clear button" icon is shown briefly. This the third line the attached screenshot. Reproducible: Always Steps to Reproduce: Check the screenshot and the attached test case (source code file src/testmainwindow.cpp).
Created attachment 69145 [details] Screenshot demonstration the problem
Created attachment 72959 [details] screenshot of klineedittest looks a bit different here. kde 4.8.4
For future reference: The problem as observed in the first KComboBox in my example is due to the fact that lineEdit() on a KComboBox returns QLineEdit* although internally it is a KLineEdit*. Calling setReadOnly(..) on this return value calls QLineEdit's implementation, but not the one of KLineEdit. The solution is to (dynamic|qobject)_cast the QLineEdit* to a KLineEdit*. Calling setReadOnly on the cast's result uses KLineEdit's setReadOnly implementation which performs proper layouting of the clear button. KLineEdit *internalLineEdit = dynamic_cast<KLineEdit*>(comboBox->lineEdit()); if (internalLineEdit != NULL) internalLineEdit->setReadOnly(true);
The hidden/missing clear button seems due to the bug as described in bug report 183861 and 268898. The latter report has a fix that went through git.reviewboard (https://git.reviewboard.kde.org/r/102095/) and was comitted to HEAD. The fix was never backported to 4.[789].x, but seems to be in 4.10. I am therefore closing this bug report. *** This bug has been marked as a duplicate of bug 268898 ***