removing minimize and zoom widgets from tool palette title bar

  • On this page:

    <http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGui
    delines/XHIGWindows/chapter_17_section_3.html
    >

    In the section on Title Bar Buttons, Apple says:

    "If buttons are not active, they should at least all be present in an
    inactive state. The exception is utility windows, where it is
    acceptable to display only one button, the close button."

    Has anyone gotten this latter option to work?  I have a narrow tool
    palette, which for organization reasons cannot readily be made wider,
    and with all the widgets in the title bar, it's 1. ugly/cluttered,
    and 2. hard to drag the window.  I'd like to remove - not just
    disable - the minimize and zoom widgets.

    I've tried programmatically creating a window with only a title bar
    and close box, and that still creates all three standard widgets
    (close, minimize, and zoom).  Does anyone know how to remove all but
    the close box?

    Thanks, -jar
  • On 19 Oct 2007, at 7:48 PM, John Richetta wrote:

    > "If buttons are not active, they should at least all be present in
    > an inactive state. The exception is utility windows, where it is
    > acceptable to display only one button, the close button."
    >
    > Has anyone gotten this latter option to work?  ...  I'd like to
    > remove - not just disable - the minimize and zoom widgets.
    >
    > I've tried programmatically creating a window with only a title bar
    > and close box, and that still creates all three standard widgets
    > (close, minimize, and zoom).  Does anyone know how to remove all but
    > the close box?

    Googling "standardWindowButton hide", I get <http://lists.apple.com/archives/Cocoa-dev/2006/Mar/msg01873.html>:

    > It's pretty simple. Once you have the window button in question, you
    > should be able to just send it a -removeFromSuperview: message. You
    > may also need to update the window's style mask for the layout to be
    > done correctly.

    I haven't tested this, but the poster, John C. Randolph, is extremely
    reliable.

    — F
  • On Oct 19, 2007, at 6:05 PM, Fritz Anderson wrote:

    >> It's pretty simple. Once you have the window button in question,
    >> you should be able to just send it a -removeFromSuperview:
    >> message. You may also need to update the window's style mask for
    >> the layout to be done correctly.
    >
    > I haven't tested this, but the poster, John C. Randolph, is
    > extremely reliable.

    However, upon removal, the title bar drag region is not properly
    updated, so you are left with some "dead spots".
    --
    Shaun Wexler
    MacFOH
    http://www.macfoh.com
  • At 7:15 PM -0700 10/19/07, Shaun Wexler wrote:
    > On Oct 19, 2007, at 6:05 PM, Fritz Anderson wrote:
    >
    >>> It's pretty simple. Once you have the window
    >>> button in question, you should be able to just
    >>> send it a -removeFromSuperview: message. You
    >>> may also need to update the window's style
    >>> mask for the layout to be done correctly.
    >>
    >> I haven't tested this, but the poster, John C.
    >> Randolph, is extremely reliable.
    >
    > However, upon removal, the title bar drag region
    > is not properly updated, so you are left with
    > some "dead spots".

    The problem noted by Shaun is unfortunate.  I
    can't actually reproduce it, as when I send the
    widgets a removeFromSuperview message, execution
    halts soon after with an exception (unrecognized
    selector during forwarding).

    I've found what seems like a reasonable
    work-around: set the origin of the widgets you'd
    like to hide to something way out of view, like
    (-500, -500).  Doing this correctly updates the
    drag region.  Note that the more obvious and
    clean approach of hiding the controls has the
    problem Shaun mentioned (drag region still has
    holes in it).

    There are two issues with this hack:

    1. The close box still highlights when you move
    the mouse over the region where the minimize and
    zoom widgets normally are, when visible (but
    disabled).  This matches "normal" behavior, but
    looks weird since there is nothing underneath the
    mouse (and so the highlighting tends to violate
    good UI principles).

    2. If you do anything to the window/panel frame
    after "hiding" the widgets - voilá! - they will
    become visible again (so set the window frame
    first, if possible).  Curious that the system
    does this, no?

    Of course, the usual caveat applies: this is
    probably not supported by Apple, or guaranteed to
    work in the future.

    -jar

    P.S. - I guess if we could remove the widgets
    from their superviews successfully, after moving
    them out of view, this would probably fix problem
    #2?
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today