Re: All-windows Exposé messes with NSFloatingWindow level
Re: All-windows Exposé messes with NSFloatingWindow level
- Subject: Re: All-windows Exposé messes with NSFloatingWindow level
- From: Ricky Sharp <email@hidden>
- Date: Mon, 20 Nov 2006 18:47:24 -0600
On Nov 20, 2006, at 6:09 PM, Albert Andersen wrote:
I think this is probably an Apple bug in exposé, since it seems to
afflict their apps too. I'm just hoping that someone knows a way
around it.
1. Open any app with a window or panel at NSFloatingWindowLevel.
IB, with its inspector and palettes, works fine.
2. With IB on top, and assuming standard exposé hotkeys, hit F11,
F9, F9. You will be back with IB on top as normal.
3. Attempt to interact with the Inspector or Palettes.
Can't do it, can you?
I was able to reproduce this (10.4.8 PPC). I also used IB. Launched
it and then closed the startup window. Only window then open was the
floating window of palettes. After the F11, F9, F9, sequence, I was
unable to drag the window. Quitting and restarting IB would put up
the IB palette window in a totally different spot. Was always to the
left of where it originally was, and often partially off the screen.
I believe that's also the relative direction that I attempted the drag.
If you F11 in and out, the palette reappears somewhere far from its
previous position. This is affecting my app in a similar way.
If starting with a fresh launch, I can F11 in/out repeatedly without
issue. If after the initial F11, F9, F9 sequence you then attempt to
drag the window, it will not move. After that point, hitting F11
does indeed move it to a different spot (basically what happens if
you quit, then relaunch).
Apparently, the window is actually being dragged to a new location,
but perhaps the window server is not updating the windows.
I've filed the bug with apple, but I'd rather find a decent
workaround than hold my breath waiting for a fix.
Not sure of any workaround. Way back when I was still doing the
carbon flavor of my full-screen app, it too would not interact
correctly with Expose (for other reasons). I've since solved that
particular problem by using the SetSystemUIMode where my app
effectively ignores Expose. However, another potential solution
early on was to file an enhancement to have a API such that one could
mark (in carbon & cocoa) a window to not participate in Expose. For
example, I can see floating windows sometimes not wanting to be moved
around. If such an enhancement would work for you, please file it.
I never filed it myself since I had a better solution that fit my needs.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden