Re: Bypassing Interface Builder
Re: Bypassing Interface Builder
- Subject: Re: Bypassing Interface Builder
- From: Wayne Packard <email@hidden>
- Date: Wed, 14 May 2008 09:26:09 -0700
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@hidden> 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@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
_______________________________________________
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