It sounds to me that you want too badly for it to be like other IDEs. You need to stop this if you want to be able to use it effectively. Interface Builder is different because it's not a GUI Code generator like in other IDEs. It generates archived objects that are supported by the Obj-C runtime, and links them to IBOutlets in your code when the nib files are loaded by the runtime. I really don't know what you mean by "Apple doesn't want you to know how the damn thing works." It takes time to get the hang of it, but there's nothing that's actually mysterious about it - and it is explained in the documentation.
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).
I wish Apple would stop messing with the UI of Xcode, and simply make their debugger work. The debugger is so broken, I don't even know where to begin. Breakpoints sometimes don't work, watchpoints don't work, expressions don't work. The debugger crashes trying to view C++ objects.. etc etc. It's a complete cluster-f*ck. And here they sit playing around with UI elements. Its pathetic.
And, least anyone think I'm just venting, I had a friend that went to work for Apple on Final Cut Pro. I asked him "Hey, how do you deal with the fact that Xcode's debugger is so broken?" He said "We mostly just use printfs." This is an Apple engineer, admitting that they can't even use their own tools to debug their own products. Does anyone realize how completely messed up this is????
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.
Quote:
Originally Posted by anonymouse
Maybe it's just me, but I find the notion of a language that depends on indentation as syntax deeply disturbing.
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.
It sounds to me that you want too badly for it to be like other IDEs. You need to stop this if you want to be able to use it effectively. Interface Builder is different because it's not a GUI Code generator like in other IDEs.
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.
Quote:
It generates archived objects that are supported by the Obj-C runtime, and links them to IBOutlets in your code when the nib files are loaded by the runtime.
Yes and try finding an explanation about how that is done.
Quote:
I really don't know what you mean by "Apple doesn't want you to know how the damn thing works."
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.
Quote:
It takes time to get the hang of it, but there's nothing that's actually mysterious about it - and it is explained in the documentation.
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.
I haven't seen any of your applications, but I instantly hope that it's not only your arrogance that can be labeled as pro.
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.
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.
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.
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.
Finally got your point. Took (translated) amateur falsely as a abusive remark.
So now we'll have another 500,000 apps to choose from since Xcode 4 development is so easy? Hmm, "there's an app for that" could become "well, there's 4,000 apps for that, good luck wading through them all".
Frankly I've never seen anything as ugly as ugly as the combo of XCode and interface builder. I've never gotten the hang of it and have found that building an interface in code is often easier. The platform is just completely unlike just about every IDE out there and for the life of me I don't know why it is so complex.
Of course it might not be complex but rather I haven't oriented my mind to it. It's possible but I blame that on the lack of any good tutorials that explain what is going on. It is almost like Apple doesn't want you to know how the damn thing works. It is just a disgusting piece of software.
Dave
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.
Yes... kids often have the imagination but not the skill, and adults often have the skill but not the vision. Perhaps to become skilful, you must repeat the same patterns of action over and over to perfect them, and in doing so your neural connections get locked-in and unable to go off on flights of fancy any more.
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.
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.
Comments
It sounds to me that you want too badly for it to be like other IDEs. You need to stop this if you want to be able to use it effectively. Interface Builder is different because it's not a GUI Code generator like in other IDEs. It generates archived objects that are supported by the Obj-C runtime, and links them to IBOutlets in your code when the nib files are loaded by the runtime. I really don't know what you mean by "Apple doesn't want you to know how the damn thing works." It takes time to get the hang of it, but there's nothing that's actually mysterious about it - and it is explained in the documentation.
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).
I wish Apple would stop messing with the UI of Xcode, and simply make their debugger work. The debugger is so broken, I don't even know where to begin. Breakpoints sometimes don't work, watchpoints don't work, expressions don't work. The debugger crashes trying to view C++ objects.. etc etc. It's a complete cluster-f*ck. And here they sit playing around with UI elements. Its pathetic.
And, least anyone think I'm just venting, I had a friend that went to work for Apple on Final Cut Pro. I asked him "Hey, how do you deal with the fact that Xcode's debugger is so broken?" He said "We mostly just use printfs." This is an Apple engineer, admitting that they can't even use their own tools to debug their own products. Does anyone realize how completely messed up this is????
they rewrote it. based on LLVM, and is called LLDB.
there is a special video about it, ? looks good, check it out!
Maybe it's just me, but I find the notion of a language that depends on indentation as syntax deeply disturbing.
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
It sounds to me that you want too badly for it to be like other IDEs. You need to stop this if you want to be able to use it effectively. Interface Builder is different because it's not a GUI Code generator like in other IDEs.
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.
It generates archived objects that are supported by the Obj-C runtime, and links them to IBOutlets in your code when the nib files are loaded by the runtime.
Yes and try finding an explanation about how that is done.
I really don't know what you mean by "Apple doesn't want you to know how the damn thing works."
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.
It takes time to get the hang of it, but there's nothing that's actually mysterious about it - and it is explained in the documentation.
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
I haven't seen any of your applications, but I instantly hope that it's not only your arrogance that can be labeled as pro.
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.
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
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!
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.
Finally got your point. Took (translated) amateur falsely as a abusive remark.
Time to apologize.
So now we'll have another 500,000 apps to choose from since Xcode 4 development is so easy? Hmm, "there's an app for that" could become "well, there's 4,000 apps for that, good luck wading through them all".
Seconded.
C
Frankly I've never seen anything as ugly as ugly as the combo of XCode and interface builder. I've never gotten the hang of it and have found that building an interface in code is often easier. The platform is just completely unlike just about every IDE out there and for the life of me I don't know why it is so complex.
Of course it might not be complex but rather I haven't oriented my mind to it. It's possible but I blame that on the lack of any good tutorials that explain what is going on. It is almost like Apple doesn't want you to know how the damn thing works. It is just a disgusting piece of software.
Dave
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.
Yes... kids often have the imagination but not the skill, and adults often have the skill but not the vision. Perhaps to become skilful, you must repeat the same patterns of action over and over to perfect them, and in doing so your neural connections get locked-in and unable to go off on flights of fancy any more.
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>
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.
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.
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!