> On 21 Nov 2009, at 10:09, Michael Davey wrote: > My application only has one window, so this dicussion is a bit moot, but I > see your point. > >> What this sounds like is that the application hides itself when one of its >> windows is miniaturized. ([NSApp hide: nil] when a window's delegate >> receives windowDidMiniaturize:) > > This does indeed sound like what I want to do - I guess what I need to know > now is how to set a delegate for a window and how to capture events (will try > looking for that myself first)
Apps that have one window either stay open or quit themselves when that window is closed. Printers are an example of the former, and System Preferences is an example of the latter. > My application is a long running, almost server like application, and the > window only really serves the purpose of starting/stopping certain services. > Once they are running, having the window visible may actually be a problem as > services could be stopped accidentally. You should consider splitting your server-esque functionality off into a separate agent, and offering your user interface in the form of a normal application, an LSUIElement with a status item, or a System Preference pane. There are certain predefined interactions: 1. A "control panel" app can be launched and quit at whim without affecting the background task. The user would launch your application to start or stop the services, and most likely quit it immediately after they made their change. If you can only ever have one window open (ex., System Preferences), closing it quits the application. If you can have multiple windows open (ex., Server Admin), the application behaves like a document-based application in that closing all open windows does not quit the application, and clicking the application's dock icon when it is not the active application and has no windows open causes a new window to open. Do not use the second model to present multiple windows on the same configuration to the user; only use it if each window controls a different set of services (for example, "services running on my computer" vs. "services running on foo.example.com"). 2. An LSUIElement which has no dock icon or menu bar of its own, but instead is interacted with only through a status item (the black-and-white icons in the upper right of the screen). This LSUIElement would preferably start at login and stay there throughout the user's session; it should be far enough out of the way that it doesn't bother them. You can combine this model with the control panel or System Preferences pane model, much like how the Airport menu has an item to open Network Preferences. 3. A standard System Preference pane. This app behaves correctly according to "control panel" app model, except you don't have to do any of that work. A System Preferences pane is more appropriate if the user changes your settings infrequently (ex., a web server running on a dedicated web host). A "control panel" app is more appropriate if the user starts and stops your service relatively frequently (ex., a web server used as a development environment by a programmer). A little bit more information about what your services do would be helpful in pinpointing the best (most consistent and Mac-like) interaction model. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
