[sword-devel] iPhone NDA dropped

[Manfred Bergmann]

Hi Greg.

Am 02.10.2008 um 10:06 schrieb Greg Hellings:

> > I already have the SWORD library building against the iPhone SDK in
> > XCode (the command-line building process simply doesn't work).  I
> > can't get Eloquent to build for iPhone because of a few missing
> > Cocoa-based headers which the iPhone system doesn't have.  I suppose
> > the next step is to go back to the drawing board and learn  
> Objective-
> > C and the iPhone SDK's basic classes.
>
> Yes, that may be.
> Which sources of Eloquent have you tried compiling? This project is
> rather old and you might want to use other backend sources.
>
> I'm trying to build the version out of SVN on googlecode.  Is this  
> the "latest" repo of it?  As for other back end sources, I know of  
> no other Obj-C back end sources for SWORD.  If there are others,  
> which are more up-to-date, I'll happily use them.

The 'original' sources of MacSword are more up-to-date.
Eloquent project is more or less dead. The sources have been merged  
into MacSword 1.4 branch and trunk partly.

> So far my errors are as follows:
> SwordDictionary.mm can't find Cocoa/Cocoa.h or CocoLogger/ 
> CocoLogger.h.
> SwordSearching.mm: missing headers - AppKit/NSApplication.h, Cocoa/ 
> Cocoa.h, Coco/CocoLogger.h, MBLOG/MBLOG_DEBUG/MBLOG_ERR macros  
> missing, and class sword::VerseKey has no member named NewIndex on  
> line 215
> SwordManager.mm - Cocoa/Cocoa.h and CocoLogger/CocoLogger.h and the  
> MBLOG macros
> SwordInstallSource.mm - same
> SwordBook.mm - same
> SwordCommentary.m - same
> SwordInstallSourceController.mm - ditto
> SwordModule.mm - ditto, plus "warning: 'SwordModule' may not respond  
> to '-textForRef:'
> SwordBible.mm - same
>
> So, it looks like, taking out CocoLogger/CocoLogger.h and finding  
> what are the necessary includes for Cocoa/Cocoa.h instead, would  
> alleviate almost all of the problems.  The sample applications tend  
> to include UIKit/UIKit.h in all of their files, and also in a .pch  
> they include Foundation/Foundation.h.  Just testing out a  
> hypothesis... I merely commented out all of the includes that were  
> raising errors (every inclusion of Cocoa/Cocoa.h, CocoLogger/ 
> CocoLogger.h, AppKit/NSApplication.h and all of the calls to MBLOG*  
> macros), except for the errors about sword::VerseKey's member  
> NewIndex, and the system builds fine, but for that one error.   
> Perhaps it's not completely feature rich with all of the new Sword  
> options, so that would be cause for future addressing, but I'm not  
> close to ready to push those limits yet. ;)

CocoLogger is a project of mine. It is a logging framework.
Although you could have the sources you should replace all 'MBLOG' or  
'MBLOGV' macros completely and replace by what you can use in iPhone  
for logging.
Probably NSLog() also is available.

I use preprocessor things like this sometimes, Xcode lets you define  
different constants for the targets:
#ifdef DEBUG
#define CLOG1(X)	NSLog(X)
#define CLOG2(X,Y)	NSLog(X,Y)
#else
#define CLOG1(X)	;
#define CLOG2(X,Y)	;
#endif

> > I have a general GUI layout in mind, so hopefully things will go
> > quickly once I get the hang of the RAD tools that XCode uses, etc.
> > They look like they should be rather simple, I just have never used
> > any type of RAD/GUI designing tools other than manual placement and
> > coding of interfaces.
>
> Interface Builder is a really nice tool. Cocoa has the best
> implementation of MVC I have seen so far. Interface Builder really
> only creates the GUI and then you switch over to Xcode and do the
> Controller part.
> It is different compared to other language platforms but I like it.
>
> I detest all RAD GUI tools which I've tried so far.  I can never  
> find where to hook in my actual code to provide content, and Apple's  
> attempt to simplify everything to the point of annoyance certainly  
> does not help in that.  I'm still just grasping at straws when it  
> comes to the whole GUI/Controller dichotomy.  I'd strongly prefer to  
> do all the GUI creation directly in my own hand-writing, even if it  
> means that I'll take twice as long as someone with RAD.  In the end,  
> I have code that I can work with and which I can complete long  
> before I learn how to use a RAD tool.  But, from the looks of  
> things, Apple won't let you create interfaces without Interface  
> Builder, so I suppose I'll have to buckle up and learn it.  I just  
> wish their developer documentation was more accessible to a non-OS X  
> developer.

Of course you can create Interfaces by hand. Interface Builder does  
not do any magic. It simply creates the code for you although you  
normally can't see it.
I also like it better to create GUIs myself in code for almost all  
languages and frameworks but not for Cocoa.
Once you have gotten used to the tools and have seen the benefits you  
won't like to have anything else. At least that's how it was for me.
Connecting the GUI to your Controller is really easy and I think I can  
say that you won't build interfaces by hand anylonger once you have  
learned how all this works.

> All-in-all, it looks like building on the iPhone shouldn't be a  
> problem, as long as we can clean up and keep up with the SWORD  
> engine.  The only real hurdle now is whether or not yours truly can  
> figure out how Cocoa GUI programming is supposed to work.

There are a couple of good resources out there for this.
Also some good books like "Cocoa Programming for Mac OSX" by Aaron  
Hillegass.
It mostly deals with Mac OSX but the principles are the same in Mac  
OSX and iPhone platform.

Do you have any concrete question?


Regards,
Manfred