Re: Cause of flickering title in load/save dialogs

[Alexander Malmberg]

Adrian Robert wrote:
> I've noticed and others have posted that the window title flickers 
> for load and save dialogs (NSOpenPanel and NSSavePanel).  I found 
> this is caused by a call to [theSession->window orderFrontRegardless]
>  in [NSApplication -runModalSession:], which itself is called 
> repeatedly in a loop in [NSApplication -runModalForWindow:], once 
> call per mouse movement event.  Commenting this line out fixes the 
> problem and seems to cause no ill effects (in limited testing).
>
> There are a couple of other calls in runModalSession which seem 
> questionable:
>
> 1) calls to -makeKeyWindow or -makeMainWindow (why can't these be 
> done just once in -beginModalSessionForWindow: ?)

I've had this change locally for more than a year, with the following
comment:

---
This is fairly broken, and causes excessive flickering in some cases.
Forcing the session window to be key, main, and ordered to the front
seems wrong:

1. -orderFrontRegardless will order it in front of other apps. The
user should be able to use other apps while in a modal session for
this app, and stray events shouldn't cause windows to order around.

2. Some windows work even in modal sessions. These might be ordered
on top of the session window, or become key or main, and we shouldn't
block this here.

3. -beginModalSessionForWindow: will already have ordered the window
in and made it key/main.
---

I've never noticed any ill effects, but I've found plenty of bugs with 
this code present, so I've committed this change now.

Adrian Robert wrote:
> ...I just read the Apple docs for these methods (should have done
> this before, sorry).  It looks like it is correct for
> -runModalSession: to request the window to the front. [snip]

I'm aware that their docs says this (or at least seem to imply it), but 
it makes no sense to do follow this. (E.g. bring up an open panel in a 
GNUstep app, switch to another app, and accidentally move your mouse 
above some window from the GNUstep app. This code will then move focus 
back to the GNUstep app, which is definitely not what you want.)


>  2) calls to updateServicesMenu and mainMenu update (if the given 
> window is modally selected can the user even interact with the menus?
>  why not call this once in -endModalSession:?)

That might be possible, but it'd have to be examined more closely.

> Anyway, I'd like to at least move the -orderFrontRegardless: call to 
> -beginModelSessionForWindow:, although not even this seems necessary 
> at least on my particular system.  On the other hand, maybe all this 
> code is correct and something else is not working as expected -- e.g.
>  the calling of -runModalSession: on every mouse movement sounds 
> fishy. Thoughts?

Well, we will get a run loop iteration for each event, so as long as we
produce events for all mouse movement, this is expected. I guess the
alternative would be to make the backend not generate these events
(unless a mouse button is being pressed, etc.) and try to fix tracking
rects and use them more extensively.

- Alexander Malmberg