• 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: Bypassing Interface Builder
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bypassing Interface Builder


  • Subject: Re: Bypassing Interface Builder
  • From: Graham Cox <email@hidden>
  • Date: Thu, 15 May 2008 10:29:14 +1000

Do join the DK mailing list if you haven't already. (http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net ) I'm very willing to help people out with learning the framework, and I don't want to pollute cocoa-dev with DK related stuff.

A new beta and a start on the documentation is coming (maybe today if I can get moving).

I recognise the difficulty in figuring out how things work, especially with little or no docs, but I'm not sure that trying to hack it down to a smaller case is likely to be all that fruitful. For example, if you tried to strip out or bypass the controllers you'd find nothing would work, because the connection between the view and the data model would be gone, and the controller implements the tool(s) that are used to draw new objects. The pathways that a mouse event, for example, takes from a click or drag in the view to creating an object in the drawing is logical, but not absolutely direct - various objects get a pop at it and all with good reason. Unfortunately the price of flexibility is often added complexity. My suggestion would be to let DKDrawingView set everything up for you, then you could try exploring using gdb.

Anyway, this is off-topic. Feel free to take it up on the DK mailing list.



G.

On 15 May 2008, at 10:14 am, colo wrote:

On Wed, May 14, 2008 at 7:41 PM, Graham Cox <email@hidden> wrote:
One thing to point out here (as the author of DrawKit) is that DrawKit
doesn't use INTERFACE builder to any great extent because it is 95% data
model. In the model-view-controller architecture, Interface Builder is
useful mostly for V, and to some extent for C and very little for M. So
trying to use IB for something it isn't useful for is a sure route to
frustration and misunderstanding.



That's what I noticed mostly from reading your source example app. I started to try and hack "out" features so I could get it to the core of just drawing a box so I can see the root code of what calls it up and stuff. But thats where my lack of real cocoa comes into play atm. And it not compiling :P

But I did not want to bother you on it per request message on your
website, and the fact that I just need to learn more still.



You might want to look for a local CocoaHeads or NSCoderNight chapter for
where you live.


j o a r

Sadly joar there are zilch in Portland, ME, and I know of zilch cocoa programers besides Rails people.

_______________________________________________

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: 
 >Bypassing Interface Builder (From: colo <email@hidden>)
 >Re: Bypassing Interface Builder (From: Graham Cox <email@hidden>)
 >Re: Bypassing Interface Builder (From: colo <email@hidden>)

  • Prev by Date: Re: Conditionally modifying NIBs?
  • Next by Date: Re: Bypassing Interface Builder
  • Previous by thread: Re: Bypassing Interface Builder
  • Next by thread: Re: Bypassing Interface Builder
  • Index(es):
    • Date
    • Thread