Bug 26406 - [Forms] Disabled SWT widgets using the Flat Look do not look disabled
Summary: [Forms] Disabled SWT widgets using the Flat Look do not look disabled
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: User Assistance (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P4 normal with 2 votes (vote)
Target Milestone: 3.2 RC1   Edit
Assignee: Dejan Glozic CLA
QA Contact:
URL:
Whiteboard:
Keywords: polish
: 69801 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-11-14 14:46 EST by Wayne Ho CLA
Modified: 2009-09-24 15:08 EDT (History)
12 users (show)

See Also:


Attachments
Disabled text field on XP with the borders rendered (2.40 KB, image/png)
2006-04-10 15:32 EDT, Dejan Glozic CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wayne Ho CLA 2002-11-14 14:46:40 EST
Description:
Text fields, listboxes, drop-down combo-boxes, and other SWT widgets that are 
disabled do not visually appear disabled in the Flat-Look.

Typically, the Flat-Look has a white background and text fields, etc. also have 
white backgrounds. A disabled text field is currently denoted by a gray text 
label, and gray text in the field (if there happens to be text in the field).  
This is very subtle and hard to notice, and is harder to notice when no text 
exists inside a disabled text field in the Flat Look.

Some inconsistencies in how different widgets look makes the enabled/disabled 
distinction more difficult to notice: Enabled list boxes have gray borders 
while text fields have black borders.  Disabled checkboxes have gray 
backgrounds, while enabled checkboxes have white backgrounds.

Note: this is a usability issue as it is currently difficult to distinguish 
between enabled and disabled widgets in a Flat-Look editor.

Suggestion:
For widgets using the Flat Look:
Disabled text fields, listboxes, and SWT widgets in general, should use a 
consistent visual treatment to visually specify that it is disabled.  

All enabled widgets (e.g., text fields, list boxes, etc.) should look similar 
(e.g., black border, white background, black text labels, and black text within 
the field).

All disabled widgets should look similar (e.g., gray border, gray text labels, 
gray text within the field.).  This can also apply for checkbox and radio 
button widgets (gray border, gray text labels, etc.).
Comment 1 Christophe Cornu CLA 2002-11-15 10:01:29 EST
Flat-Look is not rendered by SWT.

Moving to Platform UI.
Comment 2 Eduardo Pereira CLA 2002-11-18 11:38:14 EST
It is not part of workbench.ui either. Wayne, could you post the name 
(package+class) of this widget or the place in Eclipse that they are being 
used. PDE has flat widgets but as far as I know they are not API. 
Comment 3 Wayne Ho CLA 2002-11-18 14:34:42 EST
I am not sure what component this belongs to, but I believe the Flat Look UI is 
done via a thin layer above SWT. From what I understand, Dejan Glozic was 
responsible for this code. 

If this is correct, please route this defect to Dejan or the current owner of 
this code.
Comment 4 Eduardo Pereira CLA 2002-11-18 15:35:32 EST
Not sure if this is a PDE problem or has something to do with 
com.ibm.etools.webtools.flatui

Moving to PDE for comment. 
Comment 5 Dejan Glozic CLA 2003-01-07 16:03:01 EST
Wayne,

What was the conclusion from our meeting - what should we do in PDE for 
disabled entries?
Comment 6 Wayne Ho CLA 2003-01-15 16:17:43 EST
A meeting was held on Jan 15, 2003 to discuss solutions:

1. Disabled text fields (borders and text) and associated labels should be gray 
for the Flat Look UI.
A disabled text field should look disabled by making use of a gray label, a 
gray text field border, and gray text within the text field.  The gray color 
used to represent disabled should be a system gray R128 G128 B128.  This is to 
contrast with enabled text fields which use black.

As discussed in the meeting, Dejan will investigate the feasibility of linking 
the colors of the gray text label, the gray text field border, and the gray 
text within the border.

(Note: we discussed optimizing the disabled widgets for the standard color 
schemes such as the white background.  For other color schemes, the disabled 
color would be computed.)

2. Read-only fields should be black.
Read-only fields should be black as they should look 'enabled' and be easy to 
read.  By simply omitting the use of a border the read-only field will look un-
editable.

3. Disabled listboxes should use a gray border and the associated buttons 
should be disabled.
Listboxes (and other similar containers) should use a gray border (R128 G128 
B128) when disabled.  Associated buttons should look disabled (i.e., by graying 
the text.  It would be preferable to also make the button borders gray but it 
is understood that this is currently not possible).  This is contrasted with 
enabled listboxes with black borders.

(Note: As discussed in the meeting items #3 may not be fixed due to 
time/resource constraints)

4. Enabled listboxes should use a black border and the associated buttons 
should be enabled.
Enabled listboxes should use a black border.  This will provide a visual cue 
that the user can perform an action on the listbox (e.g., through the use of a 
button to add an object to the listbox).  Associated buttons should look 
enabled.

(Note: As discussed in the meeting items #4 may not be fixed due to 
time/resource constraints)
Comment 7 Andrew Kaye-Cheveldayoff CLA 2004-09-02 11:21:54 EDT
We saw this issue in some recent usability studies on Eclipse 3 based products. 
Having widgets disappear can be confusing to the user. It also affects the 
discoverability of some items since disabled widgets are not visible.
Comment 8 Dinko Ivanov CLA 2004-11-03 09:06:54 EST
I saw that the current issue is still present in Eclipse 3. Is there any 
activity or progress on this bug?
Comment 9 Dejan Glozic CLA 2004-11-09 16:34:35 EST
*** Bug 69801 has been marked as a duplicate of this bug. ***
Comment 10 Dejan Glozic CLA 2005-01-26 13:58:05 EST
We will probably revisit this issue in the 3.1 time frame, but there are 
couple of problems:

1) On Windows XP with skinned widgets used by SWT, we use native borders i.e. 
we don't render flat borders. As a result, we cannot use borders to indicate 
disabled state
2) As a usage pattern, Eclipse developers use 'setEditable(false)' instead 
of 'setEnabled(false)' for text widgets that should not be editable. They look 
the same but the content cannot be edited. This is consistent with the 
behaviour of text-only editors when read-only files are opened. They look the 
same, but you cannot change the content.
Comment 11 Donal Riordan CLA 2005-11-18 08:15:00 EST
Are there any more updates on this bug? I notice that it is still present in 
Eclipse 3.1
Comment 12 Dejan Glozic CLA 2006-04-10 15:31:40 EDT
I am closing this defect with the following resolution: 

