Re: Garbage collection and about windows
Re: Garbage collection and about windows
- Subject: Re: Garbage collection and about windows
- From: Ben Haller <email@hidden>
- Date: Wed, 11 Nov 2009 18:16:11 -0500
On 8-Sep-09, at 11:19 PM, Bill Bumgarner wrote:
On Sep 8, 2009, at 6:45 PM, Ben Haller wrote:
My idea — perhaps being too clever for my own good — was that as
long as the about window was open, the window would be referenced
by the window list, and so the window and its controller would
stick around. Choosing the "About" menu item a second time would
therefore just call showWindow: on the controller again, ordering
the window to the front if it had gotten buried. As soon as the
window was closed, I figured it and its controller would be garbage
collected, and the weak reference to it in the app delegate would
zero out, so then choosing "About" would create a new controller
and reload the nib.
Panels -- NSPanel subclasses -- don't show up in the window list
(and aren't visible in the Windows menu on the menu bar, either)
and, thus, you'll see the behavior you do.
Unless your about panel is ridiculously large & complex, make the
aboutController __strong and forget about it. It'll only take up
memory if a user brings it up -- which will be rare -- and, once
that happens, the memory is minimal.
This bit me again today; I made a new window in my app, chose to
make it a panel because I wanted the "escape closes the window"
behavior, and then discovered that it would get collected by GC even
though it was open and visible to the user. I have to say this seems
exceedingly strange to me. Why would a window that is visible to the
user be considered garbage? Is there a justification for this, or
should I file it as a bug?
This policy seems to imply that windows can live on their own,
without a reference to them from the outside world (because the window
list references them), but panels cannot; a panel has to be strong-
referenced by somebody. Somebody has to *own* it. I don't really see
the logic there. An inspector, for example, would logically be a
panel, and could quite easily be implemented in such a way that the
rest of the app wouldn't know that it was being observed by the
inspector, and wouldn't know the inspector existed. If it was a
singleton inspector, then I guess you'd have a global somewhere
pointing to the singleton reference, which would keep it around (and
that's the fix that Bill suggested to my About panel conundrum); but
if your app allowed the user to open any number of inspectors (like
Get Info panels in the Finder, say), then it seems like there would be
no logical reason for a strong reference to exist to those inspectors
anywhere else in the app. And so they would get collected. And so
you'd have to devise some artificial mechanism to prevent that, like
an NSArray of open Get Info panels kept by the application delegate
that was there for the sole purpose of preventing them from getting
collected.
This just seems wrong to me. The fact that the user's eyeballs can
*see* something seems like it ought to constitute a strong reference
in and of itself; no visible window ought to be collected just because
there is no other reference to it. This seems similar to the reason
why entire applications don't get collected -- the rest of the OS
doesn't necessarily know/care that a given app is running, and all
external references to running apps could (in a conceptual sense) be
weak references, but the fact that the user is *using* the app is a
good reason not to just collect it arbitrarily. The user may even
have their cursor over it; they may even be interacting with it. When
you collect it, you're pulling the rug out from under the user; the
collection would feel like a crash. No? Similarly with my window;
the window is there, then it isn't, and the user feels like some sort
of "sub-crash" has happened just to that window. I can't think of a
case where this is the right behavior.
It occurs to me that my woes may be due to misusing the framework.
Specifically, I have a controller object for the window, but that
controller is not a subclass of NSWindowController. If I crossed over
to the NSWindowController paradigm, would that help with this
problem? My window does not represent a document, which is why I
chose not to use NSWindowController; that class seems to mostly be
associated with the NSDocument world, and I just didn't see any
functionality that I would get from using it. But perhaps I need to
reconsider that choice?
Ben Haller
Stick Software
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden