I'll be forever grateful for the sources/help I can get. I'm working as a software engineer and we are now planning on porting our applications to OS X, but I have some issues finding info on how to build a GUI from ground up NOT using the interface builder and nib files, our GUI's are advanced and are highly dependent on states in the application.

I have been googling around for a couple of days and haven't found anything else then intros on how to use the Interface builder to do the GUI stuff, if anyone can supply me some information on where to start or some sources / how to / Podcasts on how to do this I'll be more then grateful.

Tanks.

Graciac gracion ;)

I will check it out, but maybe you could answer me this?

If I load the NSApplication using the sharedApplication: method and then call the runModalForWindow: wnd

is this the way to do it if I want to code the entire gui? or do you have something else to recommend?

*** EDIT

I may add that I'm used to program in QT and C++ and I always code the GUI's from ground up, even if it's a simple GUI or not, this is to maintain the best knowledge possible of the Framework and the GUI code since it's not in my nature to code something and not knowing what's happening in the background. I'll might be old fashion, but it has kept our software in shape and it's always easy to maintain since we can apply a single coding standard and everyone knows where to look etc even when we switch between frameworks / languages.

And yes, we could use QT for this, but since it's going to be a native OS X application we have made the decision to go with Cocoa and Objective-C

Tanks /SneWs

Just to throw my 2¢ worth in as well...

I used to code a lot of GUI stuff when I first started programming the Mac back in the 80s. At first it felt good because I was "in control" except after a while just to get something good looking I'd end up spending vast amounts of time tweaking things pixel by pixel (or else leave it looking like a dog's dinner).

Once I let go a bit and used ResEdit (as it was then) to lay out my GUIs the appearance of my apps improved dramatically and the time spent on coding the GUI dropped dramatically as well. I've never looked back.