We will now render borders for all widgets irrespective of their enabled state. On newer OSs this looks quite nice. On XP, the text is gray instead of black (see attachment).

Due to the fact that the enabled state of the widget is not part of the SWT event system (i.e. I cannot listen to changes to the enabled state of the widget), we cannot make any changes to the widget based on it. Therefore, rellying on the windowing system to render the text itself correctly is our only solution. 

On OSs that change the widget background for disabled state, you can also call 'setBackground(null)' for the widget, allowing it to make the background modification based on the state by itself. For example, when 'setBackground(null)' is called on a Text widget, the widget will be white on XP when enabled and gray when disabled. In general, I recommend not doing this.
Comment 13 Dejan Glozic CLA 2006-04-10 15:32:48 EDT
Created attachment 38205 [details]
Disabled text field on XP with the borders rendered

Note that in 3.2 on XP skinned widgets are used automatically so native (skinned) borders will be used instead.
Comment 14 Dejan Glozic CLA 2006-04-10 15:43:47 EDT
Marking as fixed - we will not be doing anything else in this space in 3.2
Comment 15 Paul Slauenwhite CLA 2009-09-24 14:57:29 EDT
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
Comment 16 Paul Slauenwhite CLA 2009-09-24 15:08:37 EDT
Please ignore the previous comment.