FROM : Quincey Morris
DATE : Mon Jun 23 20:06:54 2008
On Jun 23, 2008, at 09:01, Georg Seifert wrote:
> I do a graphic program and most users are used to the behavior of
> adobe apps. There palettes have a close button but do not react on
> command-w.
>
> For me it is more logical that all windows with a "big" title bar
> react on keyboard close commands and all panels with a "small" title
> bar not.
Well, keep in mind that there's a lot of criticism of Adobe for going
their own way with interface design. But if you want to tie your canoe
to Adobe's ship ... :)
A change of your terms of reference might solve things without a lot
of hacky code.
You have a program that has palettes (not "windows", from the user
perspective) that the user wants to be able to hide or show (not
"close" or "open", from the user perspective).
So, use a NSPanel, but turn off all three of the close/maximize/
minimize buttons in IB so that they don't even show up in the title
bar. On a suitable menu (e.g. View), add a Hide/Show XXX item for each
of your different palettes, connected to a ToggleXXXVisible action for
each palette.
If it turns out that disabling the standard close button *doesn't*
prevent the palettes from responding to the standard performClose:
action (which is sent by File | Close and Command-W), implement an
override for each palette's window controller that forwards the action
to the current main window (if there is one) or discards it (if there
is no main window).
Seems to me that's simple to implement and clear in the interface, and
not in conflict with standard behavior in any reprehensible way.
DATE : Mon Jun 23 20:06:54 2008
On Jun 23, 2008, at 09:01, Georg Seifert wrote:
> I do a graphic program and most users are used to the behavior of
> adobe apps. There palettes have a close button but do not react on
> command-w.
>
> For me it is more logical that all windows with a "big" title bar
> react on keyboard close commands and all panels with a "small" title
> bar not.
Well, keep in mind that there's a lot of criticism of Adobe for going
their own way with interface design. But if you want to tie your canoe
to Adobe's ship ... :)
A change of your terms of reference might solve things without a lot
of hacky code.
You have a program that has palettes (not "windows", from the user
perspective) that the user wants to be able to hide or show (not
"close" or "open", from the user perspective).
So, use a NSPanel, but turn off all three of the close/maximize/
minimize buttons in IB so that they don't even show up in the title
bar. On a suitable menu (e.g. View), add a Hide/Show XXX item for each
of your different palettes, connected to a ToggleXXXVisible action for
each palette.
If it turns out that disabling the standard close button *doesn't*
prevent the palettes from responding to the standard performClose:
action (which is sent by File | Close and Command-W), implement an
override for each palette's window controller that forwards the action
to the current main window (if there is one) or discards it (if there
is no main window).
Seems to me that's simple to implement and clear in the interface, and
not in conflict with standard behavior in any reprehensible way.






Cocoa mail archive

