> 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 will....a 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
