Re: Bypassing Interface Builder
Re: Bypassing Interface Builder
- Subject: Re: Bypassing Interface Builder
- From: colo <email@hidden>
- Date: Wed, 14 May 2008 11:35:38 -0400
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@hidden> 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 (email@hidden)
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:
This email sent to email@hidden