Re: Redeclaring property types in mutable subclasses

[Ken Thomases]

On Mar 28, 2011, at 11:28 PM, Quincey Morris wrote:

> On Mar 28, 2011, at 20:05, Adam Ernst wrote:
> 
>> I have a class with an array property:
>> 
>> @interface Widget : NSObject {}
>> @property (retain, readonly) NSArray *gizmos;
>> @end
>> 
>> I make a mutable subclass. In addition to making the array property 
>> readwrite, I also make it an NSMutableArray for convenience:
>> 
>> @interface MutableWidget : Widget {}
>> @property (retain, readwrite) NSMutableArray *gizmos;
>> @end
>> 
>> This triggers a warning:
>> 
>> Property 'gizmos' type does not match super class 'Widget' property type
>> 
>> I can understand why this is being triggered. How can I work around it? I 
>> could keep it a straight NSArray, but this is cumbersome to edit. 
>> Suggestions on how to properly model this in my code?
> 
> The pattern I use is:
> 
>> @interface MutableWidget : Widget {}
>> @property (retain, readwrite) NSMutableArray *mutableGizmos;
>> @end

Do either of you really mean for that property to be read-write?

I can see making a property read-write with an immutable type, and I can see 
(although I don't particularly like) making a read-only property return a 
mutable type.  (Having properties of mutable type breaks encapsulation in a big 
way.)  But it seems strange to me to make a read-write property of mutable type.

Especially you, Quincey, when you've made a "sibling", mutable variant of the 
property.  Is there really a setMutableGizmos: method?  What does it mean?

Also, if you're using -mutableArrayValueForKey: without providing the mutation 
accessors, then that's probably asking for grief.  Actually, you said something 
I didn't follow about a setter for the gizmos property, but that's read-only.  
So, it's not clear to me how the proxy is supposed to mutate it (other than 
KVC's direct instance variable access, which I always disable).  And without 
either a proper setter or the mutation accessors, you've violated 
encapsulation.  Clients of your class can mutate your property without you 
being informed (unless you KVObserve your own property).

Here's what makes sense to me:

@interface Widget : NSObject {}
@property (retain, readonly) NSArray *gizmos;

// optionally, any of:
- (NSUInteger) countOfGizmos;
- (id) objectInGizmosAtIndex:(NSUInteger)index;
- (NSArray*) gizmosAtIndexes:(NSIndexSet*)indexes;
- (void) getGizmos:(Gizmo**)buffer range:(NSRange)inRange;

@end


@interface MutableWidget : Widget {}

// At least one of:
- (void) insertObject:(Gizmo*)gizmo inGizmosAtIndex:(NSUInteger)index;
- (void) insertGizmos:(NSArray *)gizmoArray atIndexes:(NSIndexSet *)indexes;

// At least one of:
- (void) removeObjectFromGizmosAtIndex:(NSUInteger)index;
- (void) removeGizmosAtIndexes:(NSIndexSet *)indexes;

// optionally, either of:
- (void) replaceObjectInGizmosAtIndex:(NSUInteger)index withObject:(id)anObject;
- (void) replaceGizmosAtIndexes:(NSIndexSet *)indexes withGizmos:(NSArray 
*)gizmoArray;

@end


Then, clients of MutableWidget can either directly use those mutation accessors 
or they can invoke [aMutableWidget mutableArrayValueForKey:@"gizmos"] and 
mutate that.  If you really want to wrap the latter in a convenience method, 
you can, but I don't think that constitutes a read-write property.

And I reiterate that one should almost always implement 
+(BOOL)accessInstanceVariablesDirectly { return NO; } on all one's classes.


If you're looking for guidance, I suggest contemplating what the framework 
classes do.  Can you think of any mutable class which changes the type of one 
of the base class's properties to be mutable?  Can you think of any which added 
a mutable variant of one of the base class's properties (as mutableGizmos is to 
gizmos)?  Well, frankly, can you think of any framework class that has a 
property of mutable type?!?

No.  Mutable subclasses should provide setters or mutation accessors.  That's 
the core of what they should add to the interface of the immutable super class.

Regards,
Ken

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Redeclaring property types in mutable subclasses

[Quincey Morris]

On Mar 28, 2011, at 20:05, Adam Ernst wrote:

