Re: Fix for window flicks when getting focused

[Fred Kiefer]

Yen-Ju Chen wrote:
> 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.

Sorry, the replacing of orderFront: by orderFrontRegardless: was what I
was talking about :-)
What I was reasoning was, in which cases this change would make a
difference (and when not). But now that you found it working this little
misunderstanding isn't important any more.

Fred