Re: Clicking Dock Icon creates a new window
Re: Clicking Dock Icon creates a new window
- Subject: Re: Clicking Dock Icon creates a new window
- From: "Louis C. Sacha" <email@hidden>
- Date: Sat, 13 Mar 2004 21:51:06 -0800
Hello...
The default (normal) behavior of NSApplication for reactivation of
the app should be basically identical to what is described in the
HIG, so if it is not working that way, then there is something else
going on with your program.
You might want to take a look at the documentation for the
NSApplication delegate method
applicationShouldHandleReopen:hasVisibleWindows: which describes
exactly what will happen when your application is reactivated using
the dock.
It mentions that NSApplication checks for visible NSWindows, but
specifically excludes NSPanels. If you are using an NSPanel as the
basis for your document window (or a subclass of NSPanel, etc), then
that might be the reason why this particular application is having
the problem and your previous applications worked correctly.
If that is the case, and your document windows need to be NSPanels
for some reason, then all you would have to do is implement the
reactivate application delegate method, doing something similar to
the following:
/* typed in email, etc, etc, etc... */
/* in class that serves as the app delegate */
- (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication
hasVisibleWindows:(BOOL)flag
{
if (!hasVisibleWindows)
{
/* the following call should return nil if no
documents are open, or all open document windows are minimized */
NSDocument *currentDoc = [[NSDocumentController
sharedDocumentController] currentDocument];
if (currentDoc) {return FALSE;} /* there is an open,
visible (non-minimized), document */
}
return TRUE;
}
Of course, it's possible that [[NSDocumentController
sharedDocumentController] currentDocument] won't work correctly in
your case (for the same reasons why the normal NSApp behavior is
breaking), although it should. In that case you would need to figure
out some other check, which could use the document controller's
documents array to check to see if there are open documents, although
you would need to figure out a way to check for the case where there
are documents open but the windows are minimized
- (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication
hasVisibleWindows:(BOOL)flag
{
if (!hasVisibleWindows)
{
unsigned currentDocs = [[[NSDocumentController
sharedDocumentController] documents] count];
if (currentDocs != 0) /* there are open documents,
need to check if they are all minimized */
{
/* ... check if all open document windows are
minimized ... */
}
}
return TRUE;
}
If your document windows are not derived from NSPanel and something
else is causing this problem, then the above app delegate method
solution would still probably work, but it might be a good idea to
figure out what the root cause of this issue is for your app anyway,
since it could start causing problems in other parts of the
application as well. If the hasVisibleWindows: flag passed to the
app delegate method is TRUE and the application is still opening an
untitled document on reactivate, then you could eliminate that check
from the code for the delegate method, although there would
definitely be something very wrong somewhere else if that were the
case.
Hope that helps,
Louis
Addendum: I realize that malcom list-mom'ed the whole good HIG / evil
HIG portion of this topic, but I just wanted to point out that the
HIG serves more than one purpose. One is to describe what Apple feels
is the best way to design the interface of an application, to try to
help developers make their applications easy to use (and whether
Apple's ideas are right or wrong depends on the user). Another is to
foster consistency between applications, so that most applications
work as similarly as possible and once you understand how one
application works/reacts you can expect other applications to do the
same sort of thing.
It's for the second purpose, whether or not you agree with a
particular part of the HIG, that it is still a good idea to try to
follow the HIG as closely as possible for your application. Remember,
though, they are guidelines, so if something doesn't make sense for
your application, then you have to decide if the case you are working
with is an exception to the general rule.
It's always a good idea to make your application as user configurable
as possible, because while Apple tries to make the guidelines reflect
the best solution most of the time, there will always be situations
where it ends up being the opposite of the way some people would like
things to work. (I don't want to start an entirely different
off-topic discussion, but another example of a situation that is very
user subjective and very application specific is the "should all of
an applications windows be brought to the front when I click on one
of it's windows" topic...)
So, if you can, design your application so that it can be used either
way, and allow the user to choose the best way for them. The
guidelines in the HIG can help you to choose the best default
behavior, and users who prefer having things work a different way
will be able to change a preference and have things work the way they
want.
To make this part a bit more on-topic and conceptual, this is what I
usually do in terms of the "open a new document on
launch/reactivation" question in most of my applications (even though
most of the time the only person using them is me, or they were
written for a specific person doing a specific task). I usually have
a preference available in the application settings (for example,
stored in the app's user defaults with the key
@"PrefAppLaunchActionKey") that can be set for the launch/activation
action when there isn't an open document, and the
applicationShouldOpenUntitledFile: application delegate method checks
it and acts accordingly. That way the user can choose between having
an untitled document created, having the Open dialog brought up, or
having the application do nothing. The default setting is to open an
untitled document, even though I usually end up setting the
preference to "Wait for further instructions" (launchAction==2 in the
example code below).
- (BOOL)applicationShouldOpenUntitledFile:(NSApplication *)sender
{
NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
int launchAction = [defaults integerForKey:@"PrefAppLaunchActionKey"];
if (launchAction==0) {return TRUE;} /* return TRUE, default
behavior or user wants to have new document created */
if (launchAction==1) {[[NSDocumentController
sharedDocumentController] openDocument:self];} /* run open dialog
(then return FALSE for create new document) */
/* if launchAction==2, wait and do nothing until user does
something (return FALSE for create new document) */
return FALSE;
}
In my applications where the idea of a new document doesn't really
make sense (for example, applications that are more drag and drop
style converters that convert a document of one type to another),
there is no option for creating a new document so the default
behavior is to bring up the open dialog if the app was opened without
a source file, and the "Wait for further instructions" option is the
other available setting in the preferences.
Anyway, comments on this part (the HIG issues) might be better
off-list, unless they are on the code, etc... I will keep the rest of
my comments off-list as well.
> I know this probably isn't what you want to hear, but doing so would
violate this section of the Apple UI guidelines:
http://developer.apple.com/documentation/UserExperience/Conceptual/
OSXHIGuidelines/XHIGHowEnvAffects/chapter_7_section_3.html#//apple_ref/
> doc/uid/20000957-CH294-CHDICFGC
>
...
This behavior is exactly what I would like to happen except that that is
actually happening is that a new untitled window opens even if there is
already a document window open. Other document based applications I have
created do not do this and I cannot figure out why this one behaves
incorrectly.
Bruce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.