I'm completely new to Cocoa and Xcode. I started using it a couple of days ago, because I have to build a little tool for macOS.
After hours of research I still can't find a solution for my problem.
What I need to do:
A window with a Quartz Composer Patch QCView (everything working) which resizes with the window the QCView is in
There should be a second window with two text fields (with Number Formatter and editable).
Those text fields should show the current resolution of the window with the QCView
The user should also be able to type numbers in the text fields to set the size of the QCView (x and y)
As I mentioned above, I'm not really experienced in Cocoa, Xcode, Objective-C or Swift.
If someone could give me some hints how to accomplish those tasks would be great (especially with which parts of the code have to be put in the .h and .m or .swift files).
Thanks for your help!
Related
I've watched the WWDC 2014 session (#608 "Best practices for building sprite kit games") a couple of times and I just want to clarify the purpose behind using .sks files. Am I supposed to put separate assets into each .sks file? Here's a little bit of background into what I'm doing. I'm creating a Mac app that will text piano students to play chords using a MIDI keyboard. Chords will appear on the screen and they'll play them one by one and get a score. Here's a mockup of what the app may look like. Side note: for those that may know music, we're using the numeric version of chords instead of explicit names like Cm, etc.
Would I have a separate .sks file for each element of the UI. For instance, one for the green timer bar, one for the piano keys, etc. The example that they use in the video is a pretty simple one. I am subclassing SKSpriteNode for the timer and on-screen piano so how would I handle the resources for those. They are not static objects and they will change either over time (timer) or due to user input (keyboard)
I really want to organize my project using best practices. Please help. Thanks in advance.
Sks files are serialized SKScene objects. The intent is to provide something like interface builder for constructing SKScene scenes visually. The common use case is to layout complex backgrounds or levels and define starting positions. You would only have one file per scene in many cases. However you can use the sks files to organize and serialize conceptual components of a scene, as demonstrated in versions of the Apple Adventure sample code released since the sks format and scene editor were introduced with Xcode 6
In the screenshot above, you could organize the project into sections that are fairly generic and reusable, like the keyboard for one file and the hud atop the scene for another file. However, you could put them all in one file, then duplicate the file for variations on a theme.
I have a question regarding NSMenuItems.
What I'm trying to do is replicate a java GUI using native OS X components, therefore the language I am using is Cocoa. What I am trying to do is to get every menu item to have an image and then, beside it, some text.
I have already done some research into it and my first port of call (as always it seems lol) was the apple docs which had this handy example which illustrates how to embed views inside menuitems:
https://developer.apple.com/library/mac/#samplecode/MenuItemView/Listings/MyWindowController_m.html#//apple_ref/doc/uid/DTS10004136-MyWindowController_m-DontLinkElementID_8
Being relatively new to cocoa, I was thinking I would have to override one of the drawing methods from NSMenuItem. Not really sure though.
Another idea that I was toying with was creating a custom view that held a image and some text.
Any other ideas/validation or discussion would be most appreciated.
Thanks all!
Oh and the GUI creation is being done by hand no interface builder.
Okay, so I now have menu items with icons beside them. For anyone who is interested here it is ( i've not done a leak analysis on it or anything).
First things first, put all of the images you want into the "Resources" folder (thats what its called in xcode 3.1.4).
Now, for example, after we have all the images, we want to use images called "eraser.png" and "eraser_on.png" and I want to attach these to the 3rd menu item. In order to achieve this we do the following :
The code below will get the menu item at position 3 in the menu
NSMenuItem *item = [ nameOfPopUpButton itemAtIndex:2];
The code below will set the image for the menu item to be "eraser.png"
[ item setImage: [ NSImage imageNamed:#"eraser"] ];
That's you set the image for the menu item (which will be on the left hand side of the text aka before the text).
If you want different images for the different states, eg when the user presses it, use this method (not tested myself but its sounds sensible :D and the function is straight out the api)
[item setOnStateImage: [ NSImage imageNamed:#"eraser_on" ] ]
You can however leave it nil or not set it at all and it will go the default color
Hope this helps someone.
Pieced this together from: https://developer.apple.com/library/mac/#samplecode/MenuMadness/Listings/Controller_m.html#//apple_ref/doc/uid/DTS40008870-Controller_m-DontLinkElementID_4
Thanks :)
If you need to do this you have the right idea in creating a view with image and label subviews.
BUT: don't do this. Creating a "native" application is not primarily about your choice of language (which is Objective-C, btw, not Cocoa; the latter is a collection of development frameworks implemented in Objective-C). It's about conforming to the platform.
On OS X (and iOS), more than probably any other platform, consistency in UI design is paramount. Users know when an application looks strange, and having icons next to each menu item (something I certainly have seen in Java apps) is definitely strange and unnatural on OS X. Users will be irritated at best, confused at worst.
So my advice is to either follow the Human Interface Guidelines (and save yourself a lot of work as a nice side effect) or just stick with your existing Java application.
If you want to provide quick iconic access to common functions, the recommended approach on OS X is to use a toolbar.
Being a somewhat proficient iOS developer, I have just started working on a desktop OSX project in Cocoa and I'm running into issues that I just can't grasp. So this question is for the OSX developers out there.
I don't like the Interface Builder much, so I tend to write my views in code. The most prominent method I write my view layout code in is a view controller's loadView method, and at least on iOS I use autoresizingMasks for everything. Try out the view small, large, rotated landscape and portrait and if all is dandy, I continue with the next item on my list. Now on the desktop, the autoresizingMask works (or just looks) a little bit different. First of all the properties have different names, but their behavior also seems weird or unexpected.
When I ran into the issue below, I thought it must be my code was wrong, so after trying out long enough I re-created it with Interface Builder just for confirmation's sake, and guess what: I got the exact same result. Take a view with four vertically stacked subviews. Set the middle two to have flexible heights, the outer ones to be fixed. When you run it, size it down and back up again, I get two completely different layouts before and after the resize. See image:
Now I can follow why this happens from a mathematical standpoint between run loops, but from the point of an 'autosizing' or 'autoresizing' feature, this makes absolutely no sense.
Before I try to write the mother-of-all-resizing-topics here, might I ask you these questions? Feel free to elaborate some more on the resizing topic if you feel it adds to the post.
Am I a fool for not wanting to use the Interface Builder on desktop projects?
Should I depend on the autoresizingMask less than I would on iOS projects?
What are decent alternatives to making sure your layout lives up to standards without Interface Builder?
Cheers!
Yes, in my opinion. :)
You should depend on it when it does what you need. When it's insufficient, override resizeSubviewsWithOldSize: and/or resizeWithOldSuperviewSize: (or see below).
???
If you can target 10.7, look at the new constraint-based layout system. Check out the Cocoa Autolayout video from WWDC 2011.
You could also set minSize on your NSWindow to something large enough to prevent the singularity.
I'm not sure I'd say "fool," but refusing to use Interface Builder on the Mac is a very…avante-garde choice.
You should definitely use autosizing on your views.
Be maniacally attentive and spend lots of time making sure everything is right. (This is why I don't recommend going without Interface Builder. In general, what you get is a lot of wasted time that you could have spent doing something else.)
In this case, I think the best approach would be to set a sensible minimum height for the window. Don't let it get too small to display what it needs to display.
I'm just learning to use XCode and program in Objective-C (my plan is to write a an app we need for my business since I can't find one that does what I need). It's going well and as an exercise I've been playing with database apps and screensavers.
I'm trying to write a screensaver that all it does is to show 3 or 4 pictures randomly floating on the screen. Similar to the out of the box pictures screensaver that comes with Mac OS X.
I've played with the code in http://cocoadevcentral.com/articles/000088.php and while very informative I still don't know how to add those 3 or 4 pictures and make them move.
Anyone out there can point me to sample code? Or a project that I can use as reference?
Again, this is just self learning.
Thank you!
This will probably be your first port of call.
My approach to this was to create a Quartz Composition using Quartz composer. I found this easier than figuring out how to draw and animate everything by hand.
You can display a quartz composition inside a ScreensaverView by using the QCView class. This setup worked well for me.
In Interface Builder.app (and some other cocoa apps), image dragging has a very nice/sexy effect of morphing the drag image while you drag a draggable item out of its window.
For example in Interface Buildler.app:
Show the Library Palette (⇧⌘L, or Tools Menu -> Library)
Drag an item out of the Library palette
NOTE: as you drag the item out of the Library Palette window, it morphs from an image of the original list item to an image of the icon of the dragged item.
I have fully implemented drag and drop in my Application using the normal Cocoa NSDragSource/NSDragDestination facilities.
However, I can't find a hook for doing this image morph while dragging. I'm returning the initial drag image by overriding
-[NSView dragImage:at:offset:event:pasteboard:source:slideBack:]
But this is only called at the beginning of the drag.
How do you signal that you would like to replace the current drag image (ideally using the sexy morph effect).
You guys beat me to it. :-)
Yes, JLNDragEffectManager is open source (with attribution in your apps, please) and available on my blog. It should work fine as-is with no modification back to 10.5, but I'm not sure back any further. Others linked to it (and it's easily googleable), so to avoid self-congratulatory blog linking, I'll leave it at that.
Issues: One developer commented on (and submitted code to fix) the lack of dragging offset support. I've just not gotten around to posting the update. That's the only outstanding issue I'm aware of.
Improvements: I'd like to add multiple "zones" (say, one per document, so dragging from doc to doc keeps table rows looking like table rows, but anywhere outside doc windows turns them into a file icon a la HFS Promise Drag). Some day ...
Design: The post itself details the reasoning behind the design and the relatively simple morphing effect (cross-fade plus size are animated using basic NSAnimation, etc.). The code (the class as well as the demo app) is thoroughly blocked out and commented.
Won't link to my own post but would love the karma of upvotes for my effort. ;-)
UPDATE: Similar (but better-integrated) functionality is available as of 10.7. If you are targeting 10.7 or higher, it's best to use the new API. JLNDragEffectManager works fine on 10.7, so it can be used for earlier-targeted versions.
JNLDragEffectManager does exactly that. :)
The API does not support this well. Joshua Nozzi gives a method that looks reasonable in this weblog post.
IB's effect isn't that fancy. It's a crossfade and scale. Hold down shift to see it more clearly.
As of 10.7+ the current approach is to use the
enumerateDraggingItemsWithOptions:
forView:
classes:
searchOptions:
usingBlock:
API on NSDraggingInfo. The documentation is really poor but the ADC samples like MultiPhotoFrame or TableViewPlayground can give a good idea on how to use the new mechanism.