> I have a class with an array property:
> 
> @interface Widget : NSObject {}
> @property (retain, readonly) NSArray *gizmos;
> @end
> 
> I make a mutable subclass. In addition to making the array property 
> readwrite, I also make it an NSMutableArray for convenience:
> 
> @interface MutableWidget : Widget {}
> @property (retain, readwrite) NSMutableArray *gizmos;
> @end
> 
> This triggers a warning:
> 
> Property 'gizmos' type does not match super class 'Widget' property type
> 
> I can understand why this is being triggered. How can I work around it? I 
> could keep it a straight NSArray, but this is cumbersome to edit. Suggestions 
> on how to properly model this in my code?

The pattern I use is:

> @interface MutableWidget : Widget {}
> @property (retain, readwrite) NSMutableArray *mutableGizmos;
> @end

because:

a. There's no practical alternative, I don't think, in terms of keeping the 
compiler happy AND having the strongest possible compile time type checking.

b. It's often convenient to implement 'mutableGizmos' this way:

> - (NSMutableArray*) mutableGizmos {
>   return [self mutableArrayValueForKey: @"gizmos"];
> }

The advantage of this is that it's easy and it's automatically KVO compliant. 
With a couple of extra lines, you can cache the mutable array property in the 
mutable getter, and avoid the object creation every time it's called, if you 
think it's worth the trouble.

c. The caller, therefore, needs to know whether it's making a mutable or 
immutable reference to the property. It's surprising how often it helps clarify 
your thinking when you have to decide which one you mean.

Note: With the more recent compiler versions (gcc 4.2, at least), I think you 
get an error saying that there's no getter for "gizmos" in the mutable 
subclass, even though the superclass obviously must have one. The easiest way 
to solve that is to put:

> @dynamic gizmos;

in the subclass, meaning "use the damn setter you've already got".


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

UI Panel With "Pointer" On One Side

[Brian Froisy]

I want to duplicate UI functionality that appears in several Apple products. I 
have not been able to determine if there is a standard view (window, panel, 
etc.) to do this. It is a panel with a side "arrow" such as the list seen when 
right-click  on a dock item.  Another (similar) example is when you click on a 
(list view) library object in the interface builder part of Xcode 4.

 A picture is worth 1000 words.

http://web.me.com/jbfroisy/UI_Question/UI_Question.html

Thanks

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Redeclaring property types in mutable subclasses

[Adam Ernst]

I have a class with an array property:

@interface Widget : NSObject {}
@property (retain, readonly) NSArray *gizmos;
@end

I make a mutable subclass. In addition to making the array property readwrite, 
I also make it an NSMutableArray for convenience:

@interface MutableWidget : Widget {}
@property (retain, readwrite) NSMutableArray *gizmos;
@end

This triggers a warning:

Property 'gizmos' type does not match super class 'Widget' property type

I can understand why this is being triggered. How can I work around it? I could 
keep it a straight NSArray, but this is cumbersome to edit. Suggestions on how 
to properly model this in my code?

Adam

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Release Build PPC Link Error

[Nick Zitzmann]

On Mar 28, 2011, at 5:58 PM, Ian was here wrote:

> I created a framework and have been using it successfully until I upgraded to 
> XCode 3.2.6. Whenever I attempt to do a release build, I get the following 
> link error:
> 
> "In myFamework/build/Release/myFramework.framework/myFramework, file was 
> built for i386 which is not the architecture being linked (ppc)"
> 
> The release build is set to create a universal binary (ppc/i386).
> 
> Has anyone else ran into this problem?

Yes. And IANTM, but you should probably ask for a solution, and not a 
confirmation, on the Xcode list. This list has nothing to do with Xcode.

Nick Zitzmann


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Release Build PPC Link Error

[Graham Cox]

On 29/03/2011, at 10:58 AM, Ian was here wrote:

> I created a framework and have been using it successfully until I upgraded to 
> XCode 3.2.6. Whenever I attempt to do a release build, I get the following 
> link error:
> 
> "In myFamework/build/Release/myFramework.framework/myFramework, file was 
> built for i386 which is not the architecture being linked (ppc)"
> 
> The release build is set to create a universal binary (ppc/i386).
> 
> Has anyone else ran into this problem?


Yes. The framework is not set to create a universal binary, so when the app 
tries to build the PPC part, it can't link to the framework, because it has no 
PPC code to link to.

Simple fix - change the build settings for the framework so that it is creating 
a universal framework.

Note that if you eventually expect to release to the App Store, you can't 
include PPC code, even in a linked framework. I mention this because it's 
becoming more common now to find frameworks with the PPC build suppressed 
because of this, and so this error is becoming more common.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Release Build PPC Link Error

[Ian was here]

