NSTableColumn second Text Cell child

[Roland King]

I have an NSOutlineView built in IB, each column I added is automatically given 
this same format (where indents imply children).

NSTableColumn
NSTableCellView
NSTextField
NSTextFieldCell
NSTextFieldCell (called ‘Text Cell’)

I believe I understand the hierarchy under the NSTableCellView - that’s just 
giving me in the end a TextField to put a label in. But what is the second 
child of the NSTableColumn, the one called “Text Cell”? I can delete the 
NSTableCellView, but not its NSTextFieldCell sibling at the bottom. 

Is that ‘Text Cell’ something to do with the old cell-based table (I’m using a 
view-based table) or is it something else? It’s not hooked up to anything, no 
connection to an outlet, it just .. sits there. When you select it in the 
sidebar the entire column is highlighted, unlike selecting the NSTableCellView 
which just highlights as if it were the top cell of the column. 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTableColumn second Text Cell child

[Stephane Sudre]

That's correct.

You will have a cell (NSCell in the project I used to check) in the
hierarchy when you use a view-based table view.
I would tend to believe it's an IB bug that the data cell for the
TableColumn is displayed.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Deployment Target

[Raglan T. Tiger]

I set my deployment target to be 10.5.

I see no warnings about using APIs not supported in 10.5.

My program crashes on 10.5.8 ... I do not haveth report from the customer as 
yet.

Is there an efficient way to isolate APIs not supported ?


-rags




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: App fails on Yosemite - "Cannot remove an observer"

[Andreas Höschler]

Hi Jerry and all,

>> You should look for … overrides of superclass properties
> 
> Yes, indeed.  Search for the AppKit Release Notes for OS X 10.10 Yosemite and 
> carefully read the section on tab views, wherein Apple has added alot of new 
> stuff, which may be stepping on your old stuff.

Thanks! 

Adding 

#ifdef __APPLE__
- (void)setWindow:(NSWindow *)window
{
}
#endif

to my GSScrollView : NSScrollView subclass fixed (or at least worked around) 
the issue (no exception anymore and no apparent malfunction of the app). 

I searched for API changes and found:

Removed -[NSScrollView autohidesScrollers]
Removed -[NSScrollView backgroundColor]
Removed -[NSScrollView borderType]
Removed -[NSScrollView contentSize]
Removed -[NSScrollView contentView]
...
Added NSScrollView.autohidesScrollers
Added NSScrollView.automaticallyAdjustsContentInsets
Added NSScrollView.backgroundColor
Added NSScrollView.borderType
Added NSScrollView.contentInsets
Added NSScrollView.contentSize
Added NSScrollView.contentView
...

