Got it Jens and thanks everyone for the help it’s much appreciated… :-)
On Jan 24, 2015, at 1:05 AM, Jens Alfke j...@mooseyard.com wrote:
On Jan 23, 2015, at 1:53 AM, Rick C. rickcort...@gmail.com
mailto:rickcort...@gmail.com wrote:
Unfortunately setApplicationIconImage: works great
:
Unfortunately setApplicationIconImage: works great it’s just I
can’t find a method to put it in that will cause the change before
the app launches. It always takes place a second after the app
launches…
What you're asking for is impossible, because
-setApplicationIconImage is a TEMPORARY change
On Jan 23, 2015, at 1:53 AM, Rick C. rickcort...@gmail.com wrote:
Unfortunately setApplicationIconImage: works great it’s just I can’t find a
method to put it in that will cause the change before the app launches. It
always takes place a second after the app launches…
What you're asking
to use setApplicationIconImage:, but do things the other way
around. Make the Yosemite icon be the app's official one, and only call
setApplicationIconImage: for earlier OS versions. That way any unpleasantness
will cure itself when the user upgrades. You might even include a preference
setting so
Thanks everyone for the help. Bit of effort for something simple though.
Unfortunately setApplicationIconImage: works great it’s just I can’t find a
method to put it in that will cause the change before the app launches. It
always takes place a second after the app launches…
On Jan 23
is the case that you want to continue to have two versions, I suggest
you continue to use setApplicationIconImage:, but do things the other way
around. Make the Yosemite icon be the app's official one, and only call
setApplicationIconImage: for earlier OS versions. That way any unpleasantness
On 23 Jan 2015, at 10:07 AM, Steve Mills sjmi...@mac.com wrote:
-setIcon:forFile:options: still sounds like your best bet, because it will
make a lasting change. Although it's too bad that Apple didn't allow this
method to take an .icns file as well as an image. That would've made it the
On 22 Jan 2015, at 08:32, Allan Odgaard lists+cocoa-...@simplit.com wrote:
For this to work, you need to exclude the Info.plist from the app bundle’s
signature.
Sounds like an exploit waiting to happen, though...
If the OP insists on adapting the icon to the current OS version then I
setApplicationIconImage: to set a different icon for
Yosemite. Problem is the standard icon appears for a second then it changes
to the Yosemite one. Same when quitting the app. Is there a better way to
do this?
___
Cocoa-dev mailing list (Cocoa-dev
Hi,
I’m using NSApp setApplicationIconImage: to set a different icon for Yosemite.
Problem is the standard icon appears for a second then it changes to the
Yosemite one. Same when quitting the app. Is there a better way to do this?
___
Cocoa-dev
On Jan 21, 2015, at 9:46 PM, Rick C. rickcort...@gmail.com wrote:
I’m using NSApp setApplicationIconImage: to set a different icon for
Yosemite. Problem is the standard icon appears for a second then it changes
to the Yosemite one. Same when quitting the app. Is there a better way
NSApp setApplicationIconImage: to set a different icon for
Yosemite. Problem is the standard icon appears for a second then it changes
to the Yosemite one. Same when quitting the app. Is there a better way to
do this?
That method just temporarily alters the displayed icon while the app
On Jan 21, 2015, at 11:03 PM, Rick C. rickcort...@gmail.com wrote:
Thanks for the reply. But how can I have multiple icon files in the bundle
and then choose the one I want?
Alter the app's Info.plist, I suppose (and then call LaunchServices to tell it
to re-register, so it'll notice the
On 22 Jan 2015, at 14:11, Jens Alfke wrote:
Alter the app's Info.plist, I suppose (and then call LaunchServices to
tell it to re-register, so it'll notice the changes.)
For this to work, you need to exclude the Info.plist from the app
bundle’s signature.
If the OP insists on adapting the
On Thu, Jan 22, 2015, at 01:03 AM, Rick C. wrote:
Thanks for the reply. But how can I have multiple icon files in the
bundle and then choose the one I want?
You can't.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do
On Sat, 9 Aug 2008 15:19:08 -0700, Shawn Erickson [EMAIL PROTECTED]
said:
On Sat, Aug 9, 2008 at 2:46 PM, Mark Allan [EMAIL PROTECTED] wrote:
I fail to see how [NSApp setApplicationIconImage:theNewImage]; is any
different to [NSApp setApplicationIconImage:[theNewImage objectAtIndex:1
On Fri, Aug 8, 2008 at 9:02 AM, Matt Neuburg [EMAIL PROTECTED] wrote:
Wrap each call to setApplicationIconImage in an autorelease pool creation
and release, like this:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSApp setApplicationIconImage: whatever
On or about 8/10/08 4:37 PM, thus spake Kyle Sluder
[EMAIL PROTECTED]:
On Fri, Aug 8, 2008 at 9:02 AM, Matt Neuburg [EMAIL PROTECTED] wrote:
Wrap each call to setApplicationIconImage in an autorelease pool creation
and release, like this:
NSAutoreleasePool *pool = [[NSAutoreleasePool
On Sun, Aug 10, 2008 at 8:04 PM, Matt Neuburg [EMAIL PROTECTED] wrote:
That's perhaps perfectly true. But later could be a LOT later - and in the
meantime quite a lot of memory could pile up. For example, it is the nature
of the Cocoa event loop that the autorelease pool gets cleaned out when
icon, which works fine and looks
great, but unfortunately, it appears to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.
Wrap each call to setApplicationIconImage in an autorelease pool
not being monumentally stupid first!
I'm trying to animate my app's Dock icon, which works fine and looks
great, but unfortunately, it appears to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.
Wrap
setApplicationIconImage:theNewImage]; is any
different to [NSApp setApplicationIconImage:[theNewImage
objectAtIndex:1]] but it obviously does function differently.
Mark
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests
On Sat, Aug 9, 2008 at 2:46 PM, Mark Allan [EMAIL PROTECTED] wrote:
I fail to see how [NSApp setApplicationIconImage:theNewImage]; is any
different to [NSApp setApplicationIconImage:[theNewImage objectAtIndex:1]]
but it obviously does function differently.
Please post a complete code example
to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.
Wrap each call to setApplicationIconImage in an autorelease pool creation
and release, like this:
NSAutoreleasePool *pool
Ok, stupid question time.
1. Is the need for the autorelease pool because of the use of
setApplicationIconImage, or because of the array that is being used in
conjunction with setApplicationIconImage?
2. Would putting the calls to setApplicationIconImage in a class
method also stop the memory
to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.
Wrap each call to setApplicationIconImage in an autorelease pool creation
and release, like this:
NSAutoreleasePool *pool
icon, which works fine and looks
great, but unfortunately, it appears to leak memory like crazy.
Every time I call [NSApp setApplicationIconImage:(NSImage *)] and
pass it pointer to an existing image, it leaks more memory.
Wrap each call to setApplicationIconImage in an autorelease pool creation
27 matches
Mail list logo