I created a framework and have been using it successfully until I upgraded to 
XCode 3.2.6. Whenever I attempt to do a release build, I get the following link 
error:

"In myFamework/build/Release/myFramework.framework/myFramework, file was built 
for i386 which is not the architecture being linked (ppc)"

The release build is set to create a universal binary (ppc/i386).

Has anyone else ran into this problem?



  
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Trace/BPT trap

[John Brayton]

> You're not getting crash logs because the crash reporter is crashing. There's 
> definitely something wrong with your machine or its OS installation.

Perhaps, but I think there is more to it than that. I am seeing the
issue on all three of my test systems:

* An iMac running Mac OS 10.6.7, here in my office.
* A MacBook running Mac OS 10.6.7, here in my office.
* A Mac mini running Mac OS 10.6.6, located a few thousand miles away.

The Mac mini has relatively little in common with the other two
systems.  The primary purpose of the mini is to act as my web server,
so it does not have much third party software.

I have a debug menu item that can deliberately crash my app.  When I
run that, I get a crash report written to the
~/Library/Logs/DiagnosticReports directory as I would expect.

John
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Trace/BPT trap

[Greg Parker]

On Mar 28, 2011, at 2:05 PM, John Brayton wrote:
>> A Trace/BPT trap is generated when the process kills itself, such as abort() 
>> or __builtin_trap() or assert() failure.
>> 
>> Is this a normal app, or something unusual like a user agent or LSUIElement ?
> 
> My app is an LSUIElement, although I did see the problem after
> removing LSUIElement from the Info.plist file.  The purpose of the app
> is to backup Google Docs, Calendars, and Contacts.  The app typically
> performs backups every hour.  When I have seen this error, I have had
> the app in "stress test" mode, backing up data every minute.  I don't
> know if backing up data so often is triggering the error, or just
> making it happen more quickly.
> 
> In one case, I saw a "Throttling respawn: Will start in 10 seconds"
> just before the Trace/BPT trap:
> 
> 3/27/11 10:54:00
> PMcom.apple.launchd.peruser.502[157]  
> (com.apple.ReportCrash.Self[16412])
> Job appears to have crashed: Trace/BPT trap

You're not getting crash logs because the crash reporter is crashing. There's 
definitely something wrong with your machine or its OS installation.

Your app's crashes may have the same cause as ReportCrash's crashes, or you may 
have a bug of your very own. 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Trace/BPT trap

[John Brayton]

> A Trace/BPT trap is generated when the process kills itself, such as abort() 
> or __builtin_trap() or assert() failure.
>
> Is this a normal app, or something unusual like a user agent or LSUIElement ?

My app is an LSUIElement, although I did see the problem after
removing LSUIElement from the Info.plist file.  The purpose of the app
is to backup Google Docs, Calendars, and Contacts.  The app typically
performs backups every hour.  When I have seen this error, I have had
the app in "stress test" mode, backing up data every minute.  I don't
know if backing up data so often is triggering the error, or just
making it happen more quickly.

In one case, I saw a "Throttling respawn: Will start in 10 seconds"
just before the Trace/BPT trap:

