Version: (using KDE 4.1.2) Installed from: Ubuntu Packages In several places in KDE (for instance, Kate's bookmark manager) there are text fields that are inactive for one reason or another. These text fields should have a visual indicator that they are inactive, for instance they should be a darker colour than the active fields. See bug 166066 for confusion caused by the current situation. Note that I file this as a Bug, and not as a Wish, because of the usability implications. I have had this issue bite me before, and it is often time consuming to figure out what is wrong.
That's a bug in KDE's bookmark manager, I can reproduce this with trunk. If now bookmark is selected the text fields appear enabled but you can't enter anything
Although the issue mentioned in bug 166066 was specific to KDE's bookmark manager, the issue of disabled input fields being visually indistinctive from active input fields is found throughout KDE 4.
Disabled widgets should be using disabled colors. You could check this by changing the effects for disabled widgets to something insane, like tint to red (in the 'disabled effects' tab of the color kcm). If it's not working... I'm not sure what to say, Qt is supposed to handle it. Are you sure you're seeing /disabled/ widgets and not /read-only/ widgets?
For all intents and purposes, a /read-only/ widget is /disabled/ so far as the user is concerned: he tries to type in it and cannot. Furthermore, these /read-only/ widgets are in fact /read-write/ widgets sometimes, so the visual distinction is even more critical. Further, furthermore, mousing over these /read-only/ widgets highlights them like any other input element. Steps to reproduce: 1) Open Kate's Bookmark Editor 2) Create a bookmark 3) Mouse over the Location field. Try to focus the field and type in it.
You can't select text in disabled widgets. Ergo, read-only != disabled. (But maybe it should be?) Since this affects many parts of KDE, you might want to first check if there is already an HIG guideline regarding this, and if not, ask on kde-usability about it (maybe we should write one?). Then when there is consensus what is "correct" behavior, bugs should be filed against specific apps that violate the guideline.
This bug is not about selecting text. The bug is about a widget that looks [active|enabled|working] but is not.
While this "bug" may show with many styles, the behavior can actually be controlled by the style, i.e. it can render read-only line edits to look disabled. Reassigning to Oxygen. It may have to be discussed with artists and usability team if a change can be made here.
in fact, this bug is invalid. Specific examples should be provided (in different bugs) whenever this situation occurs. Oxygen do draw disabled text whenever it is asked to. When this is not the case, its usually an upstream bug and not oxygen's. Closing as invalid. Awaiting for detailed bugs of this sort if there are some.
Created attachment 55912 [details] UI file Hugo, please read the bug carefully. This bug is about read-only line edits, not about disabled widgets. There is no visual indication that you cannot enter text (not that any other style has one ...)
Cristoph, as far as I recall, there is an indication: there is no cursor. In my opinion there should be no other indication (and especially not a "disabled" look), since as was pointed out in the bug (which I did read) you however can select the text, copy it to clipboard, etc. Besides, this issue is not what the bug title refer to.
Also, for QLineEdit at least, the mouse pointer does not change shape (to edition pointer) when passing over a read-only widget. Thats another strong indication I believe. This is not the case for QTextEdit, but that's not oxygen's fault. I was thinking of disabling the (keyboard) focus glow for read-only editors, but it turns out this also would be incorrect 1/ because you can still put the focus on such widgets 2/ you can actually select text using keyboard navigation in the editor. So really, this part of the bug would also be invalid, in my oppinion.
I updated the title to reflect the nature of the bug. A readonly text field should be visually similar (if not identical) to a disabled field, and _not_ visually similar to a read/write field. Changing the mouse indicator or the presence of a cursor does not help the user who is not mousing over. Also, the changing mouse indicator is not noticed by regular users, and it is quite the lack of a cursor that makes users feel that something is not working when it should. Shall I post explicit screenshot of how other environments (Mac, Windows, Gnome) handle readonly text fields? Thanks.
@Dotan, First, thanks for changing the title to make it more explicit. However I still consider the bug as invalid and won't fix. The arguments are already stated above but let me restate 1/ there are already visible differences for readonly editors and editable ones. You dim them insufficient, but i disagree. 2/ readonly editors can get keyboard focus whereas no disable widget can. This in itself close the debate, as far as I am concerned. 3/ Many readonly *text* (multi-line) editors have no distinction between read-only and editable, on all OS's, and should stay so. Example include: kmail's message view (which is read-only) konqueror's main HTML viewer, any text-editor opening a read-only file etc, konversation (or kopete) message logs, etc. Oxygen (and me) makes no conceptual difference between single and multi line editor, so will not change their apearance of the latter, for consistency with the former. Since you don't seem happy with INVALID (though to me, it is, because of point 2), I'm closing as WONTFIX.
The example places that you state (Kmail's message view, Konqueror's main HTML viewer) do not have the same visual appearance that do editable text fields. The root of this issue is text fields that _do_ appear to be read/write, and that a user would reasonably expect to be, but are not. Please see this bug for the confusion that the issue causes: https://bugs.kde.org/show_bug.cgi?id=166066
PS: re-reading previous post I realize that my english is far from perfect. I guess I've typed too quick, and its been a long day. Sorry ...
mmm. They do (all but konqueror) have the same appearance in oxygen. Sunken frame with shadow, with white background, and glow with different colors with mouse over and keyboard focus. An explicitely disabled lineeditor would do none of the above. For the bug you mention, I would suggest that the application explicitely disable the widget, as long as it wants it disabled. As mentionned by my point 2 above, a read-only editor *is not* a disabled editor.
That's alright, I understand you even if we disagree! You should see my own English when the coffee runs out... in any case, it's late here so Buenos Noches until tomorrow...