Re: UI Question: Hide application window after minimising
Re: UI Question: Hide application window after minimising
- Subject: Re: UI Question: Hide application window after minimising
- From: Kyle Sluder <email@hidden>
- Date: Mon, 23 Nov 2009 20:53:07 -0800
> 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@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