Cocoa mail archive
Re: Why initialize the menubar without Interface Builder
FROM : Jon Hess
DATE : Sun Nov 04 02:18:16 2007
On Nov 3, 2007, at 2:06 PM, Uli Kusterer
<witness.of.<email_removed>> 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_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/jonathanhess%
> 40mac.com
>
> This email sent to <email_removed>
Sent from my iPhone -
Jon Hess_______________________________________________
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>
DATE : Sun Nov 04 02:18:16 2007
On Nov 3, 2007, at 2:06 PM, Uli Kusterer
<witness.of.<email_removed>> 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_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/jonathanhess%
> 40mac.com
>
> This email sent to <email_removed>
Sent from my iPhone -
Jon Hess_______________________________________________
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>
