On Fri, Oct 7, 2011 at 5:09 PM, Greg Brown <[email protected]> wrote:
> 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. > True, I don't often see an app doing something like that. That's a slightly different case, because they wouldn't normally be painting those controls anyway -- they'd have to go out of their way to notice that a modal dialog was taking over and repaint every window whose events were thereby being intercepted, and I can imagine it might be tricky to get it right. Of course, some people think modal dialogs are already a bad UI. > 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. > Yeah, I've considered doing that myself as a workaround for the current behavior. But it's much easier if the toolkit will do the disabled state painting for me on its own :). > I actually don't know what the "right" answer is in this case. Maybe there > isn't one. Definitely worth more thought/discussion. Yes, please. I'd like to hear from people who think my proposed default would not be right for their use case.
