Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Darwin disk I/O - better interactive response

On Monday, January 29, 2001, at 11:57 AM, Chris Page wrote:
Some applications do quite a bit of work to update the contents and enabled
states of menu items. Pushing from the app to the window server every time
the state changed could potentially be a performance hog and decrease UI
responsiveness.

Also, I question the fundamental issue: Should an application allow me to select menu options to send events to an application that is currently busy and unable to process those events? If the event queue can't process the fact that I want to display the menus for my application, should the user be able to send events to my application at all? If I'm not responding, I'm not responding - does it matter whether my menus are visible or not? If they're visible, what do I do, allow these menu events to queue, so that when I'm for whatever reason unblocked, I start processing events that are long-dead in the user's mind?

I think it raises a whole huge can of worms with regards to usability if the menus are visible but my ability to process those menu events isn't present. I'd say that even if you're able to show those menus that unless I'm able to process those events, those menus should be totally gray.

:plur,
Greg

References: 
 >Re: Darwin disk I/O - better interactive response (From: Chris Page <email@hidden>)



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

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.