• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why initialize the menubar without Interface Builder
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why initialize the menubar without Interface Builder


  • Subject: Re: Why initialize the menubar without Interface Builder
  • From: Chris Hanson <email@hidden>
  • Date: Sat, 3 Nov 2007 18:38:56 -0700

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

_______________________________________________

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


References: 
 >Why initialize the menubar without Interface Builder (From: Erik Buck <email@hidden>)
 >Re: Why initialize the menubar without Interface Builder (From: Uli Kusterer <email@hidden>)
 >Re: Why initialize the menubar without Interface Builder (From: Fritz Anderson <email@hidden>)

  • Prev by Date: Re: NSMailDelivery now in deprecation w/Leopard
  • Next by Date: Re: [Leopard] Interface Builder - Subclassing
  • Previous by thread: Re: Why initialize the menubar without Interface Builder
  • Next by thread: Re: Why initialize the menubar without Interface Builder
  • Index(es):
    • Date
    • Thread