Re: OS X : Different icon for Status Item

[Seth Willits]

On Dec 7, 2013, at 8:47 PM, Jerry Krinock  wrote:

> How can I make my app’s Status Item (“menulet", right side of menu bar) have 
> a different icon than its icon shown in the Dock and Finder?
> 
> I cannot find any mention of this in “Status Item Programming Topics”, and 
> tests indicate that it simply uses the same .icns resource indicated by 
> CFBundleIconFile in Info.plist.  But I’ve seen other non-Apple apps do it, so 
> apparently it can be done.

Uhh…  setImage: ?


--
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

OS X : Different icon for Status Item

[Jerry Krinock]

How can I make my app’s Status Item (“menulet", right side of menu bar) have a 
different icon than its icon shown in the Dock and Finder?

I cannot find any mention of this in “Status Item Programming Topics”, and 
tests indicate that it simply uses the same .icns resource indicated by 
CFBundleIconFile in Info.plist.  But I’ve seen other non-Apple apps do it, so 
apparently it can be done.

Thanks,

Jerry Krinock
___

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: What are the contents of NSPasteboardTypeFont?

[Kyle Sluder]

On Sat, Dec 7, 2013, at 12:27 PM, Jens Alfke wrote:
> Does anyone know what the data format of NSPasteboardTypeFont is? Or if
> this type is even used at all?

According to the Pasteboard Programming Guide, NSPasteboardTypeFont is a
UTI that is equivalent to the old NSFontPboardType:


That document's link to the legacy Pasteboard Programming Topics for
Cocoa document is broken, but that document is still accessible via the
Retired Documents Library. It contains a chapter on Reading and Writing
Font Data that describes how to work with the font pasteboard:


--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

What are the contents of NSPasteboardTypeFont?

[Jens Alfke]

Does anyone know what the data format of NSPasteboardTypeFont is? Or if this 
type is even used at all?

I’m writing a font-management app, and in the drag-and-drop code I’d like to 
support a standard pasteboard type instead of just something specific to my 
app, but I can’t figure out if there even is one (neither Font Book nor the 
NSFontPanel seem to support drag-and-drop.)

—Jens
___

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: Threaded drawing

[Clark Smith Cox III]

On Dec 6, 2013, at 7:27, Graham Cox  wrote:

> 
> On 6 Dec 2013, at 11:26 am, Graham Cox  wrote:
> 
>>  NSBlockOperation* op = [NSBlockOperation 
>> blockOperationWithBlock:^
>>  {
>>  CGContextClipToRect( ncx, tileRect );
>> 
>>  [self drawTile:tileRect inContext:ncx];
>>  }];
> 
> 
> A question for blocks experts:
> 
> Is the value of  here captured when the block is created,or when it 
> is run?

It is captured when the block is created.

-- 
Clark Smith Cox III
clark@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Correct use of CFArraySortValues context parameter

[Markus Spoettl]

On 12/7/13 3:35 PM, Ken Thomases wrote:

Can anyone tell me if the latter use of CFArraySortValues() is correct?


It is.  Your analysis is correct.


It doesn't feel right to cast an int option to (void *) but the
documentation simply doesn't say it will pass on a dereferenced value.


The docs for CFArraySortValues() describes the context parameter as "[a]
pointer-sized program-defined value".  It is declared as a pointer only to
guarantee that it's large enough to hold a pointer even on architectures
where a pointer is larger than, say, an int.  But semantically, it's just a
"value".  It may have been better for Apple to have used uintptr_t.


The fact that the leak went away tells me I'm on the right track.


Well, I can't explain why passing the pointer to the context variable would
have caused a leak.  In theory, CFStringCompare() would simply have
interpreted it as a option bit mask with an arbitrary variety of options set.
I wouldn't expect any such options to cause a leak.

But you're right that the original call was incorrect.


Thanks Ken for the quick confirmation!

In that case, a word of warning to all AquaticPrime users - that's where this 
code comes from. The function you're looking for is 
APCreateDictionaryForLicenseData().


Regards
Markus
--
__
Markus Spoettl
___

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: Correct use of CFArraySortValues context parameter

[Ken Thomases]

On Dec 7, 2013, at 7:49 AM, Markus Spoettl wrote:

> This was the invocation:
> 
> int context = kCFCompareCaseInsensitive;
> CFArraySortValues(keyArray,
>  CFRangeMake(0, count),
>  (CFComparatorFunction)CFStringCompare, &context);
> 
> After reading through CFArraySortValues and CFStringCompare documentation 
> it's clear (to me anyway) that the context is used incorrectly. The 
> documentation doesn't imply it will dereference the context pointer at any 
> point. That means that CFStringCompare will be called with the pointer value 
> instead of the contents of that address.
> 
> Changing it to
> 
> CFArraySortValues(keyArray,
>  CFRangeMake(0, count),
>  (CFComparatorFunction)CFStringCompare,
>  (void*)kCFCompareCaseInsensitive);
> 
> made the leak go away. I can only assume that the author never realized the 
> array wasn't going to be sorted the way he intended.
> 
> Can anyone tell me if the latter use of CFArraySortValues() is correct?

It is.  Your analysis is correct.

> It doesn't feel right to cast an int option to (void *) but the documentation 
> simply doesn't say it will pass on a dereferenced value.

The docs for CFArraySortValues() describes the context parameter as "[a] 
pointer-sized program-defined value".  It is declared as a pointer only to 
guarantee that it's large enough to hold a pointer even on architectures where 
a pointer is larger than, say, an int.  But semantically, it's just a "value".  
It may have been better for Apple to have used uintptr_t.

> The fact that the leak went away tells me I'm on the right track.

Well, I can't explain why passing the pointer to the context variable would 
have caused a leak.  In theory, CFStringCompare() would simply have interpreted 
it as a option bit mask with an arbitrary variety of options set.  I wouldn't 
expect any such options to cause a leak.

But you're right that the original call was incorrect.

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

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

Correct use of CFArraySortValues context parameter

[Markus Spoettl]

I recently discovered a strange memory leak in a 3rd-party component I use. A 
call to CFArraySortValues() sometimes produced a leak, sometimes it didn't.


This was the invocation:

int context = kCFCompareCaseInsensitive;
CFArraySortValues(keyArray,
  CFRangeMake(0, count),
  (CFComparatorFunction)CFStringCompare, &context);

After reading through CFArraySortValues and CFStringCompare documentation it's 
clear (to me anyway) that the context is used incorrectly. The documentation 
doesn't imply it will dereference the context pointer at any point. That means 
that CFStringCompare will be called with the pointer value instead of the 
contents of that address.


Changing it to

CFArraySortValues(keyArray,
  CFRangeMake(0, count),
  (CFComparatorFunction)CFStringCompare,
  (void*)kCFCompareCaseInsensitive);

made the leak go away. I can only assume that the author never realized the 
array wasn't going to be sorted the way he intended.


Can anyone tell me if the latter use of CFArraySortValues() is correct? It 
doesn't feel right to cast an int option to (void *) but the documentation 
simply doesn't say it will pass on a dereferenced value. The fact that the leak 
went away tells me I'm on the right track.


Regards
Markus
--
__
Markus Spoettl
___

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: Threaded drawing

[Graham Cox]

On 7 Dec 2013, at 1:05 am, Roland King  wrote:

> And reminded of the comment about how hard block syntax can be to remember, I 
> didn't make this page, I'm not a fan of the name, but it's awfully useful and 
> I keep it bookmarked,  I tinyURLed it to avoid tripping up swear checkers, 
> http://tinyurl.com/m6lukyg. 


Ha yes, thanks. Glad I’m not the only one ;-)

—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