What the heck does that mean? How can they remove these access methods? No idea 
what this NSScrollView.autohidesScrollers stuff is all about. This does not 
even look like Objective-C anymore!? Will they remove the message sending idea 
of Objective-C all together in the next release? :-(

This is my GSScrollViewClass:

@interface GSScrollView : NSScrollView
{
   NSSize _minSize;
}

- (id)initWithFrame:(NSRect)frame;
- (BOOL)acceptsFirstMouse:(NSEvent *)theEvent;
- (void)setFrame:(NSRect)rect;
- (void)setMinSize:(NSSize)size;
- (NSSize)minimumSizeForContent;
- (void)callSizeToFitOnTableViews;
- (unsigned int)draggingEntered:(id )sender
- (unsigned int)draggingUpdated:(id )sender;
- (void)draggingExited:(id )sender;
- (BOOL)prepareForDragOperation:(id )sender;
- (BOOL)performDragOperation:(id )sender;
- (void)concludeDragOperation:(id )sender;

and this is GSWindow:

@interface GSWindow : NSWindow 
{
   BOOL _suppressBecomingMainWin;
   GSWindow *mainWin;
   id filesOwner;
   NSRect _tempRect;
}

+ (void)relayoutContentView:(NSView < GSBoxProtocol > *)contentView

- (GSWindow *)mainWin;
- (id)filesOwner;
- (void)close;
- (BOOL)makeFirstResponder:(NSResponder *)aResponder;
- (void)setCanBecomeMainWindow:(BOOL)flag;
- (BOOL)canBecomeMainWindow;
- (void)open;
- (BOOL)validateMenuItem:(NSMenuItem *)aMenuItem;
- (void)relayout;
- (void)setFrame:(NSRect)frameRect display:(BOOL)flag

I have not subclassed NSTabView. Is this now a bug in Apples

NSScrollView::setWindow:

method? Does this ring any bells? I can't see any "stepping on Apples API" 
problem!? :-(

Thanks a lot,

 Andreas




 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deployment Target

[Quincey Morris]

On Dec 1, 2014, at 10:33 , Raglan T. Tiger  wrote:
> 
> I see no warnings about using APIs not supported in 10.5.
> 
> My program crashes on 10.5.8 ... I do not haveth report from the customer as 
> yet.
> 
> Is there an efficient way to isolate APIs not supported ?

There’s no direct way to do this in Xcode. Traditionally, you would temporarily 
set the base SDK back to 10.5 and compile to see errors about unknown (i.e. 
"future") API, but current Xcode versions don’t go back that far in SDK 
versions. You have more or less 2 options:

— Go back to a much older Xcode, which also means going back to an older Mac OS 
X version.

— Use a third-party tool such as Deploymate.

The first of these is not as terrible as it sounds. Typically you’d do it in a 
virtual machine via OS X Server or VMWare or Parallels, and there are some 
advantages in being able to develop and test on older OS’s. But it’s a bit of 
work.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: App fails on Yosemite - "Cannot remove an observer"

[Quincey Morris]

On Dec 1, 2014, at 10:41 , Andreas Höschler  wrote:
> 
> What the heck does that mean? How can they remove these access methods?

They didn’t. What they did is to change the access method declarations to 
@property declarations. The change shows up in the API changes as a deletion 
and and addition, but at run time, the exact same methods behave exactly as 
before.

> No idea what this NSScrollView.autohidesScrollers stuff is all about.

You’ve never seen Objective-C properties before!?

> This does not even look like Objective-C anymore!? Will they remove the 
> message sending idea of Objective-C all together in the next release?

IDK, but if you don’t watch out they might … I dunno … add a whole new language 
in the next release!?



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

[CALayer cornerRadius] vs. [NSBezierPath bezierPathWithRoundedRect:xRadius:yRadius]

[Bill Cheeseman]

I am looking for a way to work around the conflict between -[CALayer 
cornerRadius] and +[NSBezierPath bezierPathWithRoundedRect:xRadius:yRadius]. 
These days, NSBezierPath apparently uses a new algorithm to draw rounded 
corners on a rectangle, resulting in a smoother-appearing curve. However, 
various other classes apparently still use an older algorithm and draw rounded 
corners in a slightly different shape. This results in an unsightly graphical 
blemish when the two rounded rectangles are superimposed. The difference is 
illustrated and explained at 

 and the included links.

My OS X application has a transparent borderless window. The window's content 
view contains an NSVisualEffectView subview with dark material and a maskImage 
set to give it rounded corners using +[NSBezierPath 
bezierPathWithRoundedRect:xRadius:yRadius]. The NSVisualEffectView in turn 
contains a Core Animation layer-hosting subview whose root layer calls 
-setCornerRadius: before setting its background color. Because of the conflict 
between CALayer and NSBezierPath described above, all four corners of the 
window reveal a thin, curved arc in the dark color of the NSVisualEffectView 
material, because the curve drawn by the Core Animation layer's lighter 
background color has a little different shape.

I have tried every strategy I can think of to eliminate this graphical glitch, 
without success. All of my strategies involve using the same methods to draw 
the corners both in the NSVisualEffectView and the CALayer, on the assumption 
that using a single method for both will result in identical corner shapes. For 
example, I have drawn the corners of the NSVisualEffectView's maskImage using 
CGPathCreateWithRoundedRect(), which, according to lots of Googling, apparently 
does not incorporate the improved NSBezierPath rounded corner algorithm. And I 
have tried adding a CAShapeLayer mask to the subview's root layer using either 
-bezierPathWithRoundRect or CGPathCreateWithRoundedRect() instead of 
-setCornerRadius to round the corners. Nothing has eliminated the unsightly 
sliver at each corner, although -bezierPathWithRoundedRect and 
CGPathCreateWithRoundedRect() both create a slimmer sliver.

Can anyone suggest another approach? Apple's application switcher 
(Command-Tab), which I am trying to imitate, seems to solve the problem. Or 
maybe it takes a completely different approach.

-- 

Bill Cheeseman - b...@cheeseman.name

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deployment Target

[Raglan T. Tiger]

> On Dec 1, 2014, at 12:16 PM, Milen Dzhumerov  wrote:
> 
> you don’t actually need to run the old Xcode, you only need the SDK itself

Ok, this seems like the easiest approach.  Thanks.

-rags
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: App fails on Yosemite - "Cannot remove an observer"

[Kyle Sluder]

On Dec 1, 2014, at 10:41 AM, Andreas Höschler  wrote:
> 
> Hi Jerry and all,
> 
>>> You should look for … overrides of superclass properties
>> 
>> Yes, indeed.  Search for the AppKit Release Notes for OS X 10.10 Yosemite 
>> and carefully read the section on tab views, wherein Apple has added alot of 
>> new stuff, which may be stepping on your old stuff.
> 
> Thanks! 
> 
> Adding 
> 
> #ifdef __APPLE__
> - (void)setWindow:(NSWindow *)window
> {
> }
> #endif
> 
> to my GSScrollView : NSScrollView subclass fixed (or at least worked around) 
> the issue (no exception anymore and no apparent malfunction of the app). 

WOA. This is NOT the way to solve this problem! NSView and NSScrollView 
(may) do important work in -setWindow:! You just haven't noticed what you’ve 
broken yet.

--Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: App fails on Yosemite - "Cannot remove an observer"

[Andreas Höschler]

Hi Kyle,

>> Adding 
>> 
>> #ifdef __APPLE__
>> - (void)setWindow:(NSWindow *)window
>> {
>> }
>> #endif
>> 
>> to my GSScrollView : NSScrollView subclass fixed (or at least worked around) 
>> the issue (no exception anymore and no apparent malfunction of the app). 
> 
> WOA. This is NOT the way to solve this problem!

Of course not!! But it at least makes the application available for the time 
being (needed to be urgently fixed or at least worked around). 

> NSView and NSScrollView (may) do important work in -setWindow:! You just 
> haven't noticed what you’ve broken yet.

I have posted the methods and ivars I have added to my subclasses. I can't see 
any obvious conflict with Apples API modifications!?  And the app crashes in 
setWindow!? I see it that way. Apples implementation of NSScrollView::setWindow 
looks probably similar to this:

- (void)setWindow:(NSWindow *)window
{
// remove observer for _window::contentLayoutRect
   [_window release];
   _window = [window retain];
   ...
// add observer for _window::contentLayoutRect
}

Do you agree?

I expect a bug in Apples code where the ... are. May be a return before adding 
the observer again!??

I can only hope Apple fixes this with a Software Update soon!? Or do you have 
any further hints what I could have done wrong? Here are my ivars once again:

@interface GSScrollView : NSScrollView
{
  NSSize _minSize;
}

@interface GSWindow : NSWindow 
{
  BOOL _suppressBecomingMainWin;
  GSWindow *mainWin;
  id filesOwner;
  NSRect _tempRect;
}

Thanks,

 Andreas


29/11/14 21:21:23,496 SOSmartBrowser[731]: Cannot remove an observer 
 for the key path "contentLayoutRect" from  because it is not registered as an observer.
29/11/14 21:21:23,499 SOSmartBrowser[731]: (
0   CoreFoundation  0x9256c343 __raiseError + 195
1   libobjc.A.dylib 0x98481a2a objc_exception_throw 
+ 276
2   CoreFoundation  0x9256c25d +[NSException 
raise:format:] + 141
3   Foundation  0x99f65b18 
-[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 739
4   Foundation  0x99f65787 
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 189
5   Foundation  0x99f76919 
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:] 
+ 389
6   AppKit  0x9039c0af -[NSScrollView 
_setWindow:] + 429
7   AppKit  0x9037fe1e __21-[NSView 
_setWindow:]_block_invoke_2 + 52
8   CoreFoundation  0x9247bc3b __53-[__NSArrayM 
enumerateObjectsWithOptions:usingBlock:]_block_invoke + 107
9   CoreFoundation  0x9247b27a -[__NSArrayM 
enumerateObjectsWithOptions:usingBlock:] + 282
10  CoreFoundation  0x9247b0d5 -[NSArray 
enumerateObjectsUsingBlock:] + 53
11  AppKit  0x90afdca4 __21-[NSView 
_setWindow:]_block_invoke746 + 158
12  AppKit  0x9035afd5 
-[NSView(NSConstraintBasedLayout) _withAutomaticEngineOptimizationDisabled:] + 
111
13  AppKit  0x9035c91d -[NSView 
_setWindow:] + 2978
14  AppKit  0x90359e6f -[NSView 
addSubview:] + 453
15  AppKit  0x90359bb7 -[NSView 
replaceSubview:with:] + 152
16  AppKit  0x90621a4d -[NSTabView 
_switchTabViewItem:oldView:withTabViewItem:newView:initialFirstResponder:lastKeyView:]
 + 992
17  AppKit  0x906212d7 -[NSTabView 
selectTabViewItem:] + 568
18  AppKit  0x90a072ce -[NSTabView 
mouseDown:] + 166
19  AppKit  0x90b24c24 -[NSWindow 
_reallySendEvent:] + 12353
20  AppKit  0x9050dfb9 -[NSWindow 
sendEvent:] + 409
21  AppKit  0x904bba27 -[NSApplication 
sendEvent:] + 4679
22  AppKit  0x90335e0c -[NSApplication run] 
+ 1003
23  AppKit  0x9031f310 NSApplicationMain + 
2082
24  libdyld.dylib   0x98c466d9 start + 1
25  ??? 0x0002 0x0 + 2
)

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: App fails on Yosemite - "Cannot remove an observer"

[Lee Ann Rucker]

On Dec 1, 2014, at 1:08 PM, Andreas Höschler  wrote:

> Hi Kyle,
> 
>>> Adding 
>>> 
>>> #ifdef __APPLE__
>>> - (void)setWindow:(NSWindow *)window
>>> {
>>> }
>>> #endif
>>> 
>>> to my GSScrollView : NSScrollView subclass fixed (or at least worked 
>>> around) the issue (no exception anymore and no apparent malfunction of the 
>>> app). 
>> 
>> WOA. This is NOT the way to solve this problem!
> 
> Of course not!! But it at least makes the application available for the time 
> being (needed to be urgently fixed or at least worked around). 
> 
>> NSView and NSScrollView (may) do important work in -setWindow:! You just 
>> haven't noticed what you’ve broken yet.
> 
> I have posted the methods and ivars I have added to my subclasses. I can't 
> see any obvious conflict with Apples API modifications!?  And the app crashes 
> in setWindow!? I see it that way. Apples implementation of 
> NSScrollView::setWindow looks probably similar to this:
> 
> - (void)setWindow:(NSWindow *)window
> {
>// remove observer for _window::contentLayoutRect
>   [_window release];
>   _window = [window retain];
>   ...
>// add observer for _window::contentLayoutRect
> }
> 
> Do you agree?

No, because that's a really bad design pattern. It can bite you if you aren't 
careful - if, say, you don't call setters in dealloc because of KVO-triggered 
side effects, or anything else where the window's dealloc is called when you 
don't expect it. (Also I expect it's using ARC) 

Since you can add observers on keypaths, I would do
[self addObserver:self forKeypath:@"window.contentLayoutRect"...
instead of 
[window addObserver:self forKeypath:@"contentLayoutRect"...


And also, because it fits the behavior I've seen in other Apple bugs, the 
problem might be that there's not a "setWindow:nil" in there when it's all done 
- I have seen things that indicate they don't set delegates to nil, and since 
delegate is a weak ref, that means it can be dead and still referenced. Fine if 
everything is ARC, but not so good when there's a mix.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [CALayer cornerRadius] vs. [NSBezierPath bezierPathWithRoundedRect:xRadius:yRadius]

[Graham Cox]

> On 2 Dec 2014, at 6:19 am, Bill Cheeseman  wrote:
> 
> Can anyone suggest another approach?


Not another approach, but a possible alternative explanation. Antialiasing. 
Those curved corners will cause various nearby pixels to be rendered for 
antialiasing, and these may differ very slightly depending on all sorts of 
factors - line width, the colours used, the exact alignment of the path to the 
pixel grid, as well as the underlying curve algorithm. It's very hard to make 
two overlaid curves always hit exactly the same pixels even when using the same 
curve algorithm.

Is there no way to avoid having to overlay two curves? Maybe clip the content 
to a round-cornered rect then finally draw the same path on top? (Not sure if 
that's actually what you want, it's a little hard to visualise from the verbal 
description).

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Layer-backed multiline text view rendering dim

[Seth Willits]

Layer-backed multline text fields are drawing dimmer than otherwise *identical* 
layer-backed single line fields. The only difference is the "multiline" field 
has a new line in its text value.

Here's an example:
http://sethwillits.com/temp/upshot/upshot_uR7h5QTy.png

This visible difference only occurs when the LCD Font Smoothing option is 
turned off in System Preferences.


Does anyone know if there's a workaround for this? I tried telling the text 
field to draw an opaque white background as well (to deal with subpixelness), 
but that didn't change anything.


--
Seth Willits




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Layer-backed multiline text view rendering dim

[Martin Stoyanov]

On Dec 01, 15:38 PM, sli...@araelium.com wrote:

Layer-backed multline text fields are drawing dimmer than otherwise 
*identical*
layer-backed single line fields. The only difference is the "multiline" 
field

has a new line in its text value. Here's an example:
http://sethwillits.com/temp/upshot/upshot_uR7h5QTy.png This visible 
difference

only occurs when the LCD Font Smoothing option is turned off in System
Preferences. Does anyone know if there's a workaround for this? I tried 
telling

the text field to draw an opaque white background as well (to deal with
subpixelness), but that didn't change anything. -- Seth Willits
___ Cocoa-dev mailing list
(Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator
comments to the list. Contact the moderators at
cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your 
Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdimovv%40gmail.com This 
email

sent to mdim...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com