This chapter introduces Interface Builder, a tool no less important to Cocoa development than Xcode itself. IB is used as a straightforward tool for laying out windows and views. You’ll see how to set the many options for automatic sizing of embedded views and how to use Interface Builder’s own simulation mode to verify that your layout and sizing choices work.
this article touches on one of the more friendly parts of IB, and seems to do it well.
i do have alot of gripes though, i’m sure primarily because despite doing cocoa apps in my spare time, i’m still mainly doing win32 development.
1. it doesn’t feel like IB and Xcode are REALLY integrated despite one needing the other like a person needs eyes. yeah you feel/smell/augment your visual senses, but its still not as good as being able to actually see.
2. xcode/ib hide alot of backend details, which seems to make developing new controls a bit more tedious than they would be in MFC/WTL/Qt, etc.
3. IB overall feels a bit archaic compared to whats available for other platforms.
4. the apple merge tools that one makes heavy use of in Xcode/IB feel very unintuitive to me. compared to say codewarrrior’s, or any other dedicated merge tool.
I concede that some of my opinions may be due to my day job, as well as being relatively new to the platform in terms of developing applications for it.
Also, considering how nice many OS X applications feel (both Apple’s and other 3rd parties) i’m also willing to admit that maybe its just vastly more powerful than what i’m used to and hence why it feels a bit awkward.
IB is really powerful, but I agree, I had to retrain myself from GUI development-by-hand on other platforms. You can still create visual elements in code, but its so much faster in IB.
What I really miss (though I never really got to use it) is the Enterprise Objects framework, which let you tie your programs to databases very easily. It got replaced by WebObjects, which was then migrated to Java, which is being abandoned by Apple now as an app development platform 😛
3. IB overall feels a bit archaic compared to whats available for other platforms.
True. Either I’m too dumb or they are not there, I really miss dynamic layout managers – IB is nice for simple and static UIs, but I’m not sure how I would do complex UI layouts for which for example Swing is really well prepared. I am also baffled that with OS X being advertised as having a mostly vector and PDF based UI engine, the entire Application Kit and IB seem to make assumptions about fixed font and widget sizes. I remember that 12 years ago on the Amiga, good applications had font-sensitive UIs with layouts that didn’t mess up when you changed the system font or size. Similarly, Swing can handle different font sizes on different platforms nicely. On OS X, I can’t even change the font size unless I apply 3rd party hacks, which then destroy an applications layout.
4. the apple merge tools that one makes heavy use of in Xcode/IB feel very unintuitive to me. compared to say codewarrrior’s, or any other dedicated merge tool.
So true. If anyone knows any tool for OS X that compares to Araxis Merge, I’d be happy to hear about it.
3. IB overall feels a bit archaic compared to whats available for other platforms.
<p>
True. Either I’m too dumb or they are not there, I really miss dynamic layout managers – IB is nice for simple and static UIs, but I’m not sure how I would do complex UI layouts
<p>
Well, you can specify how your widget will react (change its size) when the parent widget size change.. The spring model (child->parent) is simple but will do what you want in a very clear way. Now, there’s some cases where this resizing model is a bit too simple, but that can generally be easily done via multiple views (eg putting views as subviews) or having a custom view. Overall, the resizing model in IB has more advantages than inconvenients.
<p>
Now, IB doesn’t handle “font size changes”, but for a good reason: it’s a bad idea ! IB let you do wysiwyg; and font size changes will only completely mess up your layout. Beside, the right approach to what is generally achieved with such font changes (eg, having a bigger UI) should be done at the display level (eg, zoom). Note that NOT using “dynamic layout managers” let you create very precisely your UI; which is helpful for creating good looking UI… but well.
<p>
Cocoa itself is vectoriel, but the pixmaps used for the Aqua theme aren’t; you can actually set a different zoom/dpi level easily, but as osx doesn’t have multiple pixmaps with different sizes, it just look a bit ugly when you zoom 😉 — hopefully the next version of osx will do that properly.
Here is a good starting place for Win32 devs
http://developer.apple.com/documentation/Porting/Conceptual/win32po…
I am looking more and more into OS X development to get away from Win32 if possible but I would prefer to avoid C family languages , alough on saying that I am interested in Objective-C as it looks a much simplified and less risky than C++ behemoth.
What is bad for OS X is the lack of Apple support for .NET/Mono and other languages and Im guessing they do not integrate withint xCode well. I dont want to drop to the shell to run cmd line compilers if possible I would like to stay 100% withing the xcode or other IDE.
Alot of opensource will just be Linux ports and look ugly GDK or other X11 toolkits or shell tools which really defeats the purpose of running on a Mac.
Does OS X have a datapicker control I can just plop into IB?
I mean Date Picker control. stupid OSNews still is broke and doesnt allow edits.
I mean Date Picker control. stupid OSNews still is broke and doesnt allow edits.
You have three options.
A NSDateFormatter for an NSTextField (which just forbids non date like characters, IIRC)
A NSDatePickerCell which just gives the up/down arrows, and a ?/?/? style (i.e. click in the first ? and click the up/down). This is for use in Tables or whatnot.
A NSDatePicker, which is a hybrid of the two (so to speak). It’s like a NSTextField, but with the up/down arrows next to it. You could still click on the month field (or whatever) and type in the desired value instead of clicking on the arrows like a monkey.
The first and the third, you’ll find in the Cocoa-Text palette in Interface Builder. The second you’ll find in the Cocoa-Data palette.
If you’re looking for something that’d pop up a Calendar or something, I don’t believe that exists in anything Apple distributes.
What is bad for OS X is the lack of Apple support for .NET/Mono and other languages and Im guessing they do not integrate withint xCode well. I dont want to drop to the shell to run cmd line compilers if possible I would like to stay 100% withing the xcode or other IDE.
Well, I can’t speak too much about C#, but Xcode can play nicely with a lot of other languages. You can extend it from the basics, such as color syntax highlighting for other languages (PHP, perl, python, ruby, I think I’ve even seen it for Mono) via simple pblangspec’s one can download, to having complete control over the project where you wouldn’t need to drop to a shell to compile it (obviously Make files are supported natively, Xcode also comes with support for Ant projects, and others are available via 3rd party).
What you’ll probably lose out on is debugging, if it can’t be easily debugged through GDB — Although xcode has support for debugging Java, so it might just be a matter of finding another 3rd party plugin.
I would recommend using wx.net (http://wxnet.sourceforge.net/). It provides cross platform portability and uses native widgets for the actual rendering. Combined with Mono, it would be a pretty usefull platform. This should have been the manner in which Windows.Forms should have been implemented in Mono.
Platform specific API’s are going to be a thing of the past but actual GUI rendering should be native.
Basically I want the impossible Ability to use xcode or some VS.NET quality IDE along with managed code and ALL the features OS X has to offer. Seems its not really possible until maybe 2 years down the line or more.
Keep Dreaming
I want Visual Studio 2005 for Mac