Why initialize the menubar without Interface Builder

  • There is a current discussion "Re: Initializing the menubar without Interface Builder."  What I desperatly want to know is WHY ?


      Jeff Johnson has kindly provided a series of articles about HOW to do it, but not WHY at http://lapcatsoftware.com/blog/2007/07/10/working-without-a-nib-part-5-open
    -recent-menu/



      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.

      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 ?

      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."

      If there is an opportunity to use a data file instead of code, choose the data file every time.  Interface Builder exists to produce data files that replace tens of thousands of lines of code.  One of the reasons that other "Interface Building Tools" frequently suck is that the generate code instead of data files.  You end up with lots of yucky code to maintain forever.

      It seems perverse to me that anyone would invest any effort to hard code user interfaces.

      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.
  • 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.

    > 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
  • On 3 Nov 2007, at 4:06 PM, Uli Kusterer wrote:

    > 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.

    I'm sure you mean more than I intend to address, but isn't this
    analogous to giving more than three developers simultaneous rights to
    edit a JPEG? As in, isn't that a _very_ bad idea, and one of the
    reasons SCM systems offer locks?

    — F
  • Am 03.11.2007 um 22:44 schrieb Fritz Anderson:
    > I'm sure you mean more than I intend to address, but isn't this
    > analogous to giving more than three developers simultaneous rights
    > to edit a JPEG? As in, isn't that a _very_ bad idea, and one of the
    > reasons SCM systems offer locks?

      I was being a bit flippant here. :-p When someone says something
    outrageous that starts with "It seems perverse ...", I sometimes just
    can't help myself :-)

      Anyway, the main difference is that a JPEG is a single image, while
    a NIB may contain several windows and other objects. They don't really
    compare too well. JPEGs are, well, "atomic", for lack of a better
    word. More single-purpose. Few JPEGs are complex enough that you would
    have the need to "merge" several changes. A Photoshop file with
    various layers and text layers, where different developers change
    different parts is almost as un-manageable as a NIB.

      And locks don't help when you're working with branches, because then
    NIBs and JPEGs and PSDs are impossible to merge back if someone
    changed something in the trunk. But NIBs that use bindings and
    connections contain complex logic that's harder to merge over, but
    will change more often than the typical image file (or a "simple" NIB,
    like Carbon still has them), and if an image is wrong for one dot-
    release, it's not as fatal than if one outlet didn't get connected,
    which can make the whole app go brain-dead.

      And while you can occasionally split up a layered image file into
    several and composite them at runtime, you can't usually do that to a
    NIB, because you have to keep certain objects that interact in the
    same file, e.g. because one has an outlet that points at the other.
    Hence, even if you don't have a branch at this time, locking NIBs may
    mean that you either have to be very short and quick in your commits
    when you lock a file, or half the team is waiting to be able to change
    a NIB and get on with their work.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On Nov 3, 2007, at 3:39 PM, Erik Buck wrote:

    > There is a current discussion "Re: Initializing the menubar without
    > Interface Builder."  What I desperatly want to know is WHY ?

    Do you mean that I need to explain why I "think different"? :)

    Seriously, let me try to answer your question.  For me, I usually
    find it easier and more powerful to work with code-defined GUIs, but
    in order to do this I need two things that don't exist in all GUI
    libraries, and don't seem to exist by default with Cocoa.  I'll
    explain those two things below.  Let me just say, I do *not* want to
    define a GUI like this:

        button = new Button();
        button.X = 231;
        button.Y = 54;
        panel.add( button );
        ...

    where I manually specify coordinates and dimensions.

    The two things I need are:

    1. "Layout managers", or whatever you want to call them.
    2. A way to use declarative language.

    If these things are not present, then building them can be more
    trouble than it's worth.  But in my case, I don't mind building them,
    and I am working on connecting Cocoa to another language (Scheme),
    which will give me #2.

    For #1, when I say "layout managers" (a term from the Java GUI
    libraries), I mean that you can create GUI components that manage the
    geometry of their child components in high-level ways.  For example,
    HTML works like this -- you define a "table" or "div", and set styles
    like borders, but you don't worry about making a button wide enough
    to fit it's text, because that is handled automatically.  Code might
    look like:

        panel = new VerticalPanel();
        panel.borderWidth = 5;
        panel.add( new Button("OK") );
        panel.add( button2 );
        ...

    Other layouts might include a horizontal panel, and grid/table.

    For #2, I mean that you do not use "imperative" code to specify the
    exact order of building the GUI, like I did in the example above.
    Instead, the code looks more like HTML, where you simply declare the
    structure of the GUI.  You could use XML, but I prefer Lisp/Scheme,
    so it looks something like this:

        (vertical-panel
          (border 5)
          (button (text "OK") (on-click do-such-and-such))
          (button (image "/a/b/thing.png"))
          (drop-down-list
            (items "Apple" "Banana" "Orange")))

    Now, if I decide that I want a fatter border, I find it just as easy
    to change the "5" to an "8" as it is to open IB and drag something
    around.

    Going further, I can use variables in the definition of the GUI, and
    make things more abstract than is possible with IB.  For example, I
    could define a variable 'dialog-border-width' and use it in the
    definitions of all the dialogs.

    (define dialog1
        (vertical-panel
          (border dialog-border-width)
          ...

    Then I can change "dialog-border-width" in one place and change all
    the dialogs.

    Rob
  • On Nov 3, 2007, at 7:26 PM, Robert Nikander wrote:

    > On Nov 3, 2007, at 3:39 PM, Erik Buck wrote:
    >
    >> There is a current discussion "Re: Initializing the menubar
    >> without Interface Builder."  What I desperatly want to know is WHY ?
    >
    > Do you mean that I need to explain why I "think different"? :)
    >
    > Seriously, let me try to answer your question.  For me, I usually
    > find it easier and more powerful to work with code-defined GUIs,
    > but in order to do this I need two things that don't exist in all
    > GUI libraries, and don't seem to exist by default with Cocoa.  I'll
    > explain those two things below.  Let me just say, I do *not* want
    > to define a GUI like this:
    >
    > button = new Button();
    > button.X = 231;
    > button.Y = 54;
    > panel.add( button );
    > ...
    >
    > where I manually specify coordinates and dimensions.
    >
    > The two things I need are:
    >
    > 1. "Layout managers", or whatever you want to call them.
    > 2. A way to use declarative language.

    Are you aware of Renaissance?

    <http://www.gnustep.it/Renaissance/>

    sherm--

    Cocoa programming in Perl: http://camelbones.sourceforge.net
    WV Talk: http://www.wv-www.com
  • --- Robert Nikander <nikander...> wrote:

    [Deleted]
    > The two things I need are:
    >
    > 1. "Layout managers", or whatever you want to call
    > them.
    > 2. A way to use declarative language.
    >
    [Deleted]
    > For #2, I mean that you do not use "imperative" code
    > to specify the
    > exact order of building the GUI, like I did in the
    > example above.
    > Instead, the code looks more like HTML, where you
    > simply declare the
    > structure of the GUI.  You could use XML, but I
    > prefer Lisp/Scheme,
    > so it looks something like this:
    >
    > (vertical-panel
    > (border 5)
    > (button (text "OK") (on-click
    > do-such-and-such))
    > (button (image "/a/b/thing.png"))
    > (drop-down-list
    > (items "Apple" "Banana" "Orange")))
    >
    > Now, if I decide that I want a fatter border, I find
    > it just as easy
    > to change the "5" to an "8" as it is to open IB and
    > drag something
    > around.
    >
    > Going further, I can use variables in the definition
    > of the GUI, and
    > make things more abstract than is possible with IB.
    > For example, I
    > could define a variable 'dialog-border-width' and
    > use it in the
    > definitions of all the dialogs.
    >
    > (define dialog1
    > (vertical-panel
    > (border dialog-border-width)
    > ...
    >
    > Then I can change "dialog-border-width" in one place
    > and change all
    > the dialogs.

    I am sympathetic to what you want.  Your approach is
    sometimes used to create cross-platform GUIs.  I would
    say your argument is analogous to the argument between
    Tex users and WYSIWYG editor users.

    There are strengths to your approach: Comments can be
    included in the code.  Syntax and consistency checkers
    are possible.  Quick preview applications can provide
    rapid WYSIWYG feedback for the edit-test-edit cycle.
    Version control and merging are both possible and
    obvious.

    However, several shortcomings of your approach are
    common:  Magic numbers inevitably appear frequently.
    Incomprehensible spaghetti code is too easy to create:
    see HTML code sometime.  A great many lines of GUI
    code often have structure (nesting) that may not be
    obvious.  Constant text strings are difficult to
    localize.  Automatically growing and shrinking GUI
    components that resize to fit text create a new realm
    of unexpected behaviors (menus already do this).  Most
    layout manager schemes suck, and even when they work
    they take layout details out of your control.
    Programmers have to spend a lot of time analyzing and
    searching in the code to change anything.  It is easy
    to inappropriately couple GUI components to underlying
    application logic.  It is difficult to conform to user
    interface standards, and every application ends up
    looking different even when they are all produced by
    the same team.  Nobody likes a 10,000 line file...

    There isn't a right answer, and just like I respect
    (but don't understand) people who write documents with
    Tex, I respect your choice to of GUI technology.  In
    fact, I admire your willingness... To the extent that
    you are able to make good compliant Mac OS X
    applications, I applaud your effort.  Users don't
    really care HOW applications are developed.  They just
    want functioning applications that are a pleasure to
    use.  Tools like Interface Builder exist to make
    programmers more productive.  If they don't make you
    more productive, I guess I understand why you don't
    want to use them.  I just think you have to be a very
    special person if IB doesn't make you a more
    productive GUI developer.

    [Deleted rest]
  • --- Uli Kusterer <witness.of.teachtext...> wrote:
    [Deleted]
    > 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.
    >

    I agree.

    If you have more than three developers who need to
    edit a single nib file, you have a serious problem.
    Sometimes the problem can be mitigated by having lots
    of small nibs, but that isn't always possible or
    desirable.

    I admit, that most projects I have directly
    experienced have had ten or fewer software developers
    at any moment in time. There might have been fifty
    developers in the lifetime of an application, but not
    all at once.  Of the ten concurrent developers, the
    usual number of GUI developers is exactly one.
    Frequently, large/complex applications are designed
    and developed with back end frameworks split over
    multiple teams and thin GUIs (using MVC).

    In another post, Uli observed that locks don't help
    when you're working with branches, because then NIBs
    are impossible to merge back if someone changes
    something in the trunk.

    Uli makes a very valid point!  I think we need a human
    readable and computer merge-able way of viewing the
    target-action, bindings, and layout/nesting details of
    a nib.  This is essential even just to document the
    design of a nib.  It is too difficult to figure out
    how somebody else's nib is put together right now.

    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.
  • On Nov 3, 2007, at 2:06 PM, Uli Kusterer
    <witness.of.teachtext...> 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

    Sent from my iPhone -
    Jon Hess
  • On Nov 3, 2007, at 2:44 PM, Fritz Anderson wrote:

    > On 3 Nov 2007, at 4:06 PM, Uli Kusterer wrote:
    >
    >> 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.
    >
    > I'm sure you mean more than I intend to address, but isn't this
    > analogous to giving more than three developers simultaneous rights
    > to edit a JPEG? As in, isn't that a _very_ bad idea, and one of the
    > reasons SCM systems offer locks?

    No, it's more analogous to giving more than three developers
    simultaneous rights to edit a project file.

    The Xcode project file format is specifically designed for this.
    Since programmers typically write code in a line-oriented fashion,
    while programming languages may not be specifically designed for easy
    diff and merge via textual tools, it does work with them too.  And
    many modern languages (Python and Ruby) are in fact line-oriented...

    There's no technical reason whatsoever that resources like nib files
    and data models can't be designed to behave in exactly the same way,
    and be easily diff-able and merge-able using standard textual SCM
    tools.    (The technical proof is that you can do anything in source
    code that you can do in a nib or data model file, and the subsequent
    source code is as diff-able and merge-able as any other source code.
    QED.)

    In fact, this is exactly what Microsoft has done with XAML for their
    Windows Presentation Foundation framework:  A XAML file is just a
    representation of an object graph, but it's an XML representation
    written entirely in a line-oriented fashion so diff and merge tools
    Just Work with it.  (This is in contrast to a xib file, which has a
    bunch of binary data in it too, and doesn't necessarily guarantee
    stability across edits.  It's also not human-editable or human-
    authorable.)

    If this is a capability you would like to see in Cocoa and Interface
    Builder in the future, please file a bug at http://
    bugreport.apple.com/ and describe your use case.  Thanks!

      -- Chris
  • 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
  • On Nov 3, 2007, at 7:49 PM, Sherm Pendley wrote:
    > Are you aware of Renaissance?
    >
    > <http://www.gnustep.it/Renaissance/>

    No, but I'll check it out.  Thanks.

    Rob
  • --- Chris Hanson <cmh...> wrote:

    > 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.
    >

    I agree completely.

    [deleted]

    >> 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.

    Again. I agree completely.
  • On 04/11/2007, at 11:45 AM, Chris Hanson wrote:

    > 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.

    The new .xib files in IB3 seem to be a big step forward here in that
    they are both textual and diffable. Or am I missing the point?

    --
    Rob Keniger
  • Am 04.11.2007 um 02:18 schrieb Jon Hess:
    > 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.

      Well, I last tried this on Tiger, where nibtool is very selective as
    to what information it will display to you. There's a lot missing,
    like bindings. It did occasionally help to view NIBs, but it doesn't
    let you merge NIB files, because it's a lossy export.

      I've seen stuff in the Leopard release notes and docs that looks
    like this is about to improve, but just yesterday Xcode 3 did
    something with one of my NIBs that made one of my apps crash when
    launched on Tiger, and I had quite a time tracking down and restoring
    that. So, I'm reluctant to seriously go for Xcode 3 until I know stuff
    like that has been fixed.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Am 04.11.2007 um 02:10 schrieb Erik Buck:
    > I admit, that most projects I have directly
    > experienced have had ten or fewer software developers
    > at any moment in time. There might have been fifty
    > developers in the lifetime of an application, but not
    > all at once.  Of the ten concurrent developers, the
    > usual number of GUI developers is exactly one.

      Oh, wow. That must be tough. We have several people there. Of
    course, we have an interaction designer and a graphics designer that
    collaborate on the actual designs and make sure it's consistent, but
    we have several people who do GUI programmer work, and it's good like
    that. With the amount of GUI work involved in a Mac app, I'd go mad if
    I was the sole GUI developer on an app.

    > Uli makes a very valid point!  I think we need a human
    > readable and computer merge-able way of viewing the
    > target-action, bindings, and layout/nesting details of
    > a nib.  This is essential even just to document the
    > design of a nib.  It is too difficult to figure out
    > how somebody else's nib is put together right now.

      Yeah. XIB was kinda supposed to do that, but someone had the great
    idea of dumping a whole binary NIB in there as well...

    > 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 never said "all aspects", but some of the really neat features,
    like bindings, are just prohibitively opaque in a NIB. So you'd have
    to script those using bindTo:. Trouble is, then you're back to
    Carbon's HIViewFindByID()-technique. And I went to Cocoa exactly to
    avoid this...

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Hey Rob -

    On Nov 3, 2007, at 8:29 PM, Rob Keniger wrote:

    >
    > On 04/11/2007, at 11:45 AM, Chris Hanson wrote:
    >
    >> 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.
    >
    >
    > The new .xib files in IB3 seem to be a big step forward here in that
    > they are both textual and diffable. Or am I missing the point?

    They are human readable, and while diff support works, it could be
    much better. Merging is still not possible. XIB files are a step in
    the right direction, but they aren't a solution.

    Jon Hess
  • On Nov 5, 2007, at 10:55 AM, Jon Hess wrote:

    > They are human readable, and while diff support works, it could be
    > much better. Merging is still not possible. XIB files are a step in
    > the right direction, but they aren't a solution.

    My apologies for continuing this thread off into non-Cocoa-dev
    discussions, but I wanted to point out that most SCM systems do not
    *require* diffing & merging to be line-oriented.  That happens to be
    the default, as most data checked into those SCM systems are in a
    format that's amenable to line-oriented comparison.  But often the SCM
    system itself is ignorant to the format of the files, in terms of
    storage, access, and difference-detection.

    For example, Subversion's "diff" command supports the "--diff-cmd"
    argument, which specifies an alternate tool to use for diffs; and the
    "merge" command similarly supports the "--diff3-cmd" for merging.  At
    the lowest level, Subversion uses *binary* diffs.  Those binary diffs
    aren't mergeable directly, which is the reason for using external
    tools like traditional diff/diff3.

    There's no reason that someone couldn't create a super-diff/merge tool
    that handled not only line-oriented files, but XIB files, other XML
    files, and other diff-able data.  It would be really groovy to see a
    graphical nib-diff/merge tool!

    If you're curious how this works, see a couple of examples at:

    http://www.wsanchez.net/blog/2005/08/filemerge_and_subversion.html
    http://ssel.vub.ac.be/ssel/internal:fmdiff

    --John
  • Hey Uli -
    On Nov 4, 2007, at 3:33 AM, Uli Kusterer wrote:

    > Am 04.11.2007 um 02:18 schrieb Jon Hess:
    >> 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.
    >
    > Well, I last tried this on Tiger, where nibtool is very selective as
    > to what information it will display to you. There's a lot missing,
    > like bindings. It did occasionally help to view NIBs, but it doesn't
    > let you merge NIB files, because it's a lossy export.

    That's true, you can't use it for merging, only diffing. You can see
    basic bindings information by passing "--connections" to either ibtool
    on Leopard, or nibtool on Tiger. Filemerge does this for you.

    Jon Hess
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today