Re: focus problem

[Fred Kiefer]

Andreas Höschler wrote:
> Hi all,
> 
> I am investigating the - well known - focus problem and am currently in
> 
> NSApplication.m
> =============
> 
> - (void)mouseDown:(NSEvent*)theEvent
> {
>   if ([theEvent clickCount] >= 2)
>     {
>       /* if not hidden raise windows which are possibly obscured. */
> 
>       if ([NSApp isHidden] == NO)
>     {
>       NSArray *windows = RETAIN(GSOrderedWindows());
>       NSWindow *aWin;
> 
>     ...
> 
>           [NSApp unhide: self]; // <------ shouldn't we activate the app
> here?
> 
>       if ([NSApp isActive] == YES)
>         {
>           if ([NSApp keyWindow] != nil)
>         {
>           [[NSApp keyWindow] orderFront: self];
>         }
>           else if ([NSApp mainWindow] != nil)
>         {
>           [[NSApp mainWindow] makeKeyAndOrderFront: self];
>         }
>           else
>         {
>           /* We need give input focus to some window otherwise we'll
>              never get keyboard events. FIXME: doesn't work. */
>           NSWindow *menu_window = [[NSApp mainMenu] window];
>           NSDebugLLog(@"Focus", @"No key on activation - make menu key");
>           NSLog(@"Focus No key on activation - make menu key %@",
> menu_window);
>           [GSServerForWindow(menu_window) setinputfocus:[menu_window
> windowNumber]];
>         }
>         }
>     
>           RELEASE(windows);
>     }
> 
> Shouldn't we activate the app in all cases if the user doubleclicked the
> app icon? If the application has no open windows, the "We need give
> input focus to some window" part is called and it indeed does not work.
> Key events go to the previously active application though the etoile
> menu already shows the correct - just activated - application. Has
> anybody a good idea how to fix that?
> 

I don't quit understand what you are suggesting here. And the original
code here is not to clear by itself.
I think we may have four cases that this code needs to handle: The
application may be active or not and it may be hidden or not.
In all these four cases there may be a suitable window to make key or not.
In the end we expect that the application is activated unhidden and a
suitable window made key.
We already have a call to unhide: here, this will activate the
application if it isn't active already.

case active + unhidden
unhide: gets called, but nothing happens

case active + hidden
windows get reorder, unhide: gets called, hidden windows get displayed

case inactive + unhidden
unhide gets called, this calls activateIgnoringOtherApps:

case inactive + hidden
windows get reorder, unhide: gets called, hidden windows get displayed,
activateIgnoringOtherApps: gets called

As far as I can see this is OK. It may not be the best way to structure
the code. I think it would be better to put the windows reordering into
unhideWithoutActivation. But which part of this is causing you problems.

Or is it only the issue, when there is no suitable key window? This
really is a problem, but moving or changing code in mouseEvent: wont
solve it.

Fred