I am in the process of starting a project and whilst the logic part is relatively simple for me to mull through I am not very experienced with creating GUIs.
If you are not familiar with node based workflow here are a few examples
Nuke (The Foundry)
Max/MSP (Cycling 74)
SoftImage (AutoDesk)
The problems I have is where to start, What kind of object should I use to encapsulate the node gui? Or How would I go about making custom GUI elements that are click-drag/movable within a workspace? Are there any Books you recommend or anything you can link me too that would be able to get me up to speed.
Thank You
Your node view will derive from NSView, and I imagine that you'll want to use CALayers for your nodes.
You may find it helpful to look at some opensource Cocoa frameworks that implement custom views. Two that spring to mind are TwUI and GCDrawKit. Neither are a drop-in solution for what you want but they should give you an idea about how to architect complex custom views in Cocoa.
I recommend you use interface builder and the AppKit framework. A good introductory book is Cocoa Programming for Mac Os X
Related
I am thinking there must be some libraries out there that people have developed which can be used as "plugins" or whatever people call them to do simple and common UI types of things.
I am using the message board idea as just an example, but I am looking for a general solution. For example, is there a place where I can browse "gems" for RoR that just take care of some UI component?
How do people usually integrate such pieces as a message board present at the bottom of every page, or some other ui tool without writing their own, or using a CMS?
Thanks,
Alex
Two good places to browse gems are http://ruby-toolbox.com/ and of course http://rubygems.org/
I am working on an application in which I need to migrate the whole code of it from carbon to cocoa.I have experience in programming of C,C++,python and Java during my college time and internship but have never touched objective C or have done any programming for Mac(Carbon and Cocoa) before this.
So Can you please suggest me some sources to start with, also how should I go about the whole migration ?
After researching on net I have found that most the people have suggested following books
Cocoa Programming for Mac® OS X, Third Edition by Aaron Hillegass
Programming in Objective C - Stephen Kochan
I have got both these books.
Should I read them first and then should start with the code change? (it will take some time to read both of these)
OR
after having a decent fimiliarity with Obj C and Cocoa, should I directly get started with code migration?
Also,
since I don't know carbon , what should I refer to learn carbon to have sufficient knowledge to migrate the carbon code to cocoa?
First, learn Carbon so you can read the program and understand how it's currently implemented.
Install the Legacy documentation set in Xcode to gain access to the Carbon guides. You'll want to read the Carbon Overview, then Getting Started with Carbon, then everything that Getting Started links to. You'll also need to learn Core Foundation, which some of the more modern parts of Carbon use; read Core Foundation Design Concepts and the Memory Management Programming Guide for Core Foundation.
Then, learn Cocoa.
I didn't learn by the Hillegass book, but a lot of people swear by it. My current favorite Cocoa book is “Cocoa and Objective-C: Up and Running” by Scott Stevenson. The way I learned Cocoa was using Apple's own docs. Start with The Objective-C Programming Language, the Cocoa Fundamentals Guide, and the Memory Management Programming Guide for Cocoa. Much of the last document will seem really familiar, but skip nothing. Read every one of those guides from beginning to end and all the way through.
Once you've learned Cocoa's general concepts, you can move on to more application-specific material. Start with the Application Architecture Overview and most of what that document links to. The Cocoa Guides list has the full list of guides.
Down the road, you'll also need to make the application compatible with 64-bit mode. If you still have any Carbon code by that point, you'll need to read the 64-bit Guide for Carbon Developers; either way, you'll also need the general 64-bit Transition Guide and the 64-bit Transition Guide for Cocoa.
I am working on this process myself right now, and it's a fairly complex undertaking for a full document-based application that uses a few frameworks. My Carbon app has dozens of menu items, the interface is built with Carbon Nibs and implemented using Carbon event hooks. The programming language is C++. Going back in history, the original Mac classic version was implemented in straight C, so there's a little bit of legacy from that era too. Resource-based PICS for example!
There are several approaches one can take, so it depends on your particular situation how to proceed. In my case I decided to start with a bare Cocoa document-based project and start building the document loading code, because the hooks for that are already in place in the empty project. This seems like a good place to start for me, because it gets me into the mode of working with Cocoa and thinking about the app in terms of smaller pieces.
You really have to take a methodical approach and look at what your app depends on in Carbon versus which parts of your app are independent - for instance your abstract classes. If your app is in C++ there may be some pitfalls with converting over to pure Objective-C. Operator overrides can be tricky to notice, for example.
You can mix C++ with Objective-C, as described in Apple's Carbon-Cocoa Integration Guide and around the web you can find plenty of C++ wrappers for Cocoa foundation objects like NSStrings. So if you already have C++ classes that wrap CFString, these can come in handy.
Generally-speaking, you can leave your data storage just as it is. If you use malloc() and calloc() to make a linked list of structs, there's no special reason to move over to an NSArray. You won't get better performance. The real change comes in the interfaces, the way you call and access that data from other objects. If you decide to mix C++ and Objective-C objects in the same app it helps to encapsulate as much as possible. That is, as much as possible make your abstract C++ classes only refer to their own data and that of other C++ objects. Eventually this will make it easier to transition them to Objective-C.
If you're transitioning from one event model to another or from Carbon port-based imaging to Cocoa's views-based imaging, it's probably best to start with a fresh Objective-C app and bring over your model classes first. Add some test functions to make sure they all work within the new language. If your app is anything like mine (old) then it probably needs to display some things larger, and to have more polish in the interface. This is a good time to rebuild those parts piece-by-piece.
There's definitely no great shortcut. The PDF linked above is the best document I've found on the topic.
I'm trying to re-write an old image-viewing plugin for the mac. The old version uses QuickDraw (I said it was old) and resources (really really old) and so it doesn't work in Firefox 3.6 (which is why I'm re-writing it)
I know some Objective C, and so I figure I'm going co re-write this in that using new-fangled Mac routines and nibs, etc. However, I don't know how to start. I've got the BasicPlugin example that comes with mozilla source, so I know how to create a plugin with entrypoints, etc. However, I don't know how to create the nib, and how to interface Obj-C with the entrypoints, etc.
Does anyone know of a more advanced sample for mac than BasicPlugin.bundle? (Preferably simple enough that I can just look at it and understand it...)
thanks.
Sadly i don't really know of any good "intermediate" example. However, integrating Obj-C isn't that difficult. Thus, following is a short overview of what needs to be done.
You can use Obj-C and C/C++-sources in the same project, its just recommendable to keep them seperated to some extent. This can for example be done by letting the source file with the entry-points and other NPAPI-interfacing stay plain C or C++ files and e.g. forward calls into the plugin from there.
Opaque pointers help to keep a clean seperation, see e.g. here.
The main changes to your plugin include switching to different drawing and event models. These have to be negotiated in NPP_New(), here is an example for the drawing model. When using Cocoa and to support 64bit enviroments, you need to use the Cocoa event model.
To draw UI elements you should be able to use a NSGraphicsContext from the CGContextRef and then draw an NSView in the context. See also the details provided in this post and its follow-ups.
Greetings, I'm currently learning Cocoa and Objective-C. I've run through "all" the tutorials and I'm fairly comfortable with the ObjC language. What I'm looking for now is to learn Cocoa idioms and see real code used in nice-looking Cocoa apps.
It seems like serious apps (iTunes, etc.) don't just drop in the IB elements. They do a lot more with code to tweak them to look good. (Example: the iTunes playlist drawer. How does one go about getting that styling?)
Here are some examples of nice UI's that are open source that I've found:
Smultron (current home, open-source fork)
Transmission
Vienna
Gitnub
Any other suggestions on Open-Source apps that have great Cocoa user interfaces?
You might want to look at BWToolkit, by Brandon Walkin. It's pretty awesome, containing an elegant collection of UI elements and other objects. The source code is provided so you can see how custom controls and views were created.
Brandon even provides some walkthrough movies, such as "Creating an iCal interface in 3 minutes."
A few other open source apps to dig into are Camino, Colloquy for both Mac and iPhone, Adium, and Quicksilver (lots of UI customization).
I would prefer to create my interfaces programatically. Seems as if all the docs on Apple Developer assume you're using Interface Builder. Is it possible to create these interfaces programatically, and if so where do I start learning about how to do this
I thought the relevant document for this, if possible would be in this section: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html
I like the question, and I'd also like to know of resources for going IB-less. Usefulness (the "why") is limited only by imagination. Off the top of my head, here are some possible reasons to program UIs explicitly:
Implementing a better Interface Builder.
Programming dynamic UIs, i.e., ones whose structure is not knowable statically (at compile/xcode time).
Implementing the Cocoa back-end of a cross-platform library or language for UIs.
There is a series of blog posts on working without a nib and a recent description by Michael Mucha on cocoa-dev.
I would prefer to create my interfaces programatically.
Why? Interface Builder is easier and faster. You can't write a typo by drag and drop, and you don't get those oh-so-handy Aqua guides when you're typing rectangles by hand.
Don't fight it. Interface Builder is your friend. Let it help you.
If you insist on wasting your own time and energy by writing your UI in code:
Not document-based (generally library-based, like Mail, iTunes, iPhoto): Create a subclass of NSObject, instantiate it, and make it the application's delegate, and in the delegate's applicationDidFinishLaunching: method, create a window, populate it with views, and order it front.
Document-based (like TextEdit, Preview, QuickTime Player): In the makeWindowControllers method in your subclass of NSDocument, create your windows (and populate them with views) and create window controllers for them, making sure to send yourself addWindowController: for each window controller.
As a completely blind developer I can say that IB is not compatible with VoiceOver (the built-in screen-reader on OS X).
This means that without access to robust documentation on using Cocoa without IB I cannot develop apps for OS X / iPhone in Cocoa, which means I (ironically) cannot easily develop apps that are accessible to the blind (and all others) on OS X / iOS.
My current solution, which I would prefer not to use, is Java + SWT, of course this works for OS X, not so much for iOS.
In fact IB becomes totally unusefull when you start to write your own UI classes. Let say that you create your own button that use an skin system based on a plist. Or you create an dinamic toolbar that load and unload items based on user selection.
IB doesn't accept custom UI elements, so more complex UI can't use him. And YES you will want to do more complex things that the UIKit gives you.
Though this is quiet a bit old...
I tried many times to do everything only with programmatically. This is hard, but possible.
Update:
I posted another question for this specific issue: View-based NSOutlineView without NIB?, and now
I believe everything can be done in programmatical way, but it's incredibly hard without consulting from Apple engineers due to lack of information or examples.
Below argument might be off-topic, but I like to note why I strongly prefer programmatically way.
I also prefer programmatic way. Because
Static layout tool cannot handle anything dynamic.
Reproducing same UI state across multiple NIBs is hard. Everything is implicit or hidden. You need to visit all the panels to find parameters. This kind of job is very easy to make mistake - mistake friendly.
Managing consistent state is hard. Because reproducing same look is hard.
Automation impossible. You cannot make auto-generated input form.
Parameter indirection - such as variable element size chosen by user - is not possible.
Aiming small point is a lot harder than hitting finger sized keys at fixed location - funny that this is serious usability issue for developers!
IB sometimes screws. Which means it's compilable, and still working, but when I open the source, it looks broken and extra editing becomes impossible. (you may not experienced this yet, but if XIB file goes complex, this must happen)
It's image based serialization. The concept is good. But the problem is image-base only. IB doesn't keep the source code for clean boot by replaying the source code. Clean boot is very important to guarantee specific running state. Also, we cannot fix the bugs in source-code. Bug s just will be stacked infinitely. This is core reason why we cannot reproduce the equal(not similar looking) UI state in IB.
Of course these stuffs can be solved by post-processing NIB UI, but if we have to configure everything again, there's no reason to use IB at first.
With text code, it's easy to reproducing the same state - just copy the code. Also easy to inspecting and fixing wrong part - because we have full control. But in IB, we have no control on hard-core details.
IB can't be ultimate solution. It's like a Photoshop, but even Photoshop offers text-based scripting facility. GUI is a moving program, and not a static image or graphic. An IB approach is completely wrong even for visual editing of GUI. If you're one of the Apple folks reading this, I beg you to remove whole dependency to IB completely ASAP.