Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Philosophy behind UI Element Destroyed notifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Philosophy behind UI Element Destroyed notifications

What is the heuristic that developers are expected to follow? Specifically,
should we generally "pretend" that a child element of a destroyed parent
element is destroyed, even though the child element does not issue a
destruction notice? If that is the rule of thumb, will there be some
documentation to keep us all on the same path? For example, I can easily
enough mark child elements of a "destroyed" drawer as destroyed, but should
I do this with sheets, too?

In general, we don't treat being obscured as being destroyed.

As a rule, when a ui element is destroyed you must treat all its
descendants as being destroyed. If you don't then you may end up with
your refs suddenly going bad, or worse yet, pointing to entirely
different ui elements.

Sheets are just dialogs that are attached to windows. When they disappears
and reappears they often come back in a different configurations (e.g. the
open/save panel). This is why we treat window closing as destruction. At
the framework level that's about all we can do. Since the app knows more,
I guess it could override this when appropriate - if we provided them a
way to do so - which we don't.

I'll grant you that drawers are a bit less clear cut - and the way they're
commonly used more closely matches a model of obscuration. If we changed
to treating drawers this way it would mean a window would have to
report its closed drawers as children and expose the contents of those
drawer to accessibility. This would be problematic, maybe not insurmountable,
but it would have to be investigated.

Anyway, if you feel strongly about either of these case you can file
bugs. But the general rule of a ui element being destroyed implying its
children are destroyed still holds.

-ME
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Philosophy behind UI Element Destroyed notifications (From: Bill Cheeseman <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.