3/27/11 10:53:50
PM  com.apple.launchd.peruser.502[157]  (com.apple.ReportCrash)
Throttling respawn: Will start in 10 seconds
3/27/11 10:53:51
PM  com.apple.launchd[1]catch_mach_exception_raise_state_identity():
PID: 16410 thread: 0x9a47 type: 0xa code: 0x1000f6044 codeCnt: 0x2
flavor: 0x1000f6054 old_state: 0x1000f605c old_stateCnt: 0x2c
new_state: 0x1000f502c new_stateCnt: 0x1000f5028
3/27/11 10:53:51
PM  com.apple.launchd[1](com.apple.ReportCrash.Root[16410]) Job
appears to have crashed: Trace/BPT trap
3/27/11 10:53:51
PM  com.apple.launchd[1]catch_mach_exception_raise_state_identity():
PID: 16409 thread: 0x9d07 type: 0xa code: 0x7fff5fbfe0c4 codeCnt: 0x2
flavor: 0x7fff5fbfe0d4 old_state: 0x7fff5fbfe0dc old_stateCnt: 0x2c
new_state: 0x7fff5fbfe5ec new_stateCnt: 0x7fff5fbfe5e8
3/27/11 10:53:51
PM  com.apple.launchd[1](0x10041f6b0.mach_init.mdworker[16409]) Job
appears to have crashed: Trace/BPT trap
3/27/11 10:53:51
PM  com.apple.launchd[1](0x10041f6b0.mach_init.mdworker) Failed to
check-in!
3/27/11 10:54:00
PM  com.apple.launchd.peruser.502[157]  
catch_mach_exception_raise_state_identity():
PID: 16412 thread: 0x124e3 type: 0xa code: 0x1000f8044 codeCnt: 0x2
flavor: 0x1000f8054 old_state: 0x1000f805c old_stateCnt: 0x2c
new_state: 0x1000f702c new_stateCnt: 0x1000f7028
3/27/11 10:54:00
PM  com.apple.launchd.peruser.502[157]  
(com.apple.ReportCrash.Self[16412])
Job appears to have crashed: Trace/BPT trap
3/27/11 10:54:00
PM  com.apple.launchd.peruser.502[157]  
catch_mach_exception_raise_state_identity():
PID: 16411 thread: 0x11eef type: 0xa code: 0x7fff5fbfdef4 codeCnt: 0x2
flavor: 0x7fff5fbfdf04 old_state: 0x7fff5fbfdf0c old_stateCnt: 0x2c
new_state: 0x7fff5fbfe41c new_stateCnt: 0x7fff5fbfe418
3/27/11 10:54:00
PM  com.apple.launchd.peruser.502[157]  (com.apple.ReportCrash[16411])
Job appears to have crashed: Trace/BPT trap
3/27/11 10:54:00
PM  com.apple.launchd.peruser.502[157]  
catch_mach_exception_raise_state_identity():
PID: 16112 thread: 0x11ef3 type: 0xa code: 0x7fff5fbfdef4 codeCnt: 0x2
flavor: 0x7fff5fbfdf04 old_state: 0x7fff5fbfdf0c old_stateCnt: 0x2c
new_state: 0x7fff5fbfe41c new_stateCnt: 0x7fff5fbfe418
3/27/11 10:54:00
PM  com.apple.launchd.peruser.502[157]  
([0x0-0xa5ea5e].com.goldenhillsoftware.CloudPull[16112])
Job appears to have crashed: Trace/BPT trap

I am using ASIHTTPRequest heavily, and that uses asserts.  I will try
removing the asserts to see if that changes the result.

Thanks.

John
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Trace/BPT trap

[Greg Parker]

On Mar 27, 2011, at 3:32 PM, John Brayton wrote:
> I am encountering an issue where my app crashes after running for 4-6
> hours.  I don't see a crash report, and the user is not alerted that
> the app has crashed; the app just silently stops running.  This is
> what I see in the Console logs:
> 
> 3/23/11 2:56:49 PM  com.apple.launchd.peruser.501[111]
> (com.apple.ReportCrash.Self[22101]) Job appears to have crashed:
> Trace/BPT trap
> 3/23/11 2:56:49 PM  com.apple.launchd.peruser.501[111]
> (com.apple.ReportCrash[22100]) Job appears to have crashed: Trace/BPT
> trap
> 3/23/11 2:56:49 PM  com.apple.launchd.peruser.501[111]
> ([0x0-0x295295].com.goldenhillsoftware.CloudPull[19747]) Job appears
> to have crashed: Trace/BPT trap
> 
> I am trying to determine what to look for that would cause a
> "Trace/BPT trap".  

A Trace/BPT trap is generated when the process kills itself, such as abort() or 
__builtin_trap() or assert() failure. 

Is this a normal app, or something unusual like a user agent or LSUIElement ?


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How can I make a palette input method with cocoa?

[Aki Inoue]

The HIToolbax release note has a section describing the input source types.

http://developer.apple.com/library/mac/#releasenotes/Carbon/HIToolbox.html

Look for "Text Input Sources".

Aki

On 2011/03/25, at 0:08, 李顺年 wrote:

> Hi All!
> 
> I want to make a palette input method of mac. But the sample
> (NumberInput_IMKit_Sample) of IMK is keyboard layout. Anyone can tell
> me how can make a palette input method?
> 
> Thanks,
> 
> Sunny
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com
> 
> This email sent to a...@apple.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Font Height and -[NSString sizeWithAttributes:]

[Aki Inoue]

The default line height used by the Cocoa Text System is based on various 
layout time configurations.  So, the differences you're seeing is coming from 
the differences in layout context.

The settings are all encapsulated in NSLayoutManager; hence, the method 
-[NSLayoutManager defaultLineHeightForFont:] gives you the information used by 
the layout context.

Aki

On 2011/03/28, at 12:06, Quincey Morris wrote:

