So I'm new to Apple and Objective-C development, I'm working with a very old version of Xcode (version 2.5) and OSX (version 10.4.11) to make a pretty simple GUI application in Cocoa Objective-C. I need to have text grabbed from an EditText when a button is clicked. I'm trying to find guides on how to use OSX, but I think the version is so far back that it doesn't apply to the guides that usually come up.
My fellow developer and I are working on a macOS app.
I'm running Xcode 8 on 10.12
He's running Xcode 7 on 10.10
Deployment target is set to 10.10
I developed the project on Xcode 8 on 10.12.
I am using an NSStackView for one section of the UI. App runs on my OS (10.12) and his OS (10.10) after I put in some version checks and "if version > x then run (code)" to address the changes made to NSStackView in 10.11.
The majority of the project (all but the xib containing the NSStackView) will open in his 10.10+Xcode 7 after I set "Opens With..." to "Xcode 7.x".
The Xib with the NSStackView, however, will not. He cannot open it. He also cannot compile the project as it complains that:
"The document “ControllerWithStackView.xib” requires OS X 10.11 or later"
I'm assuming that the xib contains additional information on the 10.11-enhanced NSStackView that his older OS and Xcode can't handle.
Does anyone have any ideas on how I might change things such that he could continue using 10.10 and Xcode 7 while I use 10.12 and Xcode 8? For several reasons it's preferred that he keep his current OS.
My ideas:
Don't embed the NSStackView in the xib via interface builder. Instead, create it in the controller via code
Don't use NSStackView. While it does work for our purpose (traditional add/remove/show/hide behavior ideally tailored to the stack), I suppose I could either use an NSTableView or code something custom
Are there other options? Are there any magic settings in Xcode 8 that I could set to say "hey, this stack view should be aiming for 10.10"?
Any insights on how people approach situations like this would be very much appreciated.
Thank you,
Eric
I'm working on wrapping some Cocoa functionality in an Objective-C library that will be called from a cross-platform C library. One of my goals is to provide someone who does development in C on Linux with the ability to deploy to OSX without having to get into XCode, nib files, etc. I want them to be able to compile and link their code on OSX using the command line tools, and end up with a regular resizeable main window with the usual buttons and so on, an application menu and a dock icon that looks and behaves as expected, etc.
I'm working on OSX 10.8.5. I have XCode 5.0 installed. Here's my gcc --version output:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I've figured out how to present a main window, how to set up the application menu, and various other things, programmatically, without using XCode or any nib or plist, but I've run into a problem with the dock icon.
I set a custom dock icon image by calling:
[NSApp setApplicationIconImage:dockImage];
When the user quits the app, the dock icon image reverts to something else (some kind of default application icon or view), briefly, before going away. How can I prevent that from happening without using XCode to create a nib or a plist?
I've tried setting the activation policy of NSApp to prohibitted in the app delegate's applicationShouldTerminate method, to try to hide the dock icon before this switch back occurs. That didn't help, it does hide the window and the dock icon, but the dock icon still switches back to the default icon, briefly, as part of the process of hiding. I confirmed this by returning NSTerminateLator, and confirming that setting the activation policy to prohibited does cause the dock and the icon to hide even though the app is not terminating, and not setting it leaves it unhidden.
I've tried subclassing NSApplication and overriding the setApplicationIconImage call. I have confirmed that it is being called a second time, by something other than my code (well, or not directly by my code, anyway), just before the program exits. I've tried preventing the second call to it from working by calling the super function the first time, but not the second time, and I've confirmed that code in that function can prevent my code from changing the application icon, but that didn't fix the problem. It still happens anyway, somehow.
I've also tried removing the application badge, like this:
[[window dockTile] setShowsApplicationBadge: NO];
just in case it was something to do with that, but that didn't work. The docs say that app badges are no longer relevant as of 10.6, but I was grasping at straws.
Being stumped on the programmatic front, I'm now trying to find out how to package an .app from scratch,without using XCode, and see if maybe I can create a plist from scratch that has a reference to application image in it. But a programmatic solution would be preferable, as I'd really like to minimize what goes into the OSX-specific packaging of a deployment.
Another possibility might be to use XCode once, to produce a very generic, bare-bones .app that my deployment scripts copy and alter.
Please don't shoot my question down as being "too broad" or "not constructive" or something like that. I realize I'm reinventing wheels that already exist in various forms, but there's no law against trying to build a better mouse trap, or just a different or even a worse one, for that matter. I realize I'm trying to fix a problem that a lot of people would consider inconsequential, but XCode-produced apps don't have this problem, and I really don't want the tools I'm creating to produce any user-visible artifacts like that. I'm not intending to diss Apple's tool chain or invite debate about whether or not what I'm pursuing should be pursued. I have a specific, technical problem that I'm looking for solution to that is within the constraints of my goals.
After Googling for about the past hour and a half, I have been unable to find out any definitive information on how the start menu and how windows 8 style applications work behind the scenes. I was under the impression that Windows 8 Style applications were processes which created fullscreen windows and that the Windows 8 start menu was created by explorer.exe in much the same way. But there are incompatibilities between Windows 8 the 1.x version Sysinternal's Desktops utility, I have to imagine that something more complex is going on.
However, in Spy++, each Windows 8 style application appears as standard Window with the WS_EX_TOPMOST style set, which would make sense, assuming they are nothing special. With respect to the Start Menu, it appears as a window of class ImmersiveLauncher created by explorer.exe. Perhaps explorer has developed an aversion to having multiple instances...
Using the old version of SysInternal's Desktops, the explorer instances in the additional desktops work fine, but do not load pinned items nor load the desktop background and icons.
Is there any documentation on why Windows 8 behaves differently from past versions when multiple copies of explorer.exe are running in different desktops?
(This is purely for curiosity's sake)
(Yes, I know there is a Desktops 2.0 version available which supports Windows 8, but it uses interesting workarounds, like switching to the original desktop when the windows key is pressed. It also seems to trigger some initialization within explorer.exe when the desktop is loaded for the first time beyond simply starting the process.)
Is there way I can quickly set up an About Window for my OS X app without creating a window and adding elements to it from scratch? Something like HIAboutBox but which works on OS X 10.8 as well.
Cocoa has built-in support for displaying a standard about box, and projects created from any of Xcode's templates will have this wired up to the "About MyApplication" menu item in the application menu. It works by calling -[NSApplication orderFrontStandardAboutPanel:]. It automatically pulls the basic information from your application bundle (icon, name, version, build number, copyright notice). It also supports displaying extra information by looking for a file named Credits.html / Credits.rtf / Credits.rtfd in the application bundle.