Re: [bug #4410] NSDocumentController's -application:openFile: can't work

[Jeff Teunissen]

nobody@savannah.gnu.org wrote:
> 
> =================== BUG #4410: LATEST MODIFICATIONS ==================
> http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4410&group_id=99
> 
> Changes by: Enrico Sersale <enrico@dtedu.net>
> Date: Tue 07/22/2003 at 14:54 (Europe/Bucharest)
> 
> ------------------ Additional Follow-up Comments ----------------------------
> A similar problem exists in Gorm. This patch fixes it.
> 
> --- Gorm.m      2003-07-22 14:50:26.000000000 +0300
> +++ Gorm.m_copy 2003-07-22 14:50:47.000000000 +0300
> @@ -1242,7 +1242,8 @@
>      }
>    else
>      {
> -      [[doc window] makeKeyAndOrderFront: self];
> +      [[doc window] orderFrontRegardless];
> +      [[doc window] makeKeyWindow];
>      }
> 
>    return (doc != nil);
> 
> =================== BUG #4410: FULL BUG SNAPSHOT ===================
> 
> Submitted by: esersale                Project: GNUstep
> Submitted on: Tue 07/22/2003 at 13:23
> Category:  Gui/AppKit                 Severity:  5 - Major
> Bug Group:  None                      Resolution:  None
> Assigned to:  None                    Status:  Open
> 
> Summary:  NSDocumentController's -application:openFile: can't work
> 
> Original Submission:  If you take a not document-based application, for 
> example ImageViewer, you will see that -application:openFile: is implemented 
> in the app controller, in this case "AppController.m".
> When the app is not active and an other app or tool calls its 
> -application:openFile: through DO, ImageViewer creates a new window and shows 
> it:
>  [window orderFrontRegardless];
>  [window makeKeyWindow];
>  [window display];
> 
> this doesn't work for document-based applications, because 
> -application:openFile, implemented in NSDocumentController, calls 
> -showWindow: in NSWindowController. And NSWindowController's -showWindow: 
> calls -makeKeyAndOrderFront: for its window.
> But NSWindow's -makeKeyAndOrderFront: returns without doing anything if, as 
> in this case, the app is not active. And the new window is newer shown.
> 
> Follow-up Comments
> *******************
> 
> -------------------------------------------------------
> Date: Tue 07/22/2003 at 14:54       By: esersale
> A similar problem exists in Gorm. This patch fixes it.

The problem is not in the app. The problem is in NSWindow --
-makeKeyAndOrderFront: should order front and make the window visible,
even unhiding the app if necessary.

This has been verified with OPENSTEP 4.2; -makeKeyAndOrderFront: always
orders front the window, even if the app is hidden. If the app is hidden,
it will unhide (but not, generally, activate -- apps can place windows on
the screen without being active).

I locally patched GNUstep some time ago to fix this (rather egregious)
problem, and had a rather long discussion on the precise behavior that
should happen.

A related problem is that apps should not start hidden -- Hiding an app
before it has finished launching should not cause anything to be placed on
the screen unless it orders a window to the front.

How do I know this is a difference? On OS, app delegates don't receive
-application*Unhide: messages during launch, while they do on GNUstep.
This interferes with the standard "auto-hide on autolaunch" preference for
certain apps.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/