Re: Core Animation animations stop prematurely at random
On May 16, 2011, at 8:11 AM, Bill Cheeseman wrote: When I quit and relaunch the application, the animations sometimes don't run for the full specified duration when I hit the hot key. During any given run of the application, the animations either work correctly every time I hit the hot key, or they stop prematurely every time I hit the hot key. Answering my own question: Although it's hard to be sure that a random problem is really fixed, it appears that the solution was to stop creating Core Animation layers in the view's -initWithFrame: method and instead create them in the view's -awakeFromNib method. I was aware that the layer tree should not be built (with -addSublayer) in -initWithFrame:, but none of the commentaries I read suggested to me that you can't even create the layers in -initWithFrame: and store them in iVars for later use. -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Closing an app with the red dot.
I understand this is not the way to close an application, but once someone does use the red dot, is there a way to get the program out of the background and back on the screen? JIM ROGERS jimrogers_w4...@me.com http://web.me.com/jimrogers_w4atk ___ 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: Closing an app with the red dot.
Jim Do you realise that this is a mailing list for software developers? Nonetheless, assuming you don't mean programatically, simply click on the application in the Dock. Joanna -- Joanna Carter Carter Consulting ___ 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: Closing an app with the red dot.
I am a cocoa developer, albeit a new one. So I have every right to post this question on this site. Thank you very much, but clicking on the application in the dock does not work in my case. That would be a rather obvious answer and one of the many things I tried. Based on some of the web guru sites, I am not the first to pose this question and a not willing to accept the answer I see most, that is the way Mac works. That is why I came to this site, as a last resort. You have a nice day Joanna. Jim On May 17, 2011, at 6:35 AM, Joanna Carter wrote: Jim Do you realise that this is a mailing list for software developers? Nonetheless, assuming you don't mean programatically, simply click on the application in the Dock. Joanna -- Joanna Carter Carter Consulting JIM ROGERS jimrogers_w4...@me.com http://web.me.com/jimrogers_w4atk ___ 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: Closing an app with the red dot.
when you 'close' the window - by default the application is not being terminated - you can get your window back programmatically by calling [myWindow makeKeyAndOrderFront]. This is what some apps call, when you click their icon on dock to get the closed window back. You can legally terminate application by closing its window as well if you return YES in the method -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)theApplication of your application's delegate. 2011/5/17 JAMES ROGERS jimrogers_w4...@me.com: I am a cocoa developer, albeit a new one. So I have every right to post this question on this site. Thank you very much, but clicking on the application in the dock does not work in my case. That would be a rather obvious answer and one of the many things I tried. Based on some of the web guru sites, I am not the first to pose this question and a not willing to accept the answer I see most, that is the way Mac works. That is why I came to this site, as a last resort. You have a nice day Joanna. Jim On May 17, 2011, at 6:35 AM, Joanna Carter wrote: Jim Do you realise that this is a mailing list for software developers? Nonetheless, assuming you don't mean programatically, simply click on the application in the Dock. Joanna -- Joanna Carter Carter Consulting JIM ROGERS jimrogers_w4...@me.com http://web.me.com/jimrogers_w4atk ___ 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/eveningnick%40gmail.com This email sent to eveningn...@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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Closing an app with the red dot.
JAMES ROGERS jimrogers_w4...@me.com writes:
I am a cocoa developer, albeit a new one. So I have every right to
post this question on this site. Thank you very much, but clicking on
the application in the dock does not work in my case. That would be a
rather obvious answer and one of the many things I tried. Based on
some of the web guru sites, I am not the first to pose this question
and a not willing to accept the answer I see most, that is the way
Mac works. That is why I came to this site, as a last resort.
The red button on windows doesn't impact the application (unless it's so
programmed), but only the window.
It sends the windowShouldClose: message to the window or window
delegate, and if it doesn't return NO, it sends the message close: to
the window.
(The application could override -[NSWindow close:] and do something
else, or could return NO from windowShouldClose: and do something else
(eg. hidding the window) instead.)
Now, it's up to the application to leave a mean to resume working when
all the windows are closed. The way it's done depends on the
application, but the only thing that will remain after all the windows
are closed or hidden, for the user to command the application, is the
menus.
So you should have an item in a menu that will order an action, such as
the opening of a new window. It is often with the menu File, item
Open... that the user will be able to open a new document window to
resume working with the application.
But some applications are not document centered. You may propose a
menu Game / item New Game, or a menu Activity / item New Processing
or whatever.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
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:closing app with the red dot
Thanks to Nick and Pascal the issue is closed, successfully. Jim JIM ROGERS, W4ATK w4...@bellsouth.net http://web.me.com/jimrogers_w4atk K3/100 P3 K2/10 JIM ROGERS jimrogers_w4...@me.com http://web.me.com/jimrogers_w4atk ___ 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
Thumbnail view like iPhone Photos app
Dear all, I used to ask one question about NSCache. Actually, I need to build a view like the 'Photos' application. Now it works, but need to be improved: the speed of dragging, loading images is not good enough. Please give me some general ideas on how to load images on time and manage the cached memory. Thanks! -- Best regards Leon ___ 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: Closing an app with the red dot.
On May 17, 2011, at 8:08 AM, Pascal J. Bourguignon wrote: JAMES ROGERS jimrogers_w4...@me.com writes: I am a cocoa developer, albeit a new one. So I have every right to post this question on this site. I think Joanna can be forgiven for an honest misunderstanding. Thank you very much, but clicking on the application in the dock does not work in my case. Yes it does. It brings your app back to the foreground, which is the literal question you asked. That would be a rather obvious answer and one of the many things I tried. Based on some of the web guru sites, I am not the first to pose this question and a not willing to accept the answer I see most, that is the way Mac works. I agree, that is not the right answer. [...] Now, it's up to the application to leave a mean to resume working when all the windows are closed. The way it's done depends on the application, but the only thing that will remain after all the windows are closed or hidden, for the user to command the application, is the menus. So you should have an item in a menu that will order an action, such as the opening of a new window. It is often with the menu File, item Open... that the user will be able to open a new document window to resume working with the application. In a document-based application the default is to create a new untitled window. You can tell it not to by implementing applicationShouldHandleReopen:hasVisibleWindows: in the app delegate. But it sounds like your app is not document-based. But some applications are not document centered. You may propose a menu Game / item New Game, or a menu Activity / item New Processing or whatever. Yup. Or if there is a specific singleton window, and it lives in MainMenu.nib, you can simply connect the menu item to it in IB with an action of makeKeyAndOrderFront:. In this case make sure to uncheck the Release When Closed checkbox, so the window instance doesn't get prematurely deallocated. Also you can implement the applicationShouldHandleReopen:hasVisibleWindows: method mentioned above to automatically reopen the window, if you prefer. --Andy ___ 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: Closing an app with the red dot.
On May 17, 2011, at 8:44 AM, Andy Lee wrote: Also you can implement the applicationShouldHandleReopen:hasVisibleWindows: method mentioned above to automatically reopen the window, if you prefer. Though I'm not sure as a user I'd like that. Maybe that is what people meant when they said that is the way Mac works. --Andy ___ 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
2 Quick questions about my iOS App and the Apple Developer program
I'm just beginning to learn about Cocoa-Touch programming, so it will be awhile. Eventually, I would like to upload the intermediate stages of my iOS App to my iPad just for testing. I am very familiar with the iOS software simulator, but I would like to use my iPad as a test platform, the real mcCoy, so to speak. I have registered (free version) as a Apple Developer. Do I have to formally be a Apple Developer ($99 per year) to get my pre-release iOS App onto my iPad? Finally, for every year I have my final iOS App in the App Store, do I have to shell out $99. I don't know if this influences the answer to the final question, but I fully intend to offer whatever iApp(s) I develop for free. Thanks in advance, John Love Touch the Future! Teach! ___ 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: 2 Quick questions about my iOS App and the Apple Developer program
On May 17, 2011, at 9:35 AM, John Love wrote: Do I have to formally be a Apple Developer ($99 per year) to get my pre-release iOS App onto my iPad? Yes. Finally, for every year I have my final iOS App in the App Store, do I have to shell out $99. Yes. I don't know if this influences the answer to the final question, but I fully intend to offer whatever iApp(s) I develop for free. Doesn't influence the answer. HTH, --Andy ___ 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: Thumbnail view like iPhone Photos app
Well give us something to go on at least! What did you use to build it? What have tried so far in profiling/improving the performance? On 17 May 2011, at 13:35, Leon Qiao wrote: Dear all, I used to ask one question about NSCache. Actually, I need to build a view like the 'Photos' application. Now it works, but need to be improved: the speed of dragging, loading images is not good enough. Please give me some general ideas on how to load images on time and manage the cached memory. Thanks! -- Best regards Leon ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Closing an app with the red dot.
I am a cocoa developer, albeit a new one. So I have every right to post this question on this site. I think Joanna can be forgiven for an honest misunderstanding. My apologies; I also moderate other technical newsgroups and it is sometimes easy to jump to the wrong conclusion, especially when the OP doesn't mention anything to do with programming :-) Joanna -- Joanna Carter Carter Consulting ___ 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: Closing an app with the red dot.
Joanna, No problem. I should have phrased it better. After many exchanges the simplest and best solution for this particular application came from Andy, just disable the button. I am a retired Senior Systems Analyst and certainly can be guilty of tossing a few stones at glass houses. Picking up a new language at 77 is a challenge. Very best regards, Jim On May 17, 2011, at 9:07 AM, Joanna Carter wrote: I am a cocoa developer, albeit a new one. So I have every right to post this question on this site. I think Joanna can be forgiven for an honest misunderstanding. My apologies; I also moderate other technical newsgroups and it is sometimes easy to jump to the wrong conclusion, especially when the OP doesn't mention anything to do with programming :-) Joanna -- Joanna Carter Carter Consulting ___ 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/jimrogers_w4atk%40me.com This email sent to jimrogers_w4...@me.com JIM ROGERS jimrogers_w4...@me.com http://web.me.com/jimrogers_w4atk ___ 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: Core Animation animations stop prematurely at random
On May 17, 2011, at 1:26 AM, Bill Cheeseman wrote: Answering my own question: Although it's hard to be sure that a random problem is really fixed, it appears that the solution was to stop creating Core Animation layers in the view's -initWithFrame: method and instead create them in the view's -awakeFromNib method. I was aware that the layer tree should not be built (with -addSublayer) in -initWithFrame:, but none of the commentaries I read suggested to me that you can't even create the layers in -initWithFrame: and store them in iVars for later use. There should be no actual restriction like that however. That said, as you point out, if you have view that supports layers and come from a nib, you often have to duplicate work to allow it to work in both situations. -- David Duncan ___ 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: Closing an app with the red dot.
On 17.05.2011, at 14:54, Andy Lee wrote: On May 17, 2011, at 8:44 AM, Andy Lee wrote: Also you can implement the applicationShouldHandleReopen:hasVisibleWindows: method mentioned above to automatically reopen the window, if you prefer. Though I'm not sure as a user I'd like that. Maybe that is what people meant when they said that is the way Mac works. Doesn't matter what you like as a user, you're a programmer :-p Seriously, many applications on the Mac work that way. Close all windows in Mail.app and click on the dock: Presto! New mail window. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.masters-of-the-void.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: Closing an app with the red dot.
This is a classic instance of having to look at the nature or the application to decide if it is an appropriate action. I use both models depending upon the application. The general approach I take is to look at the app in question determine if there is any legitimate reason it should stay open when the main window is closed. EG. Suppose the application is a simple dialog based app, take for example an app I use once or twice a week to decrypt Cisco Group Names from .ini config files. Once I've displayed the decrypted password on screen, and closed the window, should the app remain loaded? I would argue no. it is small enough that reloading it is not an issue, so closing the last window closes the app. The inverse of this is a document based app. I cannot come up with many reasons a document app should ever exit when the last document window is closed. This is counter to how Windows devs would function and as many new MAc devs bring some of those notions, it is something to be aware of. In other words, think long and hard before implementing a behavior that is non-standard to the platform, or you quickly find yourself in the 'Why am I using an app tthe feels like a Windows App on the Mac?' conundrum -- Andy 'Dru' Satori On Tuesday, May 17, 2011 at 11:40 AM, Uli Kusterer wrote: On 17.05.2011, at 14:54, Andy Lee wrote: On May 17, 2011, at 8:44 AM, Andy Lee wrote: Also you can implement the applicationShouldHandleReopen:hasVisibleWindows: method mentioned above to automatically reopen the window, if you prefer. Though I'm not sure as a user I'd like that. Maybe that is what people meant when they said that is the way Mac works. Doesn't matter what you like as a user, you're a programmer :-p Seriously, many applications on the Mac work that way. Close all windows in Mail.app and click on the dock: Presto! New mail window. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.masters-of-the-void.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/dru%40druware.com This email sent to d...@druware.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: Core Animation animations stop prematurely at random
On May 17, 2011, at 11:33 AM, David Duncan wrote: There should be no actual restriction like that however. That said, as you point out, if you have view that supports layers and come from a nib, you often have to duplicate work to allow it to work in both situations. I'm not sure I follow you. I am aware that there are a number of commentaries explaining that loading a nib file that contains accessibility settings interferes with a layer tree that was constructed in code before the nib was loaded -- hence the recommendation to construct the layer tree in -awakeFromNib, not in -initWithFrame:. However, my view's nib file does not use any of the Interface Builder accessibility features, so I'm not at all clear why I should have run afoul of this issue. Apple's documentation on the point is quite cryptic. -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why RunLoop?
Dear Bill,
You are right. Polling is not good.
But I noticed that Cocoa threading provides wait/pulse-like synchronization
techniques, such as Condition. I believe these techniques can be used to
control a thread which has a while-true loop. So I think RunLoop can be
replaced. Do you think so?
Best,
Bing
On Tue, May 17, 2011 at 5:45 AM, Bill Bumgarner b...@mac.com wrote:
In short, do **not** poll. Not ever.
If you are doing something like this:
while (stillDontGotIt) {
sleepForAMomentAndHopeWeGetIt();
}
(or the obvious spin-and-try-lock variant).
Then you are doing it wrong.
It eats CPU, makes your app less responsive, eats battery life, and is less
efficient. Far far more efficient is to set up various triggers or points
of coordination -- queues, callbacks, run loop events, etc… -- through which
your app will be notified when something is ready to be processed.
b.bum
___
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: Core Animation animations stop prematurely at random
On May 17, 2011, at 9:49 AM, Bill Cheeseman wrote: On May 17, 2011, at 11:33 AM, David Duncan wrote: There should be no actual restriction like that however. That said, as you point out, if you have view that supports layers and come from a nib, you often have to duplicate work to allow it to work in both situations. I'm not sure I follow you. I am aware that there are a number of commentaries explaining that loading a nib file that contains accessibility settings interferes with a layer tree that was constructed in code before the nib was loaded -- hence the recommendation to construct the layer tree in -awakeFromNib, not in -initWithFrame:. However, my view's nib file does not use any of the Interface Builder accessibility features, so I'm not at all clear why I should have run afoul of this issue. Apple's documentation on the point is quite cryptic. The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again. As such, if you did anything that relied on the view being layer backed (such as setting its layer and manipulating the layer tree) then that work needs to be done again. However, this should not apply to any layers you create that aren't implanted into the view. You should be able to create layers to your hearts content inside of -initWithFrame: as long as you don't try to manipulate the view's layer tree. As such your statement that you couldn't create layers there seems to be indicative of some other issue. My addendum is if you are creating a view that should both support loading from a nib, and creation purely in code. In that situation, you basically need to duplicate the layer setup code, since -awakeFromNib won't be called in the programmatic case, while in the nib case you may need to re-do some work that is done in -initWithFrame:. If only nib loading called -initWithCoder: on Mac OS X :). -- David Duncan ___ 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: Why RunLoop?
On May 17, 2011, at 9:54 AM, Bing Li wrote: Dear Bill, You are right. Polling is not good. But I noticed that Cocoa threading provides wait/pulse-like synchronization techniques, such as Condition. I believe these techniques can be used to control a thread which has a while-true loop. So I think RunLoop can be replaced. Do you think so? Just because a facility is provided (Condition locks) for does not mean that it can be used to replace another facility (Run Loops). Run Loops do and provide more than what you can do with the techniques you mention, including things that you cannot easily (if at all) replicate. -- David Duncan ___ 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: Core Animation animations stop prematurely at random
The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again Would there be any issue with overriding -setWantsLayer: to drop the [view setWantsLayer:NO] invocation, only allowing [view setWantsLayer:YES] to pass through to the NSView implementation? thanks, Keith ___ 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: Core Animation animations stop prematurely at random
On Tue, May 17, 2011 at 10:21 AM, Keith Duncan ke...@33software.com wrote: The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again Would there be any issue with overriding -setWantsLayer: to drop the [view setWantsLayer:NO] invocation, only allowing [view setWantsLayer:YES] to pass through to the NSView implementation? Well, there's no guarantee that nib loading goes through -setWantsLayer:. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Closing an app with the red dot.
On Tue, May 17, 2011 at 8:56 AM, Andy 'Dru' Satori d...@druware.com wrote: This is a classic instance of having to look at the nature or the application to decide if it is an appropriate action. I use both models depending upon the application. The general approach I take is to look at the app in question determine if there is any legitimate reason it should stay open when the main window is closed. The approach you should take is outlined in the HIG: http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/XHIGWindows.html#//apple_ref/doc/uid/2961-TPXREF56 In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window. I'd say this is roughly equivalent to your approach. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Creating an iPad-specific xib in IB
I'm making an iPad-only view-based app. The large screen size of the iPad will be split into 4 views, each operating independently, so the iPad is a perfect fit. However, in Interface Builder, the default xibs that are created with the project appear to be iPhone-sized. How do I get IB to offer me an iPad-sized canvas? Do I resize the one that's there, and if so, to what size? Isn't there a setting for this somewhere in Xcode 3.2.6? ___ 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: Creating an iPad-specific xib in IB
Okay, fishing through the menus, I found Create iPad Version. Cool. On May 17, 2011, at 10:48 AM, Nathan Sims wrote: I'm making an iPad-only view-based app. The large screen size of the iPad will be split into 4 views, each operating independently, so the iPad is a perfect fit. However, in Interface Builder, the default xibs that are created with the project appear to be iPhone-sized. How do I get IB to offer me an iPad-sized canvas? Do I resize the one that's there, and if so, to what size? Isn't there a setting for this somewhere in Xcode 3.2.6? ___ 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: Core Animation animations stop prematurely at random
On May 17, 2011, at 12:58 PM, David Duncan wrote: The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again. As such, if you did anything that relied on the view being layer backed (such as setting its layer and manipulating the layer tree) then that work needs to be done again. I get it. Thanks. However, this should not apply to any layers you create that aren't implanted into the view. You should be able to create layers to your hearts content inside of -initWithFrame: as long as you don't try to manipulate the view's layer tree. As such your statement that you couldn't create layers there seems to be indicative of some other issue. I agree that the explanation doesn't logically lead to a prohibition on creating layers in -initWithFrame:. That's why I initially created them there, deferring only the construction of the layer tree to -awakeFromNib. But I suffered random failures -- in fact, the application failed more often than not. The randomness is consistent with my doing something to which the phrase undefined behavior is often applied in Apple documentation. Now that I've moved the layer creation to -awakeFromNib, however, my application is working correctly 100% of the time. 100% of past time, that is. As to future time, I don't know yet. ;- That's the trouble with random failures -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Animation animations stop prematurely at random
On Tue, May 17, 2011 at 11:35 AM, Bill Cheeseman wjcheese...@gmail.com wrote: I agree that the explanation doesn't logically lead to a prohibition on creating layers in -initWithFrame:. That's why I initially created them there, deferring only the construction of the layer tree to -awakeFromNib. But I suffered random failures -- in fact, the application failed more often than not. The randomness is consistent with my doing something to which the phrase undefined behavior is often applied in Apple documentation. Now that I've moved the layer creation to -awakeFromNib, however, my application is working correctly 100% of the time. You could also try using -makeBackingLayer. That's useful if your view can be used both programmatically and in a nib. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why RunLoop?
On 17 May 2011, at 9:54 AM, Bing Li wrote: But I noticed that Cocoa threading provides wait/pulse-like synchronization techniques, such as Condition. I believe these techniques can be used to control a thread which has a while-true loop. So I think RunLoop can be replaced. Do you think so? In a thread that you own, you can certainly write in a style that does not use a run loop, and this is sometimes the best approach. However, if you are writing a GUI application, the main thread must be run loop based for the application to work, because Cocoa relies on the run loop. The disadvantage of blocking on a Condition (or pthread mutex, etc.) is that the thread cannot respond to anything else while it is blocked there. An application must respond to a wide variety of things at any time. A run loop allows this to happen, but avoids many of the headaches involved with multithreaded programming (and you can always use threads in addition to run loops if that makes sense). On 17 May 2011, at 11:37 AM, Bing Li wrote: Actually, I have tried a lot of time to find tutorials about how to program RunLoop. Unfortunately, samples in the Apple Developer site are large and no explanations. I have got more than 10 books. No one explains RunLoop at all. Could you please offer me a small sample or some resources to learn RunLoop? Here are some pages which might help you: http://en.wikipedia.org/wiki/Event_loop http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html especially Anatomy of a Run Loop and When Would You Use a Run Loop? http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html ___ 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
Unrecognized document type
With Xcode 3.2.6, I am getting the (well-discussed) error The OutType type doesn't map to any NSDocumentClass. after theOutDoc = [[NSDocumentController sharedDocumentController] makeUntitledDocumentOfType:@OutType error:outError]; I cannot see where I went wrong. My AppDelegate plist shows the four types of documents that the app is supposed to recognize, all with correct names. As a test, I even called [NSDocumentController sharedDocumentController] documentClassNames] to see what it thought the corresponding classes were supposed to be and all came out correct. Yet, I still get this error. To make matters worse, I have another project with analogous code that works perfectly. Can anyone offer a tip as to where to look next? [I have tried cleaning and rebuilding to no avail.] TIA. -- Mike McLaughlin ___ 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: Unrecognized document type
On Tue, May 17, 2011 at 12:24 PM, McLaughlin, Michael P. mp...@mitre.org wrote: With Xcode 3.2.6, I am getting the (well-discussed) error The OutType type doesn't map to any NSDocumentClass. after theOutDoc = [[NSDocumentController sharedDocumentController] makeUntitledDocumentOfType:@OutType error:outError]; You should be using the document type's UTI here. The old-style NSDocument type names are deprecated. I cannot see where I went wrong. My AppDelegate plist shows the four types of documents that the app is supposed to recognize, all with correct names. You mean your Info.plist. Post that here so we can make sure you've filled out all the appropriate keys. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Animation animations stop prematurely at random
On May 17, 2011, at 2:58 PM, Kyle Sluder wrote: You could also try using -makeBackingLayer. That's useful if your view can be used both programmatically and in a nib. I wonder if that method works for a layer-hosting view, which is what my view is -- not a layer-backed view. But even if it can be used in creating a layer-hosting view, I don't understand what it might accomplish. -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Memory growing and growing when using UIImageView's image
Hello.
UI have 2 UUIImageView which Im sliding in/out to display some images, but each
time the new image slides in the memory keeps growing and growing and growing
even I set to nil the image of the outgoing UIImageview.
This is what Im doing.
Please any help will be very appreciate it.
-(void)nextImage{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
if(indexActualImage +1 [images count]){
if(self.currentImageView.superview){
indexActualImage ++;
self.nextImageView.image = [UIImage imageNamed:[[images
objectAtIndex:indexActualImage]bigImageName]];
CGRect bounds = self.view.bounds;
bounds.origin= CGPointMake(bounds.size.width,0);
self.nextImageView.frame = bounds;
[self.view insertSubview:self.nextImageView
belowSubview:toolBarView];
[UIView animateWithDuration:0.5
animations:^{
self.currentImageView.center =
CGPointMake(-self.currentImageView.bounds.size.width/2,
self.currentImageView.center.y);
self.nextImageView.center =
CGPointMake(self.nextImageView.bounds.size.width/2,
self.nextImageView.center.y);
}
completion:^(BOOL finished){
self.currentImageView.image = nil;
[self.currentImageView removeFromSuperview];
[self performSelector:@selector(fireTimer)
withObject:nil afterDelay:4.0];
}];
}
else if(self.nextImageView.superview){
indexActualImage ++;
self.currentImageView.image = [UIImage imageNamed:[[images
objectAtIndex:indexActualImage]bigImageName]];
CGRect bounds = self.view.bounds;
bounds.origin= CGPointMake(bounds.size.width,0);
self.currentImageView.frame = bounds;
[self.view insertSubview:self.currentImageView
belowSubview:toolBarView];
[UIView animateWithDuration:0.5
animations:^{
self.nextImageView.center =
CGPointMake(-self.nextImageView.bounds.size.width/2,
self.nextImageView.center.y);
self.currentImageView.center =
CGPointMake(self.currentImageView.bounds.size.width/2,
self.currentImageView.center.y);
}
completion:^(BOOL finished){
self.nextImageView.image = nil;
[self.nextImageView removeFromSuperview];
[self performSelector:@selector(fireTimer)
withObject:nil afterDelay:4.0];
}];
}
}
else{
indexActualImage = -1;
[self nextImage];
}
[pool drain];
}
Regards
Gustavo
___
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
Has anyone used the VOIP background mode for a non-VOIP app?
The App Store Review Guidelines state (2.16) that Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. There is a background mode plist key (UIBackgroundModes=voip) for apps that provide VOIP services, allowing the app to continue to handle listening and data sockets while in the background. In the discussion for UIBackgroundModes, the doc states that: These keys should be used sparingly and only by applications providing the indicated services. All this taken together suggests that I shouldn't use this key for voip unless I am specifically a VOIP application, or else risk App Store rejection. Is anyone using this form of background mode in an non-VOIP app that's in the app store? Fwiw I would like to be able to run in the background enough to be able to send and receive SSH-level keepalives so that I can keep an SSH session open, given that it's costly to setup in the first place (imho). Thanks in advance... Chris ___ 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
Problems linking json-framework with ios application
All, I am building a library to be used by other apps. I have included the json-framework in the library project and used the -ljson flag as directed. Now this all works fine, until my app uses one of the JSON categories that the library implements. if I add the json-framework to the app it works, so it appears I am doing something wrong as the categories and objects created by the json-framework are not being exported. Has anyone done something similar or can anyone see what I am doing wrong? Damien___ 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: Memory growing and growing when using UIImageView's image
On May 17, 2011, at 1:28 PM, Gustavo Pizano wrote: self.nextImageView.image = [UIImage imageNamed:[[images objectAtIndex:indexActualImage]bigImageName]]; Images loaded with +imageNamed: are cached by your application. This cache should respond to memory warnings, but until you get one your memory usage will keep growing and growing. -- David Duncan ___ 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: Problems linking json-framework with ios application
On May 17, 2011, at 2:03 PM, Damien Cooke wrote: I am building a library to be used by other apps. I have included the json-framework in the library project and used the -ljson flag as directed. Now this all works fine, until my app uses one of the JSON categories that the library implements. if I add the json-framework to the app it works, so it appears I am doing something wrong as the categories and objects created by the json-framework are not being exported. Has anyone done something similar or can anyone see what I am doing wrong? http://developer.apple.com/library/mac/#qa/qa1490 -- 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: Problems linking json-framework with ios application
On 17 May 2011, at 2:03 PM, Damien Cooke wrote: I am building a library to be used by other apps. I have included the json-framework in the library project and used the -ljson flag as directed. Now this all works fine, until my app uses one of the JSON categories that the library implements. This is a problem with ObjC categories and static libraries. Categories do not involve any linker symbols (they're completely dynamic), and files in a static library only get included in the final binary if they are needed to resolve a linker symbol reference (usually this is a nice feature of static libraries but for ObjC it's a nuisance). ObjC *classes* can have this problem as well, especially if you're playing tricks like dynamically registering a class with some manager or controller object in the class's +didLoad. Usually the problem shows up with categories, though. There are a handful of ways to deal with this- - You can link the static library into a single object file (json.o) and link that to your iOS app - You can use a linker flag like -all_load or -ObjC to force the categories to be linked - You can play tricks with defining symbols in the same file as the category implementation and referencing them from any file that relies on that category's existence The third option allows you to keep the fine-grained loading behavior of static libraries, but it requires you to do a lot of manual maintenance of those symbols; I've never actually found it to be worthwhile. ___ 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: Has anyone used the VOIP background mode for a non-VOIP app?
On 17 May 2011, at 3:50 PM, Chris Markle wrote: The App Store Review Guidelines state (2.16) that Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. There is a background mode plist key (UIBackgroundModes=voip) for apps that provide VOIP services, allowing the app to continue to handle listening and data sockets while in the background. In the discussion for UIBackgroundModes, the doc states that: These keys should be used sparingly and only by applications providing the indicated services. All this taken together suggests that I shouldn't use this key for voip unless I am specifically a VOIP application, or else risk App Store rejection. The docs don't _suggest_ voip means VoIP, when you piece them together. They _say_ voip means VoIP, twice. Fwiw I would like to be able to run in the background enough to be able to send and receive SSH-level keepalives so that I can keep an SSH session open, given that it's costly to setup in the first place (imho). The reviewer will read your description of your app. It will say nothing about telephony. Next, he will examine your Info.plist. It will say voip. He may even have software that red-flags that your app claims to do VoIP. He will not open a debate with senior management over what only for its intended purpose means in your case. He will reject your app in 30 seconds and move on to the next of the thousands of apps in the approval queue. The author of the excellent app iSSH devoted a lot of effort to what can be done in the background to keep an SSH connection alive. iSSH registers for the ten-minute grace period with beginBackgroundTaskWithExpirationHandler:. If the user doesn't come back in ten minutes, the connection is lost. — F ___ 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: Has anyone used the VOIP background mode for a non-VOIP app?
All of this - and please file a bug report requesting a way for a background app to have network keep alives (would be good for any app that needs to poll or keep a connection). I've filed a bug report. You should too. That's how Apple determines what's needed. On May 17, 2011, at 5:07 PM, Fritz Anderson wrote: On 17 May 2011, at 3:50 PM, Chris Markle wrote: The App Store Review Guidelines state (2.16) that Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. There is a background mode plist key (UIBackgroundModes=voip) for apps that provide VOIP services, allowing the app to continue to handle listening and data sockets while in the background. In the discussion for UIBackgroundModes, the doc states that: These keys should be used sparingly and only by applications providing the indicated services. All this taken together suggests that I shouldn't use this key for voip unless I am specifically a VOIP application, or else risk App Store rejection. The docs don't _suggest_ voip means VoIP, when you piece them together. They _say_ voip means VoIP, twice. Fwiw I would like to be able to run in the background enough to be able to send and receive SSH-level keepalives so that I can keep an SSH session open, given that it's costly to setup in the first place (imho). The reviewer will read your description of your app. It will say nothing about telephony. Next, he will examine your Info.plist. It will say voip. He may even have software that red-flags that your app claims to do VoIP. He will not open a debate with senior management over what only for its intended purpose means in your case. He will reject your app in 30 seconds and move on to the next of the thousands of apps in the approval queue. The author of the excellent app iSSH devoted a lot of effort to what can be done in the background to keep an SSH connection alive. iSSH registers for the ten-minute grace period with beginBackgroundTaskWithExpirationHandler:. If the user doesn't come back in ten minutes, the connection is lost. — F ___ 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/alex%40webis.net This email sent to a...@webis.net Alex Kac - President and Founder Web Information Solutions, Inc. It is useless for sheep to pass a resolution in favor of vegetarianism while wolves remain of a different opinion. -- William Randolph Inge ___ 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: Has anyone used the VOIP background mode for a non-VOIP app?
On May 17, 2011, at 4:50 PM, Chris Markle wrote: The App Store Review Guidelines state (2.16) that Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. Is anyone using this form of background mode in an non-VOIP app that's in the app store? This is a psychological quiz, right? Let's see if someone, who managed to violate the guidelines and GET AWAY with it, will come on a public list and admit to it. Steve Bird Culverson Software - Elegant software that is a pleasure to use. www.Culverson.com (toll free) 1-877-676-8175 ___ 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: Has anyone used the VOIP background mode for a non-VOIP app?
Steve, This is a psychological quiz, right? Let's see if someone, who managed to violate the guidelines and GET AWAY with it, will come on a public list and admit to it. Yeah I wondered about that... They could always reply directly to me - I don't work for Apple. For a small fee I could keep their secret ;) Chris ___ 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
[MapKit] Question regarding a workaround of one of its shortcomings?
As far as I can tell, OverlayViews are not clickable. So, I'm subclassing MKMapView and overloading the GestureRecognizers actions handlers to deal with that. Considering that these actions handlers are not documented (well, they are through a quick NSLog output), would doing that be considered using private APIs by you-know-who? If it is, is there a more friendly way of doing it? Removing the current GestureRecognizers and adding my owns might be one but I haven't checked the GestureRecognizers API in details yet. ___ 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
-[NSWindow orderOut:] vs. -[NSWindow performClose:]
This seems like it should be such a fundamentally obvious difference, but I've been quite puzzled about it ever since I first started working with Cocoa: when is it more appropriate to call -[NSWindow orderOut:] than -[NSWindow performClose:] (or just plain -close)? At first glance, it appears that -orderOut: is in the window list management portion of the API, while -performClose:/-close are in the window existence management portion. In other words, -orderOut: seems to operate at a lower level than -close, as -close calls -orderOut: (or the moral equivalent). So my gut intuition is that a reusable panel should be hidden with -close, and set to not release when closed, so that it may be recalled later. But then the actual framework has to go mess with this understanding. It is apparent that NSColorWell calls -orderOut: on the shared color panel, and in general there's tons of code out there that calls -orderOut: to dismiss shared panels. Not to mention the method is an IBAction, so it's obviously designed to be called from higher-level code. The documentation is woefully ambiguous: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Tasks/OpeningClosingWindows.html It feels like there are two overlapping entry points in the API: the high level path (-close) that calls into the lower-level path (-orderOut:), but that the lower-level path has gained acceptance as a separate entry point since it implements most of the side effects seen in the high level path. Is this redundancy an artifact of a time before NSWindowController, when one-shot windows and releaseWhenClosed were far more commonplace than they are today? If so, is there any hope for a restructuring of the API in the future? Or does the distinction still exist as an opportunity for the framework client to maintain a distinction between hiding and closing, even where the line is blurry, like in an inspector or other reusable panel? And in the meantime, can someone enlighten me as to why I would ever choose to call -orderOut: instead of -close on a properly-configured reusable panel? --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: -[NSWindow orderOut:] vs. -[NSWindow performClose:]
Hi Kyle. I don't believe there's a distinction here between high level and low level API. Iit's just a simple distinction between being done with the window and not being done with the window. When your app is permanently done with a window and will never display it again, you call -close, whereas if your app may display the window again, you call -orderOut:. As for why there are two methods, -close is closely tied with the NSDocument architecture. It's no coincidence that NSWindow, NSWindowController, and NSDocument all have -close methods: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Documents/Concepts/WindowClosingBehav.html#//apple_ref/doc/uid/2027-BBCBEIEJ I believe that the main purpose not only of -isReleasedWhenClosed but also NSWindowWillCloseNotification is to handle memory management and/or clean up when you're permanently done with a window. Indeed, the link above explains how you would use NSWindowWillCloseNotification for exactly that purpose. The method -orderOut: has no such side effects, because it's meant for temporarily removing a window from the screen, not getting rid of the window altogether. It's true that if you don't release either the window or the window controller when the window closes, then -close is pretty much equivalent to -orderOut:, but I don't think that's how the designers intended people to use the API. -Jeff On May 17, 2011, at 7:12 PM, Kyle Sluder wrote: This seems like it should be such a fundamentally obvious difference, but I've been quite puzzled about it ever since I first started working with Cocoa: when is it more appropriate to call -[NSWindow orderOut:] than -[NSWindow performClose:] (or just plain -close)? At first glance, it appears that -orderOut: is in the window list management portion of the API, while -performClose:/-close are in the window existence management portion. In other words, -orderOut: seems to operate at a lower level than -close, as -close calls -orderOut: (or the moral equivalent). So my gut intuition is that a reusable panel should be hidden with -close, and set to not release when closed, so that it may be recalled later. But then the actual framework has to go mess with this understanding. It is apparent that NSColorWell calls -orderOut: on the shared color panel, and in general there's tons of code out there that calls -orderOut: to dismiss shared panels. Not to mention the method is an IBAction, so it's obviously designed to be called from higher-level code. The documentation is woefully ambiguous: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Tasks/OpeningClosingWindows.html It feels like there are two overlapping entry points in the API: the high level path (-close) that calls into the lower-level path (-orderOut:), but that the lower-level path has gained acceptance as a separate entry point since it implements most of the side effects seen in the high level path. Is this redundancy an artifact of a time before NSWindowController, when one-shot windows and releaseWhenClosed were far more commonplace than they are today? If so, is there any hope for a restructuring of the API in the future? Or does the distinction still exist as an opportunity for the framework client to maintain a distinction between hiding and closing, even where the line is blurry, like in an inspector or other reusable panel? And in the meantime, can someone enlighten me as to why I would ever choose to call -orderOut: instead of -close on a properly-configured reusable panel? ___ 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: -[NSWindow orderOut:] vs. -[NSWindow performClose:]
On Tue, May 17, 2011 at 5:55 PM, Jeff Johnson publicpost...@lapcatsoftware.com wrote: I believe that the main purpose not only of -isReleasedWhenClosed but also NSWindowWillCloseNotification is to handle memory management and/or clean up when you're permanently done with a window. Indeed, the link above explains how you would use NSWindowWillCloseNotification for exactly that purpose. The method -orderOut: has no such side effects, because it's meant for temporarily removing a window from the screen, not getting rid of the window altogether. It's true that if you don't release either the window or the window controller when the window closes, then -close is pretty much equivalent to -orderOut:, but I don't think that's how the designers intended people to use the API. Well, perhaps it will be helpful to elaborate on why the two methods seem so similar in my case. I have a multiple-window, but not document-based app. Think similar to iTunes, including the sidebar, but it supports multiple windows. I've got a shared New/Edit Item panel. The items it creates live in the sidebar of the app's windows. This panel can be summoned by a toolbar item or a menu item. The menu item can also be used to dismiss the panel, consistent with system panels like the Font or Colors panel. When the panel is summoned, I want the panel to remember the document window on whose toolbar item the user clicked, or none if the panel was summoned by the menu item. This is because I want to bring that window forward when I dismiss the panel, or if the menu item was used I will just bring the frontmost document window forward. So when I bring up the panel, I register as an observer of the document window's NSWindowWillCloseNotification. If the document window disappears while the panel is still visible, my panel removes itself as an observer of the close notification and forgets about the now-dying document window, reverting to the same behavior as if it was summoned by the menu item. Likewise, I need to deregister for notifications when I dismiss the panel first (the typical case). So I figured the panel's window controller's -windowWillClose: method is the right place to do that. But the toggle functionality sends -orderOut: to the panel, consistent with how system panels are dismissed. This, of course, will not send -windowWillClose:. I could easily change my code to call -close instead of -orderOut:. But every time I have to choose between -orderOut: and -close, this question arises, and I figured I should just go ahead and ask it. It feels like close semantics are appropriate for my dismissing my search panel, rather than hide. But the question remains why -orderOut: is so prevalent when dealing with panels that exhibit similar modality, like color wells which cause the shared color panel to attach themselves. It also doesn't help my understanding that the close button isn't wired up to plain -orderOut:. So clicking the close button on a system standard panel follows a different code path than a lot of code out there. Maybe this is an indication that, according to the framework's logic, my panel's window controller should have a documentWindow property, and that both -windowWillClose: and whoever calls -orderOut: should be responsible for resetting that property. After all, that could very well be how NSColorWell is implemented. That seems rather redundant and fragile, though. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Temporarily enabling layer backing for NSView
Hi all,
I'm trying to use CATransition in my app to provide an animated slide
transition when swapping views. I don't want to permanently layer back my views
because they cause various glitches (no subpixel antialiasing, resize issues
when backed with a CATiledLayer, etc.) To get around this, I want to
temporarily layer back my view, run the animation, and then disable layer
backing after the animation completes. This is my code thus far:
CATransition *transition = [CATransition animation];
transition.type = kCATransitionPush;
transition.subtype = kCATransitionFromLeft;
transition.timingFunction = [CAMediaTimingFunction
functionWithName:kCAMediaTimingFunctionEaseInEaseOut];
[parentView setWantsLayer:YES];
[CATransaction begin];
[CATransaction setCompletionBlock:^(void) {
[parentView setWantsLayer:NO];
}];
[parentView setAnimations:[NSDictionary dictionaryWithObject:transition
forKey:@subviews]];
[[parentView animator] replaceSubview:firstView with:secondView];
[CATransaction commit];
With this code, the animation doesn't run (the views just get swapped without
animation but the completion block is still called). The problem seems to be
the fact that I'm calling -setWantsLayer: immediately before the animation
begins. If I call this method in -awakeForNib, the animation will run. I'm
thinking that this might be some sort of runloop issue, but I have no idea what
I can do to work around this. I've tried moving my -setWantsLayer: call to
various places within the animation method but this has no effect.
Any help is greatly appreciated.
Thanks,
Indragie
http://indragie.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
Application never becomes frontmost. How?
So I'm trying to develop an app that runs as an NSStatusItem, but it keeps bringing itself to the foreground whenever a window belonging to it is left-clicked on. And that's no good. I want it to stay in the background at all times -no matter what-(which has to be possible because Accessibility Inspector and Classic Menu both do it), or failing that, at least relinquish control back to the previous foreground app after its window has been closed. I've got no idea how to accomplish either of those things. My app is already an LSUIElement, so that doesn't do the trick. LSBackgroundOnly makes its windows un-focusable, which sucks even harder. There's probably a simple solution to all of this. But I can't find it. Help? ___ 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
Reducing AVCaptureVideoDataOutput framerate
I'm developing a barcode scanner application, specifically for the
iPhone/iPod Touch. I'm using the ZXing open source library in conjunction
with AVCaptureVideoDataOutput and sampleBufferDelegate to decode QRCodes
from the video camera.
I'm trying to reduce the frame rate to the sampleBufferDelegate so the ZXing
library doesn't decode 30 frame per second. Something like 10 fps might be
more practical.
But when I do this (which should reduce it down to 1 fps):
captureOutput.minFrameDuration = CMTimeMake(1, 1);
Nothing seems to be different. The AVCaptureVideoPreviewLayer isn't affected
at all, and the sampleBufferDelegate seems to be processing just as many
frames as before.
This is my init function:
- (id)init
{
self = [super init];
if(self)
{
AVCaptureDevice *captureDevice = [AVCaptureDevice
defaultDeviceWithMediaType:AVMediaTypeVideo];
captureInput = [[AVCaptureDeviceInput alloc]
initWithDevice:captureDevice error:nil];
captureOutput = [[AVCaptureVideoDataOutput alloc] init];
captureSession = [[AVCaptureSession alloc] init];
[captureOutput setVideoSettings:[NSDictionary
dictionaryWithObject:[NSNumber numberWithInt:kCVPixelFormatType_32BGRA]
forKey:(id)kCVPixelBufferPixelFormatTypeKey]];
[captureOutput setAlwaysDiscardsLateVideoFrames:YES];
[captureOutput setSampleBufferDelegate:self
queue:dispatch_get_main_queue()];
[captureSession setSessionPreset:AVCaptureSessionPresetMedium];
[captureSession addInput:captureInput];
[captureSession addOutput:captureOutput];
// Isn't doing anything?
captureOutput.minFrameDuration = CMTimeMake(1, 1);
scanner = nil;
delegage = nil;
preview_ = nil;
previewLayer = [[AVCaptureVideoPreviewLayer alloc]
initWithSession:captureSession];
}
return self;
}
Does anyone know why this isn't working?
Luke
___
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: Application never becomes frontmost. How?
On May 17, 2011, at 10:15 AM, banned_acco...@lavabit.com wrote: There's probably a simple solution to all of this. But I can't find it. Help? NSNonactivatingPanelMask? -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: [MapKit] Question regarding a workaround of one of its shortcomings?
Solved. Saving the original gesture recognizers and replacing them with other ones works well. On Tue, May 17, 2011 at 5:10 PM, Stephane Sudre dev.iceb...@gmail.com wrote: As far as I can tell, OverlayViews are not clickable. So, I'm subclassing MKMapView and overloading the GestureRecognizers actions handlers to deal with that. Considering that these actions handlers are not documented (well, they are through a quick NSLog output), would doing that be considered using private APIs by you-know-who? If it is, is there a more friendly way of doing it? Removing the current GestureRecognizers and adding my owns might be one but I haven't checked the GestureRecognizers API in details yet. ___ 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
