> Finally, permit me to quibble with the proposal to "keep the current behavior 
> as default".  I think it's a bad default.  It violates the principle of 
> "don't surprise the user".  If the user can't interact with a portion of the 
> UI, that portion shouldn't be painted in a way that invites the user to push 
> buttons, click checkboxes, fill in blanks, or whatever.  

In general, I agree with this. But I'm not sure how far a UI toolkit should go 
towards enforcing it. For example, consider the case where a modal dialog is 
opened over another window. The user can't interact with any controls in the 
main window, yet they don't paint a disabled state. Alternatively, a UI 
designer may want to paint a semi-transparent overlay over a container to show 
that it is disabled, rather than having each subcontrol paint its own disabled 
state. So there are arguably cases where this behavior may not be desirable.

I actually don't know what the "right" answer is in this case. Maybe there 
isn't one. Definitely worth more thought/discussion.

G

Reply via email to