On 18/07/2012, at 5:12 PM, Quincey Morris wrote: > It would seem that floating panels ought to follow the #2 and #3 rule. It's > not clear that "window activation state" is meaningless. A user should be > able to see, for example, whether the up and down arrows move the selection > in the source list in the panel or not. >
Well, there are 3 distinct visual appearances, that's true. non-main (and hence non-key), main-but-not-key, and main-and-key. To distinguish between key and non-key in a floater is fine, that makes sense, but the additional distinction between main and non-main is silly here, because a floater works exactly the same in either state. It bugs me for example that the list background changes between white and a light blue in these two "states" even though there is no change in functionality at all. There is a change in functionality when it becomes key, because then I can control it with the keyboard. > The problem is, perhaps, that you've been using Macs for too long. :) Your > brain is used to thinking of gray controls as inactive/disabled, whereas gray > currently just encompasses everything non-key. Could be. But that goes for our users as well. Another particularly bad example is the segmented control, which I'm using as a set of related pushbuttons. They look completely disabled (light grey text) when the window is inactive, and yet work just fine. When the window is made active, they change in appearance to what looks "enabled" to my way of thinking (black text), but only when the mouse enters them! This seems doubly broken to me. The same goes when the window becomes inactive - the buttons stay "enabled" until the mouse happens to stray into their rects, when they "grey out". If that is the intended behaviour, all I can say is somebody was on acid when they made that. On 18/07/2012, at 6:10 PM, Uli Kusterer wrote: > -> It's not the floating panel that does anything with the active state, it > is each view itself. They register for -windowDidBecomeKey: and similar > notifications and redraw themselves accordingly. It must work in some other way. The list view can't be the window's delegate, so that should only leave the possibility that it is asking for those notifications from the window. However, if I deliberately force the list view to unsubscribe from ALL notifications, it still changes state when the window changes state. So there must be a private mechanism in place that the list view uses to track the window state. Corbin, any comment? > -> Have you tried switching "non-activating panel" on? It sounds like that is > what you want. It can still have keyboard focus then, but just won't be the > main window. No. This means that the panel won't activate the app if it is clicked when the app is inactive, but since it's set to hide on deactivate, this setting doesn't apply anyway. The setting you may be thinking of is -setBecomesKeyOnlyIfNeeded:, which I'm using, but this is something else again - it only makes the window key for controls such as text fields that require it when they are clicked for text entry. The list view can become key at times, but is never required to be. But the visual appearance change it makes conveys no information at all, so it is redundant, and I'd like to eliminate it if I can. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