> On Mar 28, 2011, at 09:45, Thomas Clément wrote:
> 
>>> NSFont *font = [NSFont fontWithName:@"Menlo" size:11.0];
>>> [@"Hello World" sizeWithAttributes:[NSDictionary 
>>> dictionaryWithObjectsAndKeys:font, NSFontAttributeName, nil]];
>> 
>> This returns a height of 17.0. However when using this font (Menlo 11.0) in 
>> TextEdit (plain text document), I'm seeing a line height of 13.0.
>> 
>> Monaco 10.0 returns a height of 14.0 which is also what I'm seeing in 
>> TextEdit.
>> Helvetica 12.0 returns a height of 15.0 but I'm seeing 14.0 in TextEdit.
>> 
>> Why these differences?
> 
> 'sizeWithAttributes:' returns the bounding box, in points, of the glyphs 
> representing the characters in the string you passed.
> 
>> How do I get programmatically the value I'm seeing in TextEdit?
> 
> There's no absolute typographic standard for the inter-baseline distance, but 
> it's almost always derived from font metrics, not from glyph bounding boxes. 
> Here are some of the possibilities:
> 
> -- The font size multiplied by a standard factor, like 120%. This is (or used 
> to be, at least) what apps like Adobe Illustrator used to use, because it 
> doesn't depend on the specific font metrics, and therefore the line spacing 
> of a line doesn't depend on what fonts are on it, only on their sizes.
> 
> -- The font's ascender + descender + "leading". These are metrics built into 
> the font itself, independent of the actual glyph bounds. This is probably 
> what TextEdit is using. (What Apple calls "leading" is really called "extra 
> leading" in the typographic world. Typographically, leading *is* the 
> inter-baseline distance: the whole thing.) IIRC, changing fonts in TextEdit 
> can affect the inter-baseline distance on a line-by-line basis.
> 
> -- The glyph bounding box, either of the particular line, or of all the 
> characters in the font. You'd only use this if you can't tolerate glyph 
> images overlapping, ever.
> 
> -- Any weird calculation that someone thought was a good idea at the time.
> 
> There's no right answer, unfortunately.
> 
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com
> 
> This email sent to a...@apple.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Weird NSSearchField text layout bug

[Aki Inoue]

Looks like an issue with us.

Please file a bug with the reproducing steps.

Thanks,

Aki

On 2011/03/25, at 21:50, Indragie Karunaratne wrote:

> I'm having a really weird issue with NSSearchField at the moment. Whenever 
> the search field ends editing, this happens:
> 
> http://d.indragie.com/bRDS
> 
> I did some tests and it _seems_ that the reason that's happening is because 
> this particular search field has been placed as a subview of the window frame 
> ([[window contentView] superview]). I'm not sure how that would really affect 
> the way in which text is laid out in the view.
> 
> Any pointers are appreciated.___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com
> 
> This email sent to a...@apple.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Font Height and -[NSString sizeWithAttributes:]

[Quincey Morris]

On Mar 28, 2011, at 09:45, Thomas Clément wrote:

>> NSFont *font = [NSFont fontWithName:@"Menlo" size:11.0];
>> [@"Hello World" sizeWithAttributes:[NSDictionary 
>> dictionaryWithObjectsAndKeys:font, NSFontAttributeName, nil]];
> 
> This returns a height of 17.0. However when using this font (Menlo 11.0) in 
> TextEdit (plain text document), I'm seeing a line height of 13.0.
> 
> Monaco 10.0 returns a height of 14.0 which is also what I'm seeing in 
> TextEdit.
> Helvetica 12.0 returns a height of 15.0 but I'm seeing 14.0 in TextEdit.
> 
> Why these differences?

'sizeWithAttributes:' returns the bounding box, in points, of the glyphs 
representing the characters in the string you passed.

> How do I get programmatically the value I'm seeing in TextEdit?

There's no absolute typographic standard for the inter-baseline distance, but 
it's almost always derived from font metrics, not from glyph bounding boxes. 
Here are some of the possibilities:

-- The font size multiplied by a standard factor, like 120%. This is (or used 
to be, at least) what apps like Adobe Illustrator used to use, because it 
doesn't depend on the specific font metrics, and therefore the line spacing of 
a line doesn't depend on what fonts are on it, only on their sizes.

-- The font's ascender + descender + "leading". These are metrics built into 
the font itself, independent of the actual glyph bounds. This is probably what 
TextEdit is using. (What Apple calls "leading" is really called "extra leading" 
in the typographic world. Typographically, leading *is* the inter-baseline 
distance: the whole thing.) IIRC, changing fonts in TextEdit can affect the 
inter-baseline distance on a line-by-line basis.

