Cocoa mail archive
Re: Bypassing Interface Builder
FROM : Uli Kusterer
DATE : Thu May 15 07:50:22 2008
Am 14.05.2008 um 16:36 schrieb colo:
> My goal is to make a drawing app from the Drawkit framework but for
> the life of me I just can't get past the use IB but Drawkit does not
> use IB but the books do and swear that I should fiasco! Ah ha ha ha ha
> h haha h hah aa haa
I think you're going down the wrong road if you try to avoid using
IB with Cocoa for now reason beyond: 'IB seems unreasonably complex to
me'.
That said, it is very easy to create your own windows and views.
They're just objects. You can alloc/initXXX any view and window
object, and then put them together using -addSubview: (Every window
has a content view to which you add its views). You just need to
create a controller that takes care of this and takes ownership of the
objects once they are created (by stashing them away in its instance
variables), and releases them when they're done.
If you actually have a NIB-like format and just want to create Mac
controls that match this, you can even do the hookup like IB does it:
Use NSSelectorFromString() to turn a string representation of a method
name into a SEL you can pass to -setAction:, and use an NSDictionary
to match up objects with the IDs/names you've assigned them in your
file format (e.g. so you can look up the object to pass to another
object's setTarget: method). To set IBOutlets, you'd use -
setValue:forKey: (and other Key-Value-Coding methods of NSObject's),
and there are also methods for hooking up bindings manually.
I haven't exhaustively looked at all the nooks and crannies, so
there may be some magic that IB does that's not quite as easy, but
most of it is covered by the above list. Of course, you need to be
familiar with how to serialize/unserialize an object graph (in general
programming terms, not Cocoa-specific) to implement this.
As to apps like Sketch: NSViews do not support overlapping views
(well, you can use layer-backed views, sort-of, but IMHO you don't
want to do that for a drawing app with lots of objcts, you'd prolly
immediately hit the software fallback of your Graphics Card), so an
app like Sketch would generally use IB for its UI and one 'canvas'
view to draw all the shapes themselves, functioning as a sort of
parallel view hierarchy. Graham's GCDrawKit does it that way already.
So, you see, they're not mutually exclusive. You can even load several
NIBs and assemble them at runtime (that's what System Preferences
does, for example).
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
DATE : Thu May 15 07:50:22 2008
Am 14.05.2008 um 16:36 schrieb colo:
> My goal is to make a drawing app from the Drawkit framework but for
> the life of me I just can't get past the use IB but Drawkit does not
> use IB but the books do and swear that I should fiasco! Ah ha ha ha ha
> h haha h hah aa haa
I think you're going down the wrong road if you try to avoid using
IB with Cocoa for now reason beyond: 'IB seems unreasonably complex to
me'.
That said, it is very easy to create your own windows and views.
They're just objects. You can alloc/initXXX any view and window
object, and then put them together using -addSubview: (Every window
has a content view to which you add its views). You just need to
create a controller that takes care of this and takes ownership of the
objects once they are created (by stashing them away in its instance
variables), and releases them when they're done.
If you actually have a NIB-like format and just want to create Mac
controls that match this, you can even do the hookup like IB does it:
Use NSSelectorFromString() to turn a string representation of a method
name into a SEL you can pass to -setAction:, and use an NSDictionary
to match up objects with the IDs/names you've assigned them in your
file format (e.g. so you can look up the object to pass to another
object's setTarget: method). To set IBOutlets, you'd use -
setValue:forKey: (and other Key-Value-Coding methods of NSObject's),
and there are also methods for hooking up bindings manually.
I haven't exhaustively looked at all the nooks and crannies, so
there may be some magic that IB does that's not quite as easy, but
most of it is covered by the above list. Of course, you need to be
familiar with how to serialize/unserialize an object graph (in general
programming terms, not Cocoa-specific) to implement this.
As to apps like Sketch: NSViews do not support overlapping views
(well, you can use layer-backed views, sort-of, but IMHO you don't
want to do that for a drawing app with lots of objcts, you'd prolly
immediately hit the software fallback of your Graphics Card), so an
app like Sketch would generally use IB for its UI and one 'canvas'
view to draw all the shapes themselves, functioning as a sort of
parallel view hierarchy. Graham's GCDrawKit does it that way already.
So, you see, they're not mutually exclusive. You can even load several
NIBs and assemble them at runtime (that's what System Preferences
does, for example).
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
