inappropriate tool palette activation problem

  • I have a problem, and it might very well be basic, but I'm hoping it
    rings a bell, and some kind soul will help me.

    I've looked around in Google, and through mail list archives, but
    some topics, due to the generic nature of the words appropriate for
    describing them, are hard to research.

    The problem is that my application's tool palettes seem to misbehave
    quite a bit, with respect to window activation.

    Generally, all windows - *including tool palettes* as well as main
    document windows - require a click to activate them.  This, in spite
    of the documentation stating that utility panels stay in their own
    layer.

    Tool palettes don't seem very common on OS X, but those I've examined
    don't have this problem.

    I've tried tinkering with most of the obvious window attributes
    (floating aka "utility," non-activating, and other doubtlessly
    irrelevant attributes like "works when modal" and "becomes key only
    if needed") in IB and programmatically, and nothing I've done so far
    appears to affect this behavior.

    I haven't thought of anything else that would be causing this, except
    perhaps something I'm doing actively, that's bad, perhaps in misusing
    some part of the frameworks.

    It might be coincidental, but I also find that I also have some odd
    behavior related to didBecomeMain and didResignMain notifications
    (the only way I've discovered to receive window activation events -
    amazing!).  I find that no matter what I do, all document windows
    seem to report being activated and deactivated, whenever just one's
    state changes.  This certainly isn't what I want, and seems like it
    might somehow be related - but perhaps not.

    Any suggestions (about either problem)?

    -jar
  • On Oct 16, 2007, at 10:50 AM, John Richetta wrote:

    > Generally, all windows - *including tool palettes* as well as main
    > document windows - require a click to activate them.
    [..]
    > I've tried tinkering with most of the obvious window attributes
    > (floating aka "utility," non-activating, and other doubtlessly
    > irrelevant attributes like "works when modal" and "becomes key only
    > if needed") in IB and programmatically, and nothing I've done so
    > far appears to affect this behavior.

    I think part of the problem might be the terminology.

    Rather than focusing on the label of "active," can you describe what
    sort of behavior you're looking for from the window? There are plenty
    of inspectors in Mac apps, which are essentially just "panel"
    windows. How does that differ from what you need?

    In general, most of the standard windows behaviors that users expect
    are fairly easily to implement. If you find one behavior is
    particularly hard to implement, it may be that the behavior is not
    one Mac users are expecting.

    Best Regards,

        - Scott
  • I said:

    > The problem is that my application's tool palettes seem to misbehave
    > quite a bit, with respect to window activation.
    >
    > Generally, all windows - *including tool palettes* as well as main
    > document windows - require a click to activate them.  This, in spite
    > of the documentation stating that utility panels stay in their own
    > layer.

    On Tue, 16 Oct 2007 23:30:11 -0700, Scott Stevenson said:
    > I think part of the problem might be the terminology.
    >
    > Rather than focusing on the label of "active," can you describe what
    > sort of behavior you're looking for from the window? There are
    > plenty of inspectors in Mac apps, which are essentially just "panel"
    > windows. How does that differ from what you need?

    Sorry: I tried to keep it short, and omitted important detail.

    The meaning of the term "active" is important in my case, and applied
    to a window means: frontmost in its layer, responding to events, and
    having a highlighted title bar.

    Here is a sequence that should illustrate the problem (assuming an
    already-open and active document window):

        1. click in the active document, selecting object A for editing;
    object A selects, as expected

        2. click in tool palette window in a text field or slider, to
    modify object A; instead of tool palette widget responding, tool
    palette window activates, and main document deactivates; click is
    consumed simply in activating the tool palette window

        3. click in tool palette window again, to modify object A using widget

        4. click back in document window, on object B, to select object;
    document window *reactivates* and tool window deactivates; object B
    does not yet get selected, because click is consumed simply in
    activating the window

        5. click on object B, for editing; object B selects correctly

        6. click in a tool palette window widget, to modify part B; again,
    main document window deactivates, and tool palette window activates;
    widget does not yet respond, because click is again consumed simply
    in activating the toll palette window

        7. click in tool palette window again, to modify object B

    Steps 2, 4, and 6 illustrate the incorrect behavior: a click should
    not be required to activate either the tool palette or main document
    windows.  The main document window should stay active (until another
    different document window becomes active), and the tool palette
    window should always be active.  That a click is required implies
    that the tool palette and document window reside in the same layers,
    when they should remain in separate layers.

    The extra click required to activate the windows is extremely
    annoying, UI-wise, and defeats the value of an inspector.  And it's
    completely different from the behavior exhibited by all normal tool
    palettes, inspectors, font panels, etc.

    Thanks for reading, and any further suggestions.

    -jar
  • On Oct 17, 2007, at 12:45 AM, John Richetta wrote:

    > 1. click in the active document, selecting object A for editing;
    > object A selects, as expected
    >
    > 2. click in tool palette window in a text field or slider, to
    > modify object A; instead of tool palette widget responding, tool
    > palette window activates, and main document deactivates; click is
    > consumed simply in activating the tool palette window

    Something's busted. Click-through should be on by default in Cocoa
    controllers, panel or not:

    "An item that provides click-through is one that a user can activate
    on an inactive window with one click, instead of clicking first to
    make the window active and then clicking the item"

    [...] Cocoa: Click-through is on by default. You must explicitly
    disable click-through for specific controls. Do not assume that the
    default behavior is the correct behavior. Make sure to apply the
    above guidelines.

    <http://developer.apple.com/documentation/UserExperience/Conceptual/
    OSXHIGuidelines/XHIGWindows/chapter_17_section_4.html
    >

    You should be able to recreate this in any two-window Cocoa app. Are
    you implementing custom controls/windows which circumvent normal
    Cocoa standards?

        - Scott
  • On Wed, 17 Oct 2007 01:36:48 -0700 , Scott Stevenson asked:

    > Are you implementing custom controls/windows which circumvent normal
    > Cocoa standards?

    No.  But this morning, the light bulb finally turned on.  After
    correcting a custom content view derived from NSOpenGLView (which
    occupied most of the window content region) that failed to override
    acceptsFirstMouse: to return YES, and after addressing a couple other
    minor matters, the "extra activation click" problems seem entirely
    resolved.

    I'm still a bit puzzled that title bars activate and deactivate when
    clicking back and forth between floating windows and document
    windows, whereas this doesn't appear to happen in other apps.  I
    would have expected clicks in windows in one layer (such as the
    floating window layer) to have no impact on window activation or
    highlighting in another layer (the one containing document windows,
    for example).

    I also don't know why I'm receiving seemingly incorrect, or at least
    very unnecessary, extra window activation and deactivation
    notifications, via didBecomeMain and didResignMain, but this is a
    separate topic, and I can probably get to the bottom of these issues.

    Anyway, thanks for the fruitful suggestion.

    -jar
  • Am 18.10.2007 um 02:53 schrieb John Richetta:
    > I also don't know why I'm receiving seemingly incorrect, or at
    > least very unnecessary, extra window activation and deactivation
    > notifications, via didBecomeMain and didResignMain, but this is a
    > separate topic, and I can probably get to the bottom of these issues.

      The apps that don't have this are probably Carbon, are they? Or
    maybe they're just using non-activating panels. The new behaviour has
    two activation states. One is the "main" window, which has the
    gradient, and the other is a more subtle "frontmost window in its
    layer" hightlight.

      This distinction is actually very useful, in particular for
    controlling an app via keyboard. You can use Cmd-~ (or Cmd-< on some
    localized keyboards) to make whatever window you want main, floater
    or document. And then the "Zoom" and "Minimize" menu items will apply
    to that window. Same goes for the "Close" menu item. Before Apple
    introduced this behaviour, it was impossible to perform the actions
    of the window widgets under keyboard control for some windows.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
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