Inside Apple's new Xcode 4 development tool - Page 3

Can't wait to give this a try. I hated the separate apps and crazy window arrangements from XCode < 4

Actually, while I agree with you mostly, the big problem that I find is the documentation itself is somewhat confusing. More than likely, this is a situation that with more time with it, it would make more sense. For most people, understanding and development process is a bunch of "Ah-ha" moments when things finally click into place. Right now, I am having some difficulty with the full understanding of how tables are made. For someone who has been developing for over 20 years, the idea of "It just does" doesn't sit well with me (but I'll get there).

Basically, what I was trying to say is the documentation could be a bit easier to read. Other than that, it is a great resource. (They could take a page from php.net, and how they did their documentation. Docs plus user comments can be very helpful).

they rewrote it. based on LLVM, and is called LLDB.
there is a special video about it, looks good, check it out!

The indentation thing though is very much a mixed bag.

When XCode turned a perfectly good piece of Python code into a mess that wouln't even format properly in the original editor it is extremely frustrating to say the least. While I don't finding the concept disturbing in practice it does not work well.

The problem is I'd have to move to another scripting language and I'm not sure where to go. I really like Pythons clean one way to do it approach.


Dave

Exactly! Very frustrating to say the least. By the way I don't like the term code generator here as that is not exactly the case all the time.

Yes and try finding an explanation about how that is done.

Have you ever seen an explanation about HOW it works? Not what gets done but HOW. Everytime it is brought up the question is sweep under the rug.

In a nut shell that is the problem, the alternatives don't require this effort. For admittedly simple apps I find it much easier to do the interface I code. IB becomes a distraction or impediment to rapid development.


Dave

It's not arrogance to assume that people who do software development for a living would be better at it than those that do it as a hobby, it is just common sense. Human beings don't get better at things by magic, but by repeating them.

Here
And Here
And last here

Pretty much show you how to use Outlets and Actions, how they work behind the scenes, and how Interface builder works. Took me 3 seconds on developer.apple.com to find.

It's pretty simple how it works. All the elements you use to make a GUI in IB are objects that get saved (or if you prefer serialized or some say freeze dried) in the .nib file. So let's say you have an NSButton in your interface. All of the information about it, like its size, text, position, and what method to call are saved in the nib file. When the nib file is loaded at runtime either automatically in the case of MainMenu.nib or if you do it explicitly for some other part of your interface, the runtime reads the nib and does an [[NSButton alloc] init] and then proceeds to set all the values on that NSButton. At runtime what you get is an NSButton object in memory with all it's attributes set and ready to go.

IBOutlet and IBAction are just macros in your code that get stripped out at compile time, but help Interface Builder better identify which parts of your code are destined to be wired up to the interface elements.

This differs from other approaches where when you create GUI elements actual compilable code for that element is generated in your project.

One of the good things about the IB way is that there is a great separation of View and Controller. In the IDEs that generated code for your elements people often times put their application logic right in the event handler for the control. The problem comes is what happens to all that application logic if you decide to delete the button? You would think that this wouldn't happen much, but you would be surprised at what you see some software engineers do.

All in all I much prefer the Interface Builder way of dealing with interfaces. The one pain point was keeping your custom classes from Xcode in sync with IB. It sounds like this will be a thing of the past in Xcode 4.

Long live ctrl + drag to wire up interfaces!

Finally got your point. Took (translated) amateur falsely as a abusive remark.

Time to apologize.

Seconded.

C

offcourse this would be great for macruby and hotcocoa

This looks like a fantastic update! Is there anything said on when it's expected to be released?

Having been a Visual Studio programmer for longer than I care to admit I too found Interface Builder baffling at first and the whole Model-View-Controller thing took me a day or two to wrap my head around; I understood the words and how they formed sentences but I didn't truly understand the concept till doing it a few times.

The worst part of the IB, I thought, was that I had to manually hook up stuff, it just seemed dumb, there seemed to be a lot of unnecessary steps but it was because I was still thinking of it like a VS programmer. It's truly a paradigm shift that requires you to forget how you think of forms and form items and think of them in the MVC paradigm. Forms are no longer repositories for code like in VS but are purely Views. All your code, even form validation stuff, goes in a controller. This seems odd at first but after you start to understand it you realize it's like you've been wearing socks on your hands and mittens on your feet; it only seemed strange because you've been doing it wrong all this time.

Anyway, I was able to quickly get over my logical hump (my lovely logical lumps?) using Cocoa Programming for OS X (3rd Edition) from Nerd Ranch. It doesn't waste a lot of time and gets right into programming pretty quickly. It's not the end all, be all that some claim it to be but it forces you to actually do what it just taught you to prove you really learned it. Also, it get's pretty boring pretty quickly but it is a programming book not Sci-Fi. Overall though it helped me tremendously and I'll be buying their Advanced Mac OS X Programming (2nd Edition) this weekend.

Well said though I disagree with your conclusion. Youth fights against the norm because it wants to make the world in its own image not that of its father. After fighting for and winning change to its way of doing things it doesn't want some young punk that hasn't been doing it for as long as it has to come along and change it all; youth has become the aged. This is the pattern people follow but rarely break. It's not just programmers, it's everyone.

If you want to make sure you don't get crushed in the ever turning gears of progress you must not only be open to change but embrace it. You must be the one looking to change things for the better; not just a passive recipient of someone else's change. You must champion change even if it destroys something you built because the new thing you build will be even better.

</philosophical propaganda>

That's very good.

Hopefully in this new version of Xcode, Apple will let us develop Carbon C++ applications again, as in Xcode 3.2 they removed it.
Not that I like Carbon or I want to develop with it, it's just cool to see how bad the classic controls and stuff are.

I'd say no! Since the carbon framework is
- obsolete for some time now
- 32bit only
- XCode4 has an all new interface builder.

lets be happy to have a framework like Cocoa!