Hmmm. The letting it create the files in the nib file sounds fine for me. But what about the linking and configuring? It's just all reflected in code correct? The dragging a pipe to one object to the other that just all shows up in the .m right? So that part can just be bypassed and done in xcode I assume and still remain "Cocoa" style.
On Wed, May 14, 2008 at 11:11 AM, I. Savant <[EMAIL PROTECTED]> wrote: >> I am reading my cocoa book and online tutorials atm. But one ting that >> totally irks me atm is using interface builder to create objects and >> instantiate them. > > Why? This is "the way it's done" in the Cocoa world unless you have > a very good reason not to. You can either get used to it or you can > fight the overall design (which is *not* trivial for anything beyond > the basics). IB saves you a *TON* of effort and instantiating an > object (I assume you mean controller-layer objects - surely you don't > have something against adding and arranging buttons and such in a > graphical environment) is common and perfectly acceptable. > >> I rather just make it in Xcode or Textmate and know what's going on >> behind the scenes. > > Using IB and knowing what goes on behind the scenes are not mutually > exclusive. I use IB and (because I thoroughly read the documentation) > know what's going on behind the scenes. If you'd still just rather do > all this yourself, you'll still need to know what's going on behind > the scenes ... so you can do it all yourself. > >> Might there be not a tutorial but more documented examples of creating >> a window, calling to the window, adding widgets(buttons and such) and >> altering an NSCustomView. > > Yes. ALL OVER THE PLACE. Google is your friend. As long as you have > and keep a reference to the window, you can get at its content view > and add whatever you want. Most views are created with -initWithFrame: > ... I guess I'm not sure what you're asking here but it seems to me > you're a bit misguided in the absence of information. > >> My goal is to make a drawing app from the Drawkit framework but for >> the life of me I just can't get past the use IB but Drawkit does not >> use IB but the books do and swear that I should fiasco! Ah ha ha ha ha >> h haha h hah aa haa > > Heh ... hilarious. But seriously, what you're trying to build is > largely irrelevant. If it's a full (Cocoa) application you're still > *always* going to have far less work to do by learning to use the > tools properly (and trusting that they're useful - believe me, > thousands of shipping applications whose UI were built using IB can't > be wrong). > > As to DrawKit ... I'm familiar only with its name and that it > exists, but whether or not it "uses IB" shouldn't matter. I have many > custom views within my applications. I drag a generic 'custom view' > into my window, placing and sizing it where needed, then set its class > to my custom view's class. Instantly all its outlets are available for > me to connect to/from. Sure, it doesn't 'do its thing' live in IB, but > lots of things don't. When I run it, it behaves as expected. > >> I miss CSS when it comes to just laying out an interface. Yes I do >> know about Widgets do that, but would a Sketch app use something like >> that? > > A few points: > > 1 - This is Cocoa, not web development. To develop a Cocoa app means > using the proper tools which are *not* the same as the proper tools > for web development. You won't get any sympathy here when it comes to > that point. > 2 - Sure, you could build a hybrid application that uses WebKit to > display the UI but ... YUCK and OUCH. Yuck because it'd be quite > un-Mac-like and Ouch because you lose all the advantage of a > platform-native user interface, which directly translates to *FAR MORE > WORK*. Again, if you're trying to write a Cocoa app, use the right > tools, if you're trying to write a web drawing application, you're in > the wrong place. > 3 - Sketch (if you're referring to the example in the Example code > in your /Developer folder) was built with Interface Builder (using a > custom view as its primary "canvas") and is a fully-native Cocoa > application. It has nothing to do with CSS, etc. > > In summary, spend more time learning how to actually use Interface > Builder with a simple test project, then spend time doing the same > thing with code (yes, there are plenty of examples, just search for > them; if you can't find something specific, post a specific question). > If you want to create an application entirely in code, more power to > you. Me, I'm a lazy, lazy man and enjoy the fact that (most modern) > platforms have evolved such that these ridiculously tedious (and error > prone) tasks are abstracted away into a high-level GUI application. > Simply maintaining (let alone initially creating) such a mess turns a > three-second adjustment into a potentially-hours-long rewrite. I cite > the task of simply creating and configuring a rounded-rect-style > button and adding it to some deeply-embedded subview. > > Good luck! > > -- > I.S. > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
