Views & Staying On Top / Accessing Across Apps

  • I've been rooting through documentation as part of learning how to
    program for OS X, but I still have much to get used to.

    Out of interest, do NSView or any other class that would be considered
    'visual' support any kind of stay-on-top semantics (or slightly less
    specifically, stay-in-front-of-another-view semantics) without actually
    being a subview? Docking (without specific support from the owning
    application to implement the feature - I'm talking about built into the
    framework)?

    Another view / window question: Is it possible to access the views /
    windows of another application, with the intention of moving / sizing
    them (and, if a stay-on-top / -in-front flag is supported, setting that)?

    (If you're wondering, I'm thinking along the lines of a utility that
    would add sticky / docking facilities to the views / windows of an app
    that otherwise doesn't support it.)

    Thanks in advance.

    --
    Jason Teagle
  • On May 18, 2012, at 4:10 AM, Jason Teagle wrote:

    > Out of interest, do NSView or any other class that would be considered 'visual' support any kind of stay-on-top semantics (or slightly less specifically, stay-in-front-of-another-view semantics) without actually being a subview? Docking (without specific support from the owning application to implement the feature - I'm talking about built into the framework)?

    A view is always clipped to its parent, so such a view would have to be a direct child of the window's contentView, and would have to be ordered in front of its siblings. There might or might not be issues with the sibling views redrawing correctly.

    Another way to accomplish this is by adding a "child window", which is a window that follows its parent around and always stays directly in front of it (this is how things like pop-up menus, tooltips, sheets and drawers are implemented.) If you don't give it a window frame, it can have arbitrary shape and content.

    > Another view / window question: Is it possible to access the views / windows of another application, with the intention of moving / sizing them (and, if a stay-on-top / -in-front flag is supported, setting that)?

    Well, sort of. There is an Accessibility API that (if the user enables this feature) can let your app look at the UI elements of other apps and manipulate them to some degree. It doesn't let you put arbitrary stuff into another app (for one thing, that would require injecting your code into its process.)

    > (If you're wondering, I'm thinking along the lines of a utility that would add sticky / docking facilities to the views / windows of an app that otherwise doesn't support it.)

    I'm doubtful this can be done; or at least, if it can, it would require some very tricky hacking (i.e. injecting code into other apps.) Definitely not a newbie project, I'm afraid.

    —Jens
  • > A view is always clipped to its parent, so such a view would have to be
    > a direct child of the window's contentView, and would have to be ordered
    > in front of its siblings. There might or might not be issues with the
    > sibling views redrawing correctly.

    Having learned a bit more about how the visual classes fit together, I
    realise now that NSView was the wrong class to ask about; I was thinking
    of NSWindow. I realise now that NSView is fairly analogous to JPanel in
    Java, and thus is not likely to be a top-level window within an app.

    > I'm doubtful this can be done; or at least, if it can, it would require
    > some very tricky hacking (i.e. injecting code into other apps.)
    > Definitely not a newbie project, I'm afraid.

    Fair enough. I found some material after I asked the question that
    hinted at an API for getting *some* sort of information about other
    windows, but it didn't look promising - very basic stuff. I guess there
    are also security concerns about cross-app access.

    It was just an idea that floated across my mind (after experiencing some
    'unhelpful' window issues in Xcode's environment) that would have helped
    me - but I have too much still to learn to tackle something that bold,
    so consider that idea shelved indefinitely.

    Thanks for the reply.

    --
    Jason Teagle
  • On 19 May 2012, at 2:29 PM, Jason Teagle wrote:

    > I realise now that NSView is fairly analogous to JPanel in Java, and thus is not likely to be a top-level window within an app.

    Conceptual note: The Xerox Star, Apple Lisa, and Apple Macintosh had windows: Independent, top-level containers that can be moved independently and freely positioned, even over each other.

    Overlapping, independently-positionable windows, with mid-'80s technology, involved either a superfast (for the time) central processor (Xerox), or some very clever programming (Apple). It was a hard problem.

    Microsoft solved the problem by declaring any _non_-overlapping rectangle tiled on the screen to be a "window." QED. It eventually got z-ordered clipping down, and modern Windows permits objects to be moved freely, but that's not how it started. As I understand it, any discrete thing on the screen is still called a "window."

    In Mac OS, views are _never_ windows, nor windows views. (And screens aren't windows, and screen spaces aren't screens.) Subclasses of NSViews are interesting because they alone can draw, and respond to events, but they can't have any presence on the screen, or role in event handling, without an enclosing NSWindow. NSWindow isn't interesting, because its role in an application is strictly stereotyped; you can have a long career in Mac programming without ever subclassing NSWindow or even thinking much about how it works.

    A view is not merely "[un]likely to be a top-level window," it is impossible. The two can't be interchanged.

    Slow down on your (apparent) assumption that the Windows Way (or even the iOS Way, though it's closer) is how Mac OS works. Go back to the Programmer's Guides, and don't rush in before you have the concepts.

    — F

    --
    Fritz Anderson -- Xcode 4 Unleashed, now in stores -- <http://x4u.manoverboard.org/>
  • My last message descended into advocacy, which isn't productive in a technical forum. If it was a troll, I didn't intend it, and I hope nobody else rises to it.

    I stand by what I said about Cocoa design patterns.

    — F
previous month may 2012 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