Re: (10.0.x) option-clicking in statusbar hides active app (update)...
Re: (10.0.x) option-clicking in statusbar hides active app (update)...
- Subject: Re: (10.0.x) option-clicking in statusbar hides active app (update)...
- From: Philip George <email@hidden>
- Date: Wed, 16 Jul 2003 02:50:08 -0500
Alright, I have tried categories, posers, and basic subclassing of several
core classes like nsapplication, nsrunloop, etc. All this to find out that
it appears as though an option-click to a window does not EVER reach your
main thread's NSRunLoop to be discpatched out to the appropriate window for
handling. It appears as though the window server (who is in charge or
notifying your run loop in the first place) handles the hiding of the active
app before notifying your app to focus. The click (if it's an option click
AND if another app was active when you option-clicked your window) never
makes it to your run loop at all, therefore there is NO place (that I know
of) that it can be caught and killed before hiding other apps.
Remember, the is an NSStatusBarWindow, not a normal window, so this
functionality IS a bug and should NOT be happening and should have been
fixed by Apple in one of the 10.0.x maintenance releases, but wasn't.
Option-clicking the system clock, for instance, absolutely should NOT hide
the active app. But it does. See the problem?
//////////////////////////////////////
//////////////////////////////////////
So, the question is now:
How do I catch a click BEFORE the window server hears about it?
//////////////////////////////////////
//////////////////////////////////////
If you want to discuss anything besides this one question, please do it
off-list. Questions about why I need to do this or why I care about how my
app works in 10.0.x, I will gladly answer off-line. Also discussions about
whether or not Apple should have fixed this in a maintenance release of
10.0.x or ANYTHING that isn't productive in answering this question, do it
OFF-LIST. I'm sorry that I have to spell this out every time now, but it
has become a problem lately and I am in need of some serious, focused
troubleshooting and brainstorming right now. All else is beside the point.
Thanks.
- Philip
On 7/15/03 6:16 AM, "Philip George" <email@hidden> wrote:
>
Okay, here's an update. On a whim, I searched the help center for "hides" and
>
found an article called "Shortcuts for Windows" which notes that you can hide
>
the previous app when switching apps by option-clicking a window. You're
>
probably laughing right now because I didn't know this, but I just never tried
>
it I guess. That's hilarious.
>
>
This still quailfies as an OS bug, because the problem isn't that feature in
>
an of itself; the problem is that NSStatusBarWindow -- the private subclass of
>
NSWindow that is used for holding the content of your statusitem -- is failing
>
(in 10.0.x) to ignore that click. Even when I control click on the system
>
clock in 10.0.x it hides the active app. That's not what should be happening
>
obviously.
>
>
So, I guess I need to make an obj-c category for that api and kill the click
>
myself.
>
>
I'll post the outcome in case anyone's interested.
>
>
- Philip
>
>
>
>
>
On 7/15/03 3:51 AM, "Philip George" <email@hidden> wrote:
>
>
> Okay, one of the design objectives of the app I'm currently working on is
>
> that
>
> it must work perfectly in ALL versions of OS X, from Jaguar right down to
>
> 10.0. So please, if you have to ask why, do it off-list, because that would
>
> definitely not be helpful.
>
>
>
> So, the app is primarily a statusitem (top of screen, in the menubar, over to
>
> the right. if you don't know this stuff, you should probably skip this
>
> post).
>
>
>
> The interface is 100% controllable via mod-clicks to the different parts of
>
> the interface in the statusitem. I allow the user to choose any combination
>
> of shift, control, option, and command modifier keys while clicking the
>
> different "hot spots" (for lack of a better description) of the interface.
>
>
>
> In 10.2.x, this works perfectly.
>
>
>
> In 10.1.x, this works perfectly as long as I fix NSStatusbarButton using the
>
> code snippet provided by Apple (
>
> http://developer.apple.com/qa/qa2001/qa1081.html ) to ensure that statusitem
>
> clicks don't activate the app. That is fixed, so it does work perfectly in
>
> 10.1.x
>
>
>
> In 10.0.x, it ALMOST works perfectly. Everything is A-OK until I
>
> option-click
>
> any part of the statusitem. This not only activates my app; it hides the app
>
> that WAS active. Yuk.
>
>
>
> Anyone seen this?
>
>
>
> What can I do to fix?
>
>
>
> Again, if you're tempted to ask why I am worried about such an old version of
>
> the OS that not many folks are even using, then feel free to do so OFF-LIST.
>
> I'll be glad to answer off-list.
>
>
>
> Thanks.
>
>
>
>
>
> - Philip
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.