Re: Why initialize the menubar without Interface Builder

FROM : Chris Hanson
DATE : Sun Nov 04 02:45:45 2007

On Nov 3, 2007, at 6:10 PM, Erik Buck wrote:

> If you have more than three developers who need to
> edit a single nib file, you have a serious problem.


This is not always the case.  Perhaps two developers want to make non-
overlapping changes to the same user interface.  This is perfectly 
well accommodated by either writing the code for the user interface 
directly (instead of using Interface Builder), or by using a format 
that has been designed to be diff-able and merge-able from the ground 
up like XAML.  You don't even need layout managers or anything like 
that, just a way of representing the object graph

This is one of those cases where there really is no trade-off: 
Interface Builder *could* support textual nib files that *do* handle 
diff and merge straight from SCM tools reasonably well.  It just 
*doesn't*.  No capabilities of the current system would be lost, and 
there would be straightforward developer benefit for what are becoming 
increasingly common cases.

> Of the ten concurrent developers, the
> usual number of GUI developers is exactly one.


This has almost never been my experience working on applications in 
teams; typically, everyone in the team will work on different aspects 
of its human interface.  Even modularizing the system into many nib 
files doesn't always prevent people from having to make simultaneous 
but non-overlapping changes to them.

> I don't think these problems with IB and nibs raise to
> the level where I would prefer to hard code all
> aspects of a GUI.


I don't think they do either.  However, that it's possible to hard-
code everything specified in a nib, and that the hard-coded version is 
diff-able and merge-able via textual SCM tools, is a proof that nibs 
themselves could be diff-able and merge-able via textual SCM tools.

  -- Chris