Re: Why initialize the menubar without Interface Builder
Re: Why initialize the menubar without Interface Builder
- Subject: Re: Why initialize the menubar without Interface Builder
- From: Jon Hess <email@hidden>
- Date: Sat, 3 Nov 2007 18:18:16 -0700
On Nov 3, 2007, at 2:06 PM, Uli Kusterer
<email@hidden> wrote:
Am 03.11.2007 um 20:39 schrieb Erik Buck:
The closest Jeff gets to telling us WHY is "There are a number of
reasons why you might want to build your application without a
nib. As you may know, ‘nib’ is an acronym for no inspecting
bindings. Anyone who uses version control ... can see in the diffs
that nib files are rather opaque."
I am sympathetic to the argument that development should not depend
on opaque data files. Wait a minute: .o files are opaque,
frameworks and static libraries are opaque, most xml files are
opaque or at least incomprehensible.
But those are mainly output files, which you wouldn't check into an
SCM system. The problem is not depending on opaque file formats, it
is that two people can edit a NIB at the same time, and then you'll
have to do a bunch of work to find out what each one did and
consolidate the changes. Many XML and source code files usually are
usually formatted and organized in a way that they can be diffed and
merged automatically by most version control systems.
There is a very nice tool that opens nib files and shows you their
contents. Why single out .nib files as the one non-source-code
development resource that isn't allowed to be opaque ?
It isn't, but in Cocoa, more of your app's "smarts" are in NIB files
than in e.g. Carbon (just to pick something more of you will
probably will be familiar with, I could also choose Windows resource
files or whatever). So, while usually only GUI changes like adding
new controls or moving them bore the danger of collisions, now
there's a lot more opportunity, if you have several people working
on one project.
Not to mention that it's fairly easy to accidentally disconnect a
binding or connection in IB, and you can't see that you did this by
looking at a diff of the file in the commit log.
Interface Builder files have a long way to go with reguards to
integrating with industry standard SCM systems. That said, you can get
consistently good diff results with Filemerge. Filemerge runs
Interface Builder documents through ibtool to provide a canonicalized
human readable textual representation of a NIB before presenting you
with a diff. If you have not already, try out the svn-view-diffs, cvs-
view-diffs, or opendiff scripts that ship with the dev tools. With
those tools, it's pretty easy to visualize a nib diff.
Steve Jobs once famously personally told me (OK - told everyone in
the auditorium) the following in approximately 1989: "Every line of
code is a potential bug and has a long term maintenance cost. It
doesn't matter if the line of code is machine generated or manually
generated. The initial cost to write a line is typically small
compared to the lifetime cost to maintain it, and machine generated
code is not magically bug free. The only way to reduce the cost of
software is to produce more features with fewer lines of code."
Yes, but connections and bindings are lines of code, too. It's just
that you can only view them as a graphic in IB, and no diff tool
right now can show it as such.
It seems perverse to me that anyone would invest any effort to hard
code user interfaces.
It seems perverse to me that someone would want to use NIBs in a
team of more than three developers, while you're effectively
blindfolded and can't even do a "code review" of the NIB changes
another developer did.
Having said all that, Interface Builder is not perfect or magic.
I usually prefer an easily human readable text file to a binary
file. I like plist files. I would like a tool that could output a
nice table that summarizes all of the bindings in a nib file. But
I like any data file better than the equivalent lines of code.
Well, IMHO it depends on the kind of code. One can use macros and
other things to pretty much make a source code file look like data.
In fact, in the end, code *is* data.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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:
40mac.com
This email sent to email@hidden
Sent from my iPhone -
Jon Hess_______________________________________________
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