Interface Builder is infinitely better than ResEdit ever was, and there's just no good reason not to use it. You might feel that you are giving up too much to code working behind your back that you cannot see, but in fact that's not really the case - all that loading a NIB does is all the chores of creating and positioning all your controls, then hooking them up to your data members and action methods (OK, more than that if you use bindings, but let's keep the discussion simple). As far as I can see IB does not restrict you very much, except in the sense of going with the flow instead of going against it, which is a good thing anyway.

Using IB does not in any way prevent you from creating a "dynamic interface", whatever that means in your terms. You can use IB to set up entire views, or parts of views, just as much as complete window layouts, and you can write code to make use of those smaller pieces if you so wish. A typical trick for switching views I use is to use a tabless tab view and simply lay out each tab in IB then the code switches the invisible tabs to select different views.

I cannot think of any programming task where IB would hinder more than help, so I strongly recommend not trying to avoid it. Handling all that GUI stuff yourself is exceedingly tedious, won't look good without a great deal of time spent, and will be much more difficult to maintain, localise and tweak than using IB.

SneWs,

Sorry, -runModalForWindow is for temporarily putting up an alert, and only in rare cases where the user must be forced to respond to the alert before doing anything else. Notice the 1st discussion paragraph in the ref doc about how the entire app UI is disabled.

At minimum, you can put the minimum UI items that you will always use (a blank window, the basic menus) and you will not be wasting any memory (and saving time). Then, in your application delegate class (the top-level controller class in MVC), have an instance variable connected (yes in Interface Builder) to your window in the nib. Use that reference to add UI items programmatically--there's your hand-coding, and plenty of it. It won't be as efficient as having the items you normally use in the nib file, and will take longer to create, debug, and maintain.

Also, you could programmatically instantiate an NSWindow, populate it with views and controls, then I think you just call -makeKeyAndOrderFront (don't hold me to that). But you're really going to need to know a lot more about low-level stuff: event loop, responder chain, how views work, etc.

As suggested by the comments, no experienced Cocoa programmer who would do away with Interface Builder and nib files. Even though this is different than your standardized approach, coding to a native framework requires specialized knowledge anyway. Put comments in your code like "See main.nib for starting menu contents and windows".

Apple (and NeXT) engineers have spent many years optimizing and debugging the frameworks which the nib file resources leverage. While you are obviously an expert programmer, it would be quite difficult to improve on this from an optimization standpoint. Also, this is premature optimization.

As I see it you have 3 paths to choose from:

1. Base your implementation on the tutorials using nib file resources, the proven, robust, efficient, easy way to create Mac apps. You can still avoid the extra nonprogrammatic stuff like bindings (although they're efficient and easy) and Core Data. Skim over the Cocoa Fundamentals Guide to get your bearings. "The code you don't have to write is the code you don't have to debug and maintain."

2. Spend weeks studying the low-level Mac app implementation, including a throughrough read of the Human Interface Guide, Cocoa Fundamentals Guide, the Objective-C Programming Language (for the runtime), probably the Model Object Implementation Guide, and of course all the Application Kit reference docs for all the programmatic methods you'll need to replicate what IB does for you. (I'm not trying to be hyperbolic--its just that you'd be reinventing a huge wheel.)

3. Pick out a few classes and methods (well, like -runModalForWindow) and create some kind of non-Mac interface that Mac users will hate. Not just because it's different, but because they won't be able to figure it out, and those that figure it out won't be able to use it in the ways they want.

SneWs, I appreciate the polite approach you've taken and your willingness to tackle a new platform. We welcome you to the Mac developer community. Like Graham, some of us date back to pre-resouce days, but we think Cocoa rocks, and we think you'll dig it too. Maybe it's time to let go of some ideas that work for you elsewhere, and consider a different approach.

One again gracion, tanks.

I have spent the last 48h on coding with cocoa and setting up some test projects etc, I found a simple way to actually skip the designer stuff, using the setDelegate: to a custom NSApplication pointer, BUT it sure is a lot simpler to use the awakeFromNib: and hook it from the Interface builder, I have actually starting to get used to the approach using IB. ( Will probably do some tests using designer generated views etc to ) =)

- "Maybe it's time to let go of some ideas that work for you elsewhere, and consider a different approach."
Yeah, can't argue with that =)

I feel that this is going to be one of the most exciting steps in my career as a developer, not just because it's a new platform, but because it's a very rich framework and it provides a gorgeous UI from start.

gracion, really appreciate the answers you have provided me with, they have been really helpful. And now, it's back to the documentation and XCode.

Graham_Cox, tanks for your comment, as in earlier discussion with both you and gracion I have had some time to continue try stuff out.

As I come from the world of C++ and QT/KDE and C#.NET (Windows/Mono) I'v grown used to code GUI stuff by hand, even if .NET provides form designers etc they are not needed and in QT you also have GUI designer tools but it's just a code generator.

I have never liked to work with thinks I don't understand, I have been taught that code generators is good as long as you understand what they do and generate so that you can fix bugs, optimize the generated code if needed (have been fortunate enough to not run into those problems as often as one can think).

"Until you try both approaches and compare them with profiling tools, you cannot make any "intuitive" judgement about memory and/or speed in advance"

You are def. right about that, the thing I had in mind writing that was that you can improve overall memory usage if you don't need to instantiate controls/objects until they are needed, and in GUI programming that can mean great startup time improvements etc. Of course this is something you need to test and tweak from case to case.

"One of the things you're likely to run into, whether you like it or not, right or wrong, is that Mac users are very picky about their apps and have certain expectations"

This is something I actually like, I my self is very picky about applications look and feel, and Apple is the reference for great looking GUI's even when I do windows, Linux applications, the soft touches and the simplicity is just overwhelming.

I must say that I'm very impressed by the answers I have gotten from this thread, you have been very helpful =)

* Side note:
The application I'm planning will be for the business segment including PBX / PAM stuff. Theirs no timeline for this project, still in R&D.

I have to disagree with iluvcapra. Carbon is effectively deprecated, what with it not being ported to 64-bit. I wouldn't be surprised if Apple stops updating it completely in the future. XML nibs are also still serialized (keyed) object graphs and nearly impossible to even edit by hand (I've tried), much less create.

Unless you can point to a reason why you shouldn't be using nib files, you should. That said, there are ways to get around it...for applications that /don't/ use/need a normal UI. The way Cocoa programmers get over the startup time/memory issue, BTW, is to have seperate nib files for UI elements that aren't loaded at the same time. (Don't go overboard with this, though; loading a second file takes time too, of course, and a bit of extra memory as well.)

This vaguely applies, but it appears all iPhone apps will require building the GUI completely from code:

http://furbo.org/2008/02/11/so-youre-going-to-write-an-iphone-app/

And you write the iPhone apps in ObjC. This should be eye-opening.

> but it appears all iPhone apps will require building the GUI completely from code

This is totally out of date. IB3 has supported iPhone GUI development for some time now.