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.

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

On Mar 26, 2008, at 8:03 PM, Matt Mower wrote:

On 3/27/08, Grayson Hansard <ghans...@dstvi.com> wrote:

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?

M.

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

* 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/

On Mar 26, 5:03 pm, "Matt Mower" <matt.mo...@gmail.com> wrote: