Re: Disabling screen capture
Sent from my iPad On Feb 22, 2014, at 12:27 AM, Gary L. Wade garyw...@desisoftsystems.com wrote: You did go to this page, right? https://developer.apple.com/membercenter/index.action#requestTechSupport Yep, that's the one. I remembered one form on the site, not this one, that I had to submit by deleting all the data and doing it again. Some freaky web page issue; I think it was a phone number field that kept trying to be reformatted but in a way the back end didn't like it, so I turned off JavaScript while filling it in and then submitted it. If things still don't work, try emailing d...@apple.com and explain this issue and your real issue. Yeah, I have a strong suspicion that there is a bug in the web page, and I'd lay money that it is due to the apostrophe in my last name. I deal with this problem continually -- web developers who script with single quotes don't allow for last names with a single quote (apostrophe) in them, and thus their string processing is abruptly terminated early and appears as if data wasn't sent, when it actually was. The enter all required data points pretty strongly to that being the case here. I'd guess I encounter this problem about half the time on web sites, and often just going and altering my last name to remove the apostrophe solves the problem. Unfortunately, it appears the you can't change your name in your Dev account profile anymore -- that requires contacting Dev program support as well. So I filled out yet another form for Dev program support, which luckily allowed me to submit. Hopefully we can get the problem ironed out quickly. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ On Feb 21, 2014, at 8:13 PM, Bradley O'Hearne br...@bighillsoftware.com wrote: On Feb 21, 2014, at 3:02 PM, Jens Alfke j...@mooseyard.com wrote: The best answer I’ve seen is that you’ll need to file a DTS support incident and go through those official channels. I’ve spent the last hour trying to post an issue to DTS via the Apple Mac Developer Program Member Center….no dice. Despite the fact I have all fields filled out, I keep getting the error message: “We are unable to process your request. Please enter all required data.” If anyone has any insight how to get past this, let me know. Thanks, Brad ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 2:45 PM, Rick Mann rm...@latencyzero.com wrote: I am never able to get this shit right 100% of the time, and I don't know if it's because I'm doing something wrong, or iOS is broken and I need to do something else. As a second to Rick's request, auto-layout has given me fits on both iOS and OS X. I have not found the Auto-Layout Guide doc or various blog / other posts or WWDC sessions (unless I missed one that had this in it) on it to be a silver bullet. I find the pre-autolayout springs/struts approach to be easy to understand, but more importantly, it behaves consistently and the IB UI doesn't seem to get confused. With auto-layout, I've had no such success -- the IB UI seems to have a will of its own, and the UI seems to continually generate or change various things inexplicably in response to what are by all other indications proper constraints you create. If anyone out there has THE definitive guide on how to use auto-layout and accomplish various common use cases of relative resizing, you have money waiting in my wallet. Thanks, Brad ___ 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: Still can't get autolayout to work the way I want
On Sep 19, 2013, at 3:50 PM, Kevin Muldoon caoimgh...@gmail.com wrote: Yes, IB does automagically pop in constraints and for simple layouts, it works. But, with more complicated layouts, moving a single element around will rearrange one or more other constraints, generally breaking everything. I'm not familiar with the clear I have yet to spend much time in Xcode 5 with auto-layout constraints, but what both Kevin and Rick are describing sounds similar to what I'm experiencing. I have no problem with a smart tool inserting constraints when a constraint I add necessitates the ones being auto-generated (if such a thing exists, though this would raise the logical issue of whether the UI ought to display those other constraints as a package-deal per se, rather than just inserting them, because in that case, you are really deciding on more than just the constraint you are adding, you are deciding on the others constraining the UI too). But that is not what I'm seeing. I'm seeing completely random, in some cases wholly unrelated, and in others conflicting constraints being added that completely change the layout visually to something unintended. It's like the Miss Cleo of development tools, trying to read my mind repeatedly but being completely wrong. (Sorry, I don't know why the ebaum's World Miss Cleo soundboard prank call popped into my head as an analogy for this). Anyway, you get the point. I have found myself actually devoting time to trying to reverse-think how some of these auto-generated constraints appear, because some of them are so wacky I find myself wondering that it must be something ridiculously simple I'm missing. Brad ___ 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: Turning off screen shot ability
Thank you everyone for your responses and discussion. I'll take a look at all of the resources listed by responders, and pursue it further with DTS. In conclusion, I'll add what my opinion is of the knobs and switches on the machine here. Here's what I find interesting -- if I set the NSWindow sharingType to NSWindowSharingNone, then screen capture with another capture app (like ScreenFlow -- the only one I've directly tested) does not work. It still indeed does capture, but it captures my desktop as if my app was not running or visible. Everything else on my desktop is captured, but my app is nowhere to be found. In addition, if I attempt a Command-Shift-4-SpaceBar (to capture the window), then this does not work -- in fact, OS X presents a dialog saying that this operation cannot be done (see the link below -- note this is nothing that my app presents). https://www.dropbox.com/s/0i02n3bkuhg0160/Screen%20Shot%202013-03-07%20at%208.11.16%20AM.png However, if I Command-Shift-4 and then mouse-drag, I can capture whatever is in the bounding box (including the entire contents of the window which was prevented in the other case), or if I Command-Shift-3 I can capture the entire screen (including the window in question). Based on the inconsistency of the Command-Shift-... screen shot behavior, my conclusion is that this is a bug. Completely forgetting any philosophical or design opinions, this behavior doesn't make logical sense to me. To prevent someone from taking a screen shot of the specific window, to the point of the system intervene further with a dialog presented to the user, while allowing the entire contents of that same window to be captured by taking a screen shot of the full screen or a custom bounding box by mouse-drag -- I can't reconcile the logic behind that. So my conclusion is that this is a bug, probably with the enforcement of the NSWindow sharingType. Thanks again or the responses and discussion, both on this list, and offline. Brad On Mar 7, 2013, at 3:18 AM, Markus Spoettl ms_li...@shiftoption.com wrote: On 3/7/13 10:47 AM, Richard Heard wrote: Seeing as this uses non public APIs, i would STRONGLY recommend not using it in any shipping applications. However, for interests sake alone this is how DVD Player appears to do it. https://github.com/heardrwt/RHAdditions/blob/master/RHAdditions/NSWindow%2BRHPreventCaptureAdditions.m I can't imagine myself using it but it really is cool! Thanks for sharing! 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/brado%40bighillsoftware.com This email sent to br...@bighillsoftware.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: Turning off screen shot ability
I appreciate the desire of a few here to communicate your perceived futility of turning off screen shots or window capture. I do not want to digress into a philosophical discussion here, I just want to stick to talk of the capabilities of machinery -- but given that the responses here pretty much scan with the discussions I found at various forums online, I want to just briefly address the futility issue. Because a security measure can be breached, either in common practice or in theory, does not mean that it is either futile, or that it is wise to just throw it away. I could give a very long list of examples of this, but for brevity, just a few: - Passwords can be breached, but yet we still actively use and recommend using them. - SSL can be breached, yet it is the protocol foundation for most secure communication on the Internet. - An ATM pin can be breached, yet all of us are no doubt happy that our banks didn't just issue us code-less cash cards which pull directly from our bank accounts. - Car and house locks can be quite easily breached, but yet we still continue to put them in cars and house doors. Finally, every security system on the planet can be breached by social engineering. Given that there may be no such thing as a 100% secure system, does that mean it is wise to throw off security measures? No. Eliminating 99% (or 90%, or 80%) of potential breaches is useful. Even slowing down a breach is useful on a number of levels. I would like to avoid everyone's personal editorial on the value of turning off screen capture is or not, as it is a foregone conclusion that we need this in place. My client is in the security business, and while the details of their product are not going to be discussed here, suffice to say, their use case is a completely legitimate pursuit of turning off screen capture -- and that is with full consideration of alternate means of capture, not ignoring them. So that said, to retrench back to the original question, I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window. For those who have mentioned screen capture apps as a way to breach this, you might be interested to know that with one common screen capture app (I tested with ScreenFlow) that setting the NSWindow's sharingType to NSWindowSharingNone prevents it from capturing the active window. The primary hole appears to be OS X screen capture hotkeys, and in that regard, I'm really interested why setting the sharingType to none, which is supposed to prevent other processes from capturing the contents of the window (and does in some cases) allows OS X to still capture the screen. To distill it -- does OS X have the programmatic ability to turn off screen capture, and if so, how? It is just a question of whether the machine can do it or not. While I appreciate the other sentiments, I can assure you this use is completely legit. Either OS X has the ability or it doesn't -- that, and how it is turned off (if it can be) is all I need to determine. One other responder said that he's encountered other apps which *can* do this, so if someone in the know could pass on the 4-1-1, I would be very appreciative. Thanks in advance, Brad On Mar 6, 2013, at 12:51 AM, Izzy Fraimow frozendevil+cocoa-...@gmail.com wrote: Would you be so kind as to elaborate on your statement, i.e. the fundamental stupidity? I didn't make the original statement but perhaps I can shed some light. Even if, hypothetically, you were able to disable the cmd-shift-3 keyboard shortcut there many, many other ways for a person to capture screen contents. There are 3rd party apps for screen capture, they could mirror the screen and put a sniffer on the video cable, they could eavesdrop on the EM radiation given off by the monitor and recreate the image inductively (yes, this has been done), to say nothing of the most obvious issue: cameras, which are bound to be almost every pocket you come across. There're also screen readers and other assistive devices that expose the same information. Attempting solve any of these problems, let alone all of them, is a losing battle and would only serve to frustrate legitimate users. ___ 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/brado%40bighillsoftware.com This email sent to br...@bighillsoftware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list.
Re: Turning off screen shot ability
Why would there be a simple way? I can think of a few reasons: 1. Using NSApplicationPresentationOptions, you can enforce the following programmatically: auto-hide the system dock, hide the system dock entirely, auto-hide the system menu bar, hide the system menu-bar entirely, completely disable the system Apple menu, disable process switching between apps, disable the ability to force-quit an app, disable app session termination, disable the ability to hide an application, disable menu bar transparency, present your app full screen, and auto-hide the toolbar. These are all clearly aimed at giving an app control of its presentation and environment. A very obvious reason an app would need to control its presentation is in order to control the content presented within. 2. NSWindow allows you to specify the level of access other processes have to the window's content. Aside from the fact that is seems a bit bizarre that there's the ability to grant no access (NSWindowSharingNone, which doc states should prevent the window's contents to be read by another process), and a screen shot still works, the mere presence of this configurable parameter acknowledges the potential need of an app to secure its displayed content. Therefore, it doesn't seem such a stretch to imagine that if a window's contents were secured, that screen shots would follow right along as something desired to be turned off. Screenshots and screen movies are how many apps are easily and quickly documented by honest consultants and IT help desks; a vital tool. As a developer, I know everyone else has full access to my UI and I theirs... no biggie. I get the sentiment, and I think it follows with most of discussions I've found elsewhere online about this that the general misperception about the need to turn off this ability stems from some draconian developer wanting unreasonable rigidity and control in an app like a game or something casual. I'm sure there are those folks out there who have such motivations. This is not one of them, and if interested in thinking this through, I would encourage a slight shift in perspective. Again, I am not at liberty to speak in detail about the specific use-case, but I can speak to the nature of the need. Ultimately, this is not an issue of needing to secure the app itself. The app is really just scaffolding if you willa pipeline. The app is just a delivery mechanism -- but the content it is delivering needs to be secured. A few others have accurately mentioned an example which demonstrates this -- DRM -- for securing music, movies, books, etc. This is a great example, there's no particular need for iTunes to be secured (for the app itself), but the content it is delivering, that's another matter -- DRM has certain requirements, as do the copyright holding entities have contractual requirements for securing such. The specific use-case I am dealing with isn't a music or movie sharing app, and the specifics aren't really important anyway. But I'm sure everyone can draw a distinction between someone trying to prevent screen shots of their favorite first-person-shooter game, and trying to secure private research, government or military information, or confidential documents. My use-case is in the latter category -- and the target of screen-shot prevention isn't necessarily even the user or a user's nefarious intent -- it might be other agents on the machine, or it might be preventing an accidental or arbitrary screen shot which gets left on a machine or is accidentally sent to a printer. So in a nutshell, shift the perspective -- this isn't an enemy-of-the-user thing. It is a help and safeguard for both the content provider, and the content consumer (user). I hope that helps to paint the picture a little clearer. In all seriousness though, you may want to approach Apple DTS directly and present your business case to them. That is good advice. Thanks for the tip. Brad ___ 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: Turning off screen shot ability
On Mar 6, 2013, at 1:49 PM, M Pulis tooth...@fastq.com wrote: Fine, Good rehearsal, but we are not the folks you need support from. I was unaware you spoke for the entire list. I had thought it wasn't too far of a stretch to think that someone somewhere (outside of Apple themselves) might be subscribed to this list that might have a similar need and/or have solved it already. If I truly am the only developer writing security-related apps, then I suppose I ought to be able to stay employed a while longer... ;-) If it was easy, Google would have it listed or someone here would have quickly replied. What Google returned in searching was a a number of similar conversations elsewhere in which a few vocal people didn't even attempt to answer the question, but instead tried to rake the question-asker over the coals merely for not recognize[ing] the fundamental stupidity of the requirement and drop it. Finding zero answers elsewhere, I posted here. I appreciate the opinions of those vocal few who essentially are saying that OS X has security holes which shouldn't be closed, and anyone needing such are not only inconsiderate to their users, but should go elsewhere and use other more secure operating systems. Now I personally don't believe any of that -- I believe that OS X is a great platform for security-related apps, and that there is a solution out there for this problem. (And there appears to be -- thank you for the couple of people who shall remain anonymous who contacted me offline while I was writing this response). You have a special need, that's fine and what DTS is all about. Go for it. Again, good advice. I'll will pursue this direction. Cheers, Brad ___ 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: Turning off screen shot ability
I'll take a stab at this one last time -- I appreciate the opinions here and under normal circumstances I would agree with the sentiments of user liberty and user control of their machine. However, this is a very specialized, security-oriented use-case. This app *never* runs in the background, it can't be put to the background, you cannot switch to another app while it is running, you cannot access any other system or app facilities whatsoever while this app runs. The content delivered by this app is intended to be completely secured, not able to be captured by a background app, not able to be captured with screen shots either. It is the user's choice whether they want to run the app or not, and at any time during the use of this app, the user may opt to exit the app. However, while the app runs, it is the only game in town. There are very legitimate use cases for this -- someone earlier replied mentioning kiosk mode. That's a pretty close analogy, but consider this to be kiosk mode plus confidential data which the user is not supposed to replicate or copy, either intentionally or accidentally. Put simply, the user is given full control over whether to run the app, or exit the app, but they do not get to call the shots or make the rules on how to use the content in the app. It is displayed while the app runs, and it is gone once the app is exited. Again -- I appreciate the sentiments about disabling screen shots not being a desirable approach for whatever reasons. If this were a game, or word-processing app, or music composition app, or something else, that might be a good argument. But this is something far different from those -- security is imperative. Furthermore, one more wrinkle I have not mentioned, this is a requirement of the content-owners. Someone earlier mentioned DRM, iTunes, and the requirements of media publishers to secure such data. Different data, but same principle -- it is an absolute, non-negotiable requirement that data be secured in this way. I have zero ability to change that requirement. The requirement does not originate from me, nor is it mine to change -- it is only mine to solve. But even if I was given authority to make the call, I'd agree with the pursuit of this end -- this particular use case is a legitimate use-case for disabling screen-shots. I'll refrain from any more attempts at explaining the scenario...I've said what I could, but if that still isn't enough, it shouldn't be too hard to imagine scenarios where this would be desirable. Brad On Mar 6, 2013, at 9:39 PM, Steve Mills smi...@makemusic.com wrote: On Mar 6, 2013, at 19:56:04, Charles Srstka cocoa...@charlessoft.com wrote: Turning off the user's ability to do a screen capture in general is probably the wrong approach — and even if you managed to sink your tendrils deep enough to do this, there'd probably be plenty of ways to work around it. Instead, I'd try to figure out what Apple's DVD player does; it allows you to take screenshots all day long, but the copyrighted content gets replaced by a solid color. And as a user, I would still expect my screenshot key to function if this mystery app is running in the background, so it had better not remove/trap the key just because it's running. And if you remove/trap it only when it's the foreground app, than what's preventing it from being screenshotted when it's in the background? Look for other ways around being secure - preventing screenshots whole-hog is not a good idea at all. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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/brado%40bighillsoftware.com This email sent to br...@bighillsoftware.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: Turning off screen shot ability
Lee Ann, Thanks for the reply. I took a look at the Son of Grab app -- if I've understood it correctly, it appears to be related to the setSharingType property of the window in question, which I already have set to none -- which means no other process should be able to capture it. It appears that isn't the case with Command-Shift-3 however, which seems to still create screen shots unimpeded. Brad On Mar 6, 2013, at 2:14 PM, Lee Ann Rucker lruc...@vmware.com wrote: On Mar 6, 2013, at 9:02 AM, Jens Alfke wrote: On Mar 6, 2013, at 8:37 AM, Brad O'Hearne br...@bighillsoftware.com wrote: I am interested in the capabilities of the machine (OS X) and if so, how. I need to programmatically within an app (not by external system administration) turn off all screen capture capability, by hotkeys, or by grabbing the contents of the window. Apple’s DVD player app does this, for DRM purposes*. I don’t know how it manages it, whether it’s some public system API or an internal-only thing … but it might be a useful clue to track down. I'd start with the Son Of Grab sample app; it shows how to get the contents of other app's windows, so that's where I'd look to figure out how to prevent that. ___ 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
Turning off screen shot ability
Hello, I am working on a security-related Mac app and I need to know the way to turn off the ability to screen shot or capture the contents of the app's window. It would appear that setting the sharing type on the main window (which covers the entire screen) to none doesn't completely do it. It appears that Shift-Cmd-3 still performs a screen shot. I've already tried capturing keystrokes and it appears these system-level hot-key combinations aren't able to be cleanly intercepted. More than that, I would think this is overkill -- I would think there would be a simple way to turn off the ability for outside sources to grab contents of an app. How can I turn this off? Thanks, Brad ___ 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
Convention for init with error
Hello,
I have a need to construct an object with the possibility of an error taking
place and needing to return that error. While it would be nice to have a clean
init method that returned no errors, in this particular case, the error belongs
with init. I've been pondering two ways of doing this:
1. Just a modified init method, where it returns nil for the return value and
sets an error pointer like so:
- (id)init:(NSError **)error;
{
self = [super init];
if (self)
{
if ([self operationThatMightFail:error])
{
*error = nil;
}
else
{
return nil;
}
}
return self;
}
OR
2. Using a static method to perform the dirty work, and then encouraging the
caller only to use this method to init the class, like so:
- (AThing *)athing:(NSError **)error;
{
AThing *a = [[AThing alloc] init];
if ([a operationThatMightFail:error])
{
*error = nil;
}
else
{
return nil;
}
return a;
}
What is the recognized convention or design pattern for addressing this in
Objective C, or does it not really matter?
Thanks,
Brad
___
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: Convention for init with error
Quincey and John, Thank you both for the replies and opinions. I do like the factory method approach, however there is something about a mandatory process or workflow for using an object that seems like it should naturally be put in an init method. It sometimes strikes me a little weird when I think I just did an init, but the object in reality isn't initialized -- there's still these other steps that must be accomplished. I guess it is a semantic difference, but even one that I've wondered in Apple's API too...factories over here, but no factories over there; init leaves an object in the desired state over here, but over there you need to init and invoke methods 1-2 before the object is in a proper state to be freely used. Maybe it is just philosophy, but I try to be disciplined and consistent in my coding, so I thought this to be a good learning situation for me to see how others approached it. Thanks for the insight, guys. Brad On Feb 27, 2013, at 2:50 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: P.S. I agree with John's statement that a factory method is better (especially with ARC) for your class's public interface, but even within the class implementation you might not be able to avoid the need to return an error from a private 'init'. ___ 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
Conversion of QTCaptureDecompressedVideoOutput frame to YUV420p
Hello, I am trying to take a CVImageBufferRef received from the following video capture callback: - (void)outputVideoFrame:(CVImageBufferRef)videoFrame withSampleBuffer:(QTSampleBuffer *)sampleBuffer fromConnection:(QTCaptureConnection *)connection ...and feed to to an FFmpeg codec for further encoding. We can ignore the FFmpeg side of this except to say that the FFmpeg codec in use requires YUV420p, which for anyone familiar with FFmpeg is the pixel format AV_PIX_FMT_YUV420P,described as follows: planar YUV 4:2:0, 12bpp, (1 Cr Cb sample per 2x2 Y samples) I am pretty sure that I have to set attributes on the QTCaptureDecompressedVideoOutput instance to use KCVPixelFormatType_420YpCbCr8Planar pixel format type, given the definition below seems closest to the desired YUV 4:2:0 format, and that I need to be Snow Leopard compatible. kCVPixelFormatType_420YpCbCr8Planar Planar Component Y'CbCr 8-bit 4:2:0. baseAddr points to a big-endian CVPlanarPixelBufferInfo_YCbCrPlanar struct. Available in OS X v10.5 and later. The problem is that once this attribute is set, the capture is failing with the following in the console: 2013-02-05 17:48:21.050 Sentinel[998:13503] *** QTCaptureDecompressedVideoOutput warning: Output received the following error while decompressing video: Error Domain=NSOSStatusErrorDomain Code=-12906 The operation couldn’t be completed. (OSStatus error -12906.). Make sure that the pixel buffer attributes of all outputs are valid. Question #1: why am I receiving this message, and how to I get past it. Question #2 (and if you can answer this, forget #1): How can I get a decompressed frame formatted properly to the following format: planar YUV 4:2:0, 12bpp, (1 Cr Cb sample per 2x2 Y samples) Thanks in advance for your help. Regards, Brad ___ 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: Get the current displayed NSAlert
In general -- any alert that requires user attention (especially ones with multiple button alternatives) can be left on the screen indefinitely by a user. If you are monitoring environmental conditions (such as network, server, or Internet reachability) that arise, it is always possible that such an event that would necessarily need to supersede the displayed alert, as the global event (environmental condition) might prevent the normal course of action which the first alert would provide. For example: 1) Alert one displays: This condition took place, would you like to proceed with option X or option Y. (Assume both X and Y require Internet connectivity). 2) The app detects a loss of Internet connectivity. Neither X nor Y are now appropriate until the Internet reachability issue is resolved. So what we need to do is redirect the user's attention to resolving the more important problem at hand, fixing the network issue, a second alert condition. The thing compounding the issue is that 1) and 2) occur in somewhat unrelated parts of the app which necessarily do not know what each other is doing (other than existing). That is actually a very good thing -- and we want to somewhat keep it that way. They do have a relationship, however, in that the managing entity in 2 actually controls the entity in 1 (though agnostic to its function). So the problem was resolved by having the managing entity in 2 issue a lifecycle message to the entity in 1, so that it could behave accordingly. Its working, but in any such architecture (an OS is a good example) there is the constant tension between managing resources globally vs. separating and hiding concerns within components. Thanks for the replies everyone, they are greatly appreciated. Cheers, Brad On Dec 4, 2012, at 12:54 AM, jonat...@mugginsoft.com jonat...@mugginsoft.com wrote: On 4 Dec 2012, at 06:26, Kyle Sluder k...@ksluder.com wrote: I think you're thinking about the problem too generally. The workflow manager is probably going to need to understand that the plugins it's running can have encounter exceptional conditions. Therefore, there should be a mechanism by which your processing plugins can inform the workflow manager of these exceptional conditions. I would implement an alert controller that would accept prioritised alert requests either from the app or a plug-in. I would also ask myself whether a simple alert sheet is the way to go. Alerts are asking for the user to attend. If a plugin alert is displayed and then inexplicably replaced by another it looks as if the software is conflicted. Perhaps the alert controller displays a single dismissible window that contains a scrollable prioritised list of active alerts. Jonathan ___ 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/brado%40bighillsoftware.com This email sent to br...@bighillsoftware.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
Get the current displayed NSAlert
Hello all, Is there a way to get a reference to the currently displayed modal NSAlert, or to be able to globally determine if a modal alert is presently showing in a Cocoa app, though you have no knowledge of where in the app it originated from? Thanks, Brad Brad O'Hearne Founder/Lead Developer Big Hill Software LLC http://www.bighillsoftware.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: Get the current displayed NSAlert
Kyle, Thanks (I think). I asked the question as simply as I could without convoluting it with quite a bit of complexity, which would probably lead more to theoretical discussion rather than the specific issue. But since you want a more involved description of the problem, I've developed a processing framework that facilitates workflow by sequentially processing workflow plugins. All plugins are agnostic of one another, and the workflow framework is agnostic to the function of the plugins. This workflow framework dynamically becomes whatever app I want it to be, just by changing the plugin stack that the workflow framework processes. There are some interesting design questions that arise about responsibility of processing, whether the workflow manager merely provides certain state information to a plugin, and makes each plugin handle the condition, or whether the workflow manager imposes itself on the process. The particular manifestation that this question was addressing is if a plugin presented a modal alert which the user had not yet dismissed, when the workflow manager needed to present its own modal alert, what approaches existed to handle this. Very similar questions exist between OS and apps -- when does the OS merely provide info to an app (which passes responsibility for handling to the app) vs. when does the OS impose itself on the app and overrule its UI and processing. That's the idea...pretty oversimplified here. But that is what was behind the question. If an app could easily request a reference to any NSAlert that was currently being displayed, it might suggest an alternative to handling it. Presently, each plugin has to handle dismissing its own potentially displayed alerts when the workflow manager decides it needs to display its own alerts, and the workflow manager effectively messages the plugins by virtue of pause and resume lifecycle methods on plugins. Thanks, Brad Brad O'Hearne Founder/Lead Developer Big Hill Software LLC http://www.bighillsoftware.com On Dec 3, 2012, at 10:10 PM, Kyle Sluder k...@ksluder.com wrote: On Mon, Dec 3, 2012, at 05:13 PM, Brad O'Hearne wrote: Hello all, Is there a way to get a reference to the currently displayed modal NSAlert, or to be able to globally determine if a modal alert is presently showing in a Cocoa app, though you have no knowledge of where in the app it originated from? If you need to know this, your architecture is almost certainly screwed up. What are you actually trying to accomplish? --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
Suppressing variable hiding warning in Xcode
Hey there, I had a few questions about selectively suppressing a certain warning in Xcode. I personally find the warning which pertains to local variables hiding instance variables a real nuisance. For example, if you have a message signature with a parameter name which matches an instance variable name, and the compiler produces the following message: warning: local declaration of 'variable name' hides instance variable Two questions: 1. I get the gist of trying to prevent developers from accidentally hiding variables -- but is this really a major problem? Other than this, is there a compelling reason to keep this warning in tact, and change variable parameter variable names to make the warning go away? 2. How do you get Xcode to not produce this warning? Thanks, Brad ___ 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
Dynamic getting of a property of BOOL type
I am dynamically retrieving properties from an NSObject, in order to convert the types to string values and store them in XML. I am using the following line of code to send a message to the object to retrieve the property's value: id value = objc_msgSend(object, propSelector); BOOL booleanValue = (BOOL)value; The problem I am having is that I'm getting a warning on the second line. I've tried a number of variations, including: BOOL booleanValue = value; both of which give the following warning: warning: cast from pointer to integer of different size How can I properly convert this id returned from the dynamic invocation of the property getter to the BOOL value that it actually is? Thanks, Brad ___ 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
Sublclassing NSThread
Hello,
I am trying to create an NSThread subclass which completely wraps the
desired behavior of the thread execution. Now typically when creating
a new thread instance, it seems one will use the
initWithTarget:selector:object initializer to properly direct the
thread's execution. But what if I want the thread subclass to invoke a
method within itself? This leaves you with a situation where you have
to set the target to self within the initializer, but that seems
problematic, as self is not yet defined, i.e.:
- (id)init {
self = [super initWithTarget:self @selector(myMethod) object:nil];
return self;
}
As you can see, the initWithTarget: param is set to self, but the
purpose of that statement is to set self, and self isn't defined yet
to my knowledge. I'd otherwise just use the NSThread's init method,
but I do not see a way to set the target as a property on the thread
object once initialized. So my question is, in Objective C, is the
typical approach to wrapping behavior entirely within an NSThread
subclass to override the start method, as such:
- (void) start {
[super start];
[self myMethod];
}
Is this the recommended approach, or is there another way to go about
this?
Thanks,
Brad
___
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
OT: Uninstallers (Was: Cocoa-dev Digest, Vol 5, Issue 1598)
This is starting to stray a bit from Cocoa code talk, but as a bit of feedback to all Cocoa developers out there who are developing applications to ship to end-users (in contrast to internal corp apps), the lack of uninstallers on Mac apps seems to be a notable omission, for an otherwise stellar platform. I recently ran into a problem with this with Final Cut Studio 2 on my MacBook Pro. For those unfamiliar with FCS2, it takes a huge chunk of disk space to install video / audio assets, which over time / other apps installed left me running out of disk space. Apps like AppZapper don't find all the assets, and when posts to Apple discussion forums net reinstall OS X as the best advice for removing FCS2, there's definitely an opportunity there for improvement. (FYI -- I did not reinstall OS X, I went on a Google / file system hunt and eventually got most of it off, to the best of my knowledge). As a bit of user feedback to Cocoa app developers: if all things were equal between two like apps I was evaluating, if one had an uninstaller, it would tip the scales for me, and keep in mind, I'm a software developer. Non-technical users are going to be all the more -- if yours happens to be the app which results in them getting the reinstall OS X advice, that is what the user is going to remember. So in a nutshell, big +1 for uninstallers. B On Sep 10, 2008, at 7:32 AM, Bill Royds wrote: On 10-Sep-08, at 04:59 , [EMAIL PROTECTED] wrote: Anyway, if Mac software starts heading back down the road to everything having an installer, the appeal of the Mac platform vs. Windows will be severely diminished in my eyes. Drag and drop puts the user in control - installers put the user at their mercy. Whenever I see an installer that does nothing but put an app in / Applications, I tend to think twice about using that app, because it's often a sign of a poorly thought out product. Often I will send an e-mail to the author complaining about this as well. But you are not a typical user so your preferences are not the most important. Most users who want to install software only want to b able to click on the downloaded package and have it install.It might ask some questions like password or ask whether you want advanced control, but even the concept of moving to /Applications is more than most users want to know. Windows installers are much easier for naive users to handle than anything that requires knowledge of the system structure such as drag and drop to /Applications. Of course, it is still better to have a simple install logic and a bundled app that you could drag and drop to /Applications is better than one that requires many different steps. probably the double click on an app package should just invoke a shell script the\at does sudo cp MyApp.app /Applications with the sudo password prompt in a gui window. ___ 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/brado%40neurofire.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
OT: Announcing Pi, the Phoenix iPhone Developer Group
All, Please pardon the fact that this is in regards to a new user group based in Phoenix, AZ. While most of you may not be local to Phoenix and be able to attend our meetings, please feel free to join anyway, to take part in iPhone development discussion. Perhaps your area does not have an iPhone user group yet, but if not, there's no reason you have to do without -- hook up with our group. For the better part of the past year, I've been an iPhone user, and have kept a close eye on the developments of the iPhone, iPhone web development, and the iPhone SDK. I attended the Apple World Wide Development Conference (WWDC) last week, and as most of you probably know, Apple announced the 3G iPhone and the iPhone SDK 2.0. For those unable to attend, I can summarize last week by saying that the iPhone is not merely a mobile device; it is essentially a brand new OS platform, and the most advanced mobile technology in the world. Apple has created a huge opportunity for development, and rarely in a technical career does one get the opportunity to get in on the ground floor. I am an independent software developer based in Gilbert, I am developing applications for the iPhone to be marketed soon when the iPhone Application Store opens. This is a major career direction I've been planning, and as such, I have had plans to launch an iPhone developer group following the WWDC. That day is here. I'm announcing the Phoenix iPhone Developer Group, otherwise known as Pi, due to a play on the letters of the group name, and the anticipation of this new, exciting direction going on, and on, and on (that's nerd humor for those following along...). You may join this group at the Google Group at the following URL: Phoenix iPhone Developer Group: http://groups.google.com/group/phoenix-iphone-developer-group These URLS also resolve to the same location presently: http://phoenix-iphone.com http://phoenix-iphone.org I will be supporting this group through email posts, attempting to facilitate meetings (which will be spontaneous, as members are available, and at convenient locations), and my blog just opened at: NeuroFire (blog entitled Burning Embers): http://www.neurofire.com/ I welcome everyone to join. I look forward to collaborating with you, and growing the iPhone Developer Community in Phoenix. I would be very grateful if you could forward this email to any work associates, and other user groups you may be a part of -- spread the word! Sincerely, Brad Brad O'Hearne NeuroFire ___ 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 [EMAIL PROTECTED]