-- The glyph bounding box, either of the particular line, or of all the 
characters in the font. You'd only use this if you can't tolerate glyph images 
overlapping, ever.

-- Any weird calculation that someone thought was a good idea at the time.

There's no right answer, unfortunately.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Hash Values in Custom Classes

[Sean McBride]

On Sat, 26 Mar 2011 02:23:42 +0100, Peter Lübke said:

>To be more detailed: my custom class and its subclasses are wrapper
>classes containing file informations. They are based on FSRef rather
>than using paths - I do a lot of lengthy iterations so paths are much
>too fragile. I also heavily use NSSet to store instances, and I
>wanted -isEqual: to be as fast as possible. So I thought I could just
>return a unique hash value for each custom class and return
>(FSCompareFSRefs (&ownRef, &otherRef) == noErr) for -isEqual:, thus
>avoiding the need to *first* compare the objects' classes.

Are you aware that starting in 10.6, the OS provides 'file reference
URLs' which are much like FSRefs.  See:



--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Font Height and -[NSString sizeWithAttributes:]

[Thomas Clément]

Hello,

I'm confused about the returned height from -[NSString sizeWithAttributes:].

> NSFont *font = [NSFont fontWithName:@"Menlo" size:11.0];
> [@"Hello World" sizeWithAttributes:[NSDictionary 
> dictionaryWithObjectsAndKeys:font, NSFontAttributeName, nil]];

This returns a height of 17.0. However when using this font (Menlo 11.0) in 
TextEdit (plain text document), I'm seeing a line height of 13.0.

Monaco 10.0 returns a height of 14.0 which is also what I'm seeing in TextEdit.
Helvetica 12.0 returns a height of 15.0 but I'm seeing 14.0 in TextEdit.

Why these differences?
How do I get programmatically the value I'm seeing in TextEdit?


Thomas___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Convert nib file usage to dynamically created controls

[Vyacheslav Karamov]

Hi All!

I'm pretty new to Cocoa and I (alone) have to support large Cocoa-based 
project which uses NIBs with
custom controls. I've rewritten IB 3x plug-in, but IB crashes while 
opening some of the NIBs.

How to convert these NIBs to dynamically created controls?
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Unique identification of foreign windows

[Benedikt Iltisberger]

Hey everybody,

I am working with the the accessibility API and I need to identify windows 
(selected by the user).
This identification must be unique.
I tried many things but nothing worked out.

I need this mechanism to check if a window (selected by the user) has been 
selected before.
Checking size, name, dimension, PID and so on is not sufficient for my purpose.

Does anyone have an idea? Would really appreciate it.

Cheers,
Ben___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Hash Values in Custom Classes

[Peter Lübke]

To be more detailed: my custom class and its subclasses are  
wrapper classes containing file informations. They are based on  
FSRef rather than using paths - I do a lot of lengthy iterations  
so paths are much too fragile. I also heavily use NSSet to store  
instances, and I wanted -isEqual: to be as fast as possible. So I  
thought I could just return a unique hash value for each custom  
class and return (FSCompareFSRefs (&ownRef, &otherRef) == noErr)  
for -isEqual:, thus avoiding the need to *first* compare the  
objects' classes.



Am 28.03.2011 um 01:23 schrieb Mike Abdullah:


http://www.mikeash.com/pyblog/friday-qa-2010-05-28-leopard- 
collection-classes.html


Good link, particularly NSPointerArray might come in handy in future  
projects.


I trust you have profiled your code etc. before deciding this is  
worth your while…


For my current project, NSSet works fine. I'll test for class  
identity before calling FSCompareFSRefs() in the -isEqual: methods of  
my custom classes, so I'm not dependant on *absolute* uniqueness of  
the values they return for -hash.


Cheers,

Peter___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Help with Custom Control

[Vyacheslav Karamov]

26-Mar-11 00:16, Kyle Sluder пишет:

On Fri, Mar 25, 2011 at 2:48 PM, WT  wrote:

I'm downloading 4.0.1 at this very moment so I didn't know that IB plugins are 
officially deprecated. That really indeed sucks.

File bugs at http://bugreport.apple.com. If you don't, the developers
won't know that removing this functionality affects you.

--Kyle Sluder

Is it allowed to create duplicate bugs?
I've already created Bug ID# 9168578.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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