Cocoa mail archive
Re: Bypassing Interface Builder
FROM : Graham Cox
DATE : Thu May 15 02:29:14 2008
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 <graham.<email_removed>>
> 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.
DATE : Thu May 15 02:29:14 2008
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 <graham.<email_removed>>
> 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.
