On May 20, 2012, at 22:43 , Graham Cox wrote:
> I'm not sure why Xcode (4) inserts a whole extra level of settings when the
> first level is fine, then doesn't give you a way to remove the second level
> of settings
But it does … the Delete key.
Well, that does it for individual settings. I ca
Heh. I'd file a bug with Apple - this could be an edge case they didn't
consider when they redid grow zones. At the very least they could make sample
code showing what they're doing behind the scenes with the tracking rects.
- Original Message -
From: mlist0...@gmail.com
To: "Lee Ann Ruc
OK, following that line, I checked again. My Target settings were overriding
the Project build settings and there the minimum OS was 10.6. I've changed that
to 10.5 and have asked the user to give it another try. I'm not sure why Xcode
(4) inserts a whole extra level of settings when the first l
On May 20, 2012, at 6:25 PM, Graham Cox wrote:
> A user is reporting an error when dlopen tries to load my plugin in iTunes.
> I've not seen it in my own testing.
>
> 5/20/12 12:29:57 AM iTunes[22591] Error loading :
> dlopen(, 262): no suitable image found. Did find:
> : unknown required loa
(This was originally posted to the Colorsync-dev list about three weeks ago
without any activity on the list, so I'm hoping that someone here can help)
I have an app that is essentially creating a single resultant image from an
amalgamation of multiple source images. Each source image is an NSI
A user is reporting an error when dlopen tries to load my plugin in iTunes.
I've not seen it in my own testing.
5/20/12 12:29:57 AM iTunes[22591] Error loading :
dlopen(, 262): no suitable image found. Did find:
: unknown required load command 0x8022
Googling on this error seems to sugg
On May 20, 2012, at 10:45 AM, Lee Ann Rucker wrote:
> But if you're only updating the cursor, why not try addCursorRect:cursor: ?
> Presumably that's smart enough to know about the grow zone.
The docs note that -addCursorRect:cursor: is "legacy api", supplanted in
Leopard by... tracking rects!
Belt *and* suspenders? ;)
_murat
On May 20, 2012, at 7:43 AM, Quincey Morris wrote:
> On May 20, 2012, at 02:21 , mlist0...@gmail.com wrote:
>
>> Your alternate approach is essentially to give up on tracking areas, no? The
>> tracking area approach has an attractive simplicity, especially once
Sounds like your tracking area overlaps the 3 pixel wide grow zone tracking
area. It's an interesting area - if you do a hitTest as the mouse is entering
the window it won't hit your content in that zone, but it will if you start
from > 3 pixels in and move out.
But if you're only updating the
On May 20, 2012, at 9:02 AM, Ken Thomases wrote:
> On May 20, 2012, at 10:04 AM, Kyle Sluder wrote:
>
>> Have you implemented -updateTrackingAreas?
>
> Or you can try specifying NSTrackingInVisibleRect to take care of much tedium
> for you.
Nope, didn't help either.
_murat
__
On May 20, 2012, at 8:04 AM, Kyle Sluder wrote:
> Have you implemented -updateTrackingAreas?
Implementing it did not help. Not a surprise since my view doesn't change
geometry.
_murat
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do
On May 20, 2012, at 10:04 AM, Kyle Sluder wrote:
> On May 19, 2012, at 10:10 PM, "mlist0...@gmail.com"
> wrote:
>
>> I have a view for which I am adding a tracking area so that I can update the
>> cursor. The view entirely fills my window and is the only view in the
>> window's content view.
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
___
Cocoa-dev mailing l
On May 19, 2012, at 10:10 PM, "mlist0...@gmail.com" wrote:
> I have a view for which I am adding a tracking area so that I can update the
> cursor. The view entirely fills my window and is the only view in the
> window's content view.
>
> The tracking area is being registered thusly:
>
> - (v
On May 20, 2012, at 02:21 , mlist0...@gmail.com wrote:
> Your alternate approach is essentially to give up on tracking areas, no? The
> tracking area approach has an attractive simplicity, especially once my view
> hierarchy and cursor tracking needs get more complicated, but if it's broken,
>
No, the window is very vanilla. No scrollviews. Hierarchy is
NSWindow
NSView (window's content view)
MyView
Your alternate approach is essentially to give up on tracking areas, no? The
tracking area approach has an attractive simplicity, especially once my view
hierarchy and cursor
16 matches
Mail list logo
