Building apps with Nu and Objective-C

[Matt Mower]

Hi gang.

I am pondering whether I have the time & energy to get back to writing
Mac apps. I have my next app in mind and am trying to think of the
best way to approach it.

All of the example apps I have seen (even the Nib example) are pure-Nu
not using XCode or any of the XCode generated stub of an application.

I am reticent about taking this approach but not clear about how to
pursue the alternative route. I created a new app and embedded the
NuConsole (neat trick Jeff) but didn't immediately see how I would go
about mixing & match Obj-C and Nu elements.

I'm interested in how people are approaching building applications
using Nu. Are you going NuEverywhere? Is anyone using XCode? Interface
Builder?

All input welcome.

M.

--
Matt Mower :: http://matt.blogs.it/

[Grayson Hansard]

I have a decent amount of experience with this as one of my
applications, Paperclip (<http://www.fromconcentratesoftware.com/Paperclip/
>), uses Nu for some core functionality. I also like to hack small
apps just for me using the following techniques.

I like Xcode and I like to mix ObjC and Nu. I copy the Nu framework
into my app's Frameworks folder and I have a small shell script that
makes it distributable (as built, the Nu framework can't accessed
within an app bundle). After those hurdles are out of the way,
everything is rather easy.

I'm not proposing this as a "best practice," but it's easy and works.
In an +initialize message, load a Nu file in your bundle:

#import <Nu/Nu.h>
+(void)initialize {
id nu = [Nu parser];
[nu eval:[nu parse:[NSString stringWithContentsOfFile:[[NSBundle
mainBundle] pathForResource:"nuinit" ofType:@"nu"]]]];
}

