pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill van Melle <bill.van.me...@gmail.com>
Subject Re: [jira] [Commented] (PIVOT-798) Component#isEnabled does not affect appearance recursively
Date Sat, 08 Oct 2011 03:53:29 GMT
On Fri, Oct 7, 2011 at 5:09 PM, Greg Brown <gk_brown@verizon.net> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message