[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix for window flicks when getting focused
From: |
Yen-Ju Chen |
Subject: |
Re: Fix for window flicks when getting focused |
Date: |
Sun, 9 Sep 2007 11:45:35 -0700 |
On 9/7/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> Yen-Ju Chen wrote:
> > This is the current implementation of makeKeyAndOrderFront:
> >
> > - (void) makeKeyAndOrderFront: (id)sender
> > {
> > [self orderFront: sender];
> > [self makeKeyWindow];
> > /*
> > * OPENSTEP makes a window the main window when it makes it the key
> > window.
> > * So we do the same (though the documentation doesn't mention it).
> > */
> > [self makeMainWindow];
> > }
> >
> > Would it make sense to use -orderFrontRegardless instead of -orderFront: ?
> > By looking at the source code, it may solve the problem.
> > I haven't test it, though.
> >
>
> I thought about that as well, but somebody added the following code into
> orderWindow:relativeTo:
>
> /* The backend will keep us below the current key window unless we
> force it not too */
> if ((otherWin == 0
> || otherWin == [[NSApp keyWindow] windowNumber]
> || otherWin == [[NSApp mainWindow] windowNumber])
> && [NSApp isActive])
> otherWin = -1;
>
> Now the difference between orderFront: and orderFrontRegardless: is that
> one uses 0 and the other -1 for its relative window. In many cases the
> above code will level out this difference and I really don't see, why we
> want that to happen. But in our specific case (application is not
> active, user clicks on a window and the window gets ordered front and
> made key, then the application becomes active) it could still make a
> difference.
>
> Please give this change a try and if it resolves your problem I will add
> it to SVN.
>
The change you mentioned does not work,
and it does not make sense to me.
It is only effective when [NSApp isActive] == YES,
which is not the case we are discussing.
I tried the -orderFrontRegardless and it works (see patch below).
In -makeKeyAndOrderFront:,
the window does not care about other key window.
It is going to be the key window anyway.
So I think it is reasonable to use -orderFrontRegardless in this case.
Regards
Yen-Ju
Index: Source/NSWindow.m
===================================================================
--- Source/NSWindow.m (revision 25470)
+++ Source/NSWindow.m (working copy)
@@ -1498,7 +1498,7 @@
- (void) makeKeyAndOrderFront: (id)sender
{
- [self orderFront: sender];
+ [self orderFrontRegardless];
[self makeKeyWindow];
/*
* OPENSTEP makes a window the main window when it makes it the key window.