Note that the above isn't shipping or even tested code, just an
example from the top of my head. You can do this in an `awakeFromNib`
or delay it even later. I go early in case I create a category for a
standard class and use Interface Builder to call custom IBActions (see
<http://github.com/Grayson/nudatadetector/tree>; your app will bitch
if it loads a nib/xib and it can't connect an action). Add whatever
nu files you want included to your app's Resources folder. Then, in
nuinit.nu simply load them:

; nuinit.nu
(load "markdown") ; Note that Nu is able to look into your Resources
folder for Nu files to load
(load "somethingelse") ; Alternatively, you could load all of the nu
files in a folder. `filelist`!

All of the classes and whatnot that you define in Nu files are then
inserted into the runtime and will then be available. You can then
mix and match ObjC and Nu to your heart's content.

There are two minor problems with this approach. The compiler likes
to complain if you try to use a method in ObjC that's defined in a Nu
file. You can use `performSelector:` or define the header part of a
category to remove these warnings. The other thing is that the
compile doesn't know about the classes that you've defined in Nu. You
can use `@class` to indicate to an ObjC file that it should be aware
of it but the compiler will ask you where the class is defined. You
can use some linker flags (<http://www.culater.net/wiki/moin.cgi/LinkerSettings
>) to get around that, though.

That's my basic approach to hybrid Nu/ObjC apps. It works fairly well
so far with a minimum of headaches.

Sincerely,
Grayson

[Matt Mower]

Hi Grayson.

On 3/27/08, Grayson Hansard <ghan...@dstvi.com> wrote:
> I have a decent amount of experience with this as one of my
> applications, Paperclip (<http://www.fromconcentratesoftware.com/Paperclip/
> >), uses Nu for some core functionality. I also like to hack small
> apps just for me using the following techniques.
>

Thanks for that write-up, that was exactly the kind of information I
was looking for.

> I like Xcode and I like to mix ObjC and Nu. I copy the Nu framework
> into my app's Frameworks folder and I have a small shell script that
> makes it distributable (as built, the Nu framework can't accessed
> within an app bundle). After those hurdles are out of the way,
> everything is rather easy.
>

Okay this is a new one on me... "as built, the Nu framework can't
accessed within an app bundle". I'm not quite sure what you mean by
that.

I embedded the Nu framework into my testbed app last night and was
able to access it to setup the Nu console which required creating a
parser and evaluating some code.

Are you referring to something else?

> or delay it even later. I go early in case I create a category for a
> standard class and use Interface Builder to call custom IBActions (see
> <http://github.com/Grayson/nudatadetector/tree>; your app will bitch
> if it loads a nib/xib and it can't connect an action). Add whatever
> nu files you want included to your app's Resources folder. Then, in
> nuinit.nu simply load them:
>

Thank you, this was again exactly the sort of tip I was looking for.

> There are two minor problems with this approach. The compiler likes
> to complain if you try to use a method in ObjC that's defined in a Nu
> file. You can use `performSelector:` or define the header part of a
> category to remove these warnings.

Using performSelector: sounds like drudgery. It occurs to me that it
ought to be possible to automatically generate of category style
headers from Nu code to satisfy XCode. Does that sounds plausible?

> The other thing is that the
> compile doesn't know about the classes that you've defined in Nu. You
> can use `@class` to indicate to an ObjC file that it should be aware
> of it but the compiler will ask you where the class is defined. You
> can use some linker flags (<http://www.culater.net/wiki/moin.cgi/LinkerSettings
> >) to get around that, though.
>

Ok, I will look at that.

> That's my basic approach to hybrid Nu/ObjC apps. It works fairly well
> so far with a minimum of headaches.
>

Your message contained a lot of really useful info Grayson, thanks again.

[Grayson Hansard]

> Okay this is a new one on me... "as built, the Nu framework can't
> accessed within an app bundle". I'm not quite sure what you mean by
> that.

I should have been clearer. If you distribute an application, the
user *must* have the Nu framework installed. If you'd like to remove
that dependency and distribute the framework inside the application,
you have to reset some linker information in the framework. As built,
Nu.framework wants to living in /Library/Frameworks/ and won't be
loaded properly if it's referenced in the app's Frameworks folder
without some nudging.

> Using performSelector: sounds like drudgery. It occurs to me that it
> ought to be possible to automatically generate of category style
> headers from Nu code to satisfy XCode. Does that sounds plausible?

It occurred to me as I was writing it that it ought to be possible to
automatically generate header files from Nu code. If I have some time
today, I might hack around on it.

Sincerely,
Grayson

[Grayson Hansard]

> It occurs to me that it
> ought to be possible to automatically generate of category style
> headers from Nu code to satisfy XCode. Does that sounds plausible?

I took some time today to toss something together. It's mostly
cobbled from what I learned from reading nudoc and it isn't
extensively tested but it worked in my (very simple) tests. It should
iterate through the nu files in a nu folder and create basic header
files for classes and categories.

http://github.com/Grayson/nug/tree/master

Sincerely,
Grayson Hansard
in...@fromconcentratesoftware.com

[Brian Chapados]

I've been working with a 3rd party framework (DataGraph[1]), as well
as the OmniInspector[2] framework, using Nu to control the interface
and interactions between Objective-C classes. My approach is similar
to the one that Tim used for NuPagePacker:

* I don't use Xcode as my main development environment. I write Nu
code in TextMate and use the Nu-style layout for the project code and
resources.

* I use Interface Builder to build all of the interface nibs as
follows:
- In the nib files, I just manually set the class of File's Owner to
the appropriate class defined in Nu, and then define any actions and
outlets to match the ivars/methods defined in Nu. In general, I've
found that I don't really miss automatic import from .h files.
However, if someone wrote a routine to pull this info out of Nu source
files, I'd use it.
- I currently define the menu in Nu, but I've also used a nib for
the menu.
- I prefer to define bindings manually in Nu. To me it is also
easier to understand and debug. However, I've also done this in IB and
it works just fine.

* There are portions of the code that need to be written in Objective-
C in order to do some pointer manipulations and integrate with some C+
+ classes. To handle this, I just created a Framework project in
Xcode and build this code as a framework. I keep the Xcode project
under my nu project directory and have a nuke task that copies the
compiled framework into the application bundle. Loading frameworks in
Nu is as simple as (load "<Framework>"). This also makes it really
easy to test the framework with Nu.

* There are a few cases where a class that is mostly written in Nu
needs C/Objective-C methods. In this case I just create the .h/.m
file(s) (there are so few that I just have one .m file) under the
'objc' directory. These get compiled into the app during the standard
nuke build process.

Personally, I prefer to use Nu over Obj-C, hence the mostly pure-Nu
approach. It is easy to integrate Obj-C code in places where you need
it.

[1]: http://www.visualdatatools.com/DataGraph/index.html
[2]: http://www.omnigroup.com/developer/