Re: Bypassing Interface Builder

FROM : Wayne Packard
DATE : Wed May 14 18:26:09 2008

Are you asking whether IB just generates code in a .m file to draw UI 
(in the same way something like NetBeans does for a Swing UI)?  If so, 
the answer is no.

If that isn't what you're asking, could you rephrase the question? :-)

wp

Sent from my iPhone

On May 14, 2008, at 8:35 AM, colo <<email_removed>> wrote:

> 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_removed>> 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_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>