[sword-devel] Future MacSword

Manfred Bergmann bergmannmd at yahoo.de
Wed Mar 12 01:28:51 MST 2008 

Hi Greg.


Am 11.03.2008 um 21:42 schrieb Greg Hellings:

> Manfred,
>
> Thanks, that clears up quite a bit of how it works.  More below...
>
> On Tue, Mar 11, 2008 at 3:19 PM, Manfred Bergmann  
> <bergmannmd at yahoo.de> wrote:
>> Hi Greg.
>>
>>
>> Am 11.03.2008 um 20:52 schrieb Greg Hellings:
>>
>>
>>> I've been starting to tackle the iPhone/iPod Touch question this  
>>> past
>>> week, and it doesn't look like it would be terribly difficult.  The
>>> most complicated and tedious portion of the project is getting Sword
>>> to compile in XCode in a manner which would allow it to build for an
>>> iPhone app.
>>
>> It must not necessarily be build in Xcode. And to be honest I  
>> wouldn't
>> do it.
>> C/C++ libraries will continue to be C/C++ libraries. What you do on
>> Mac is to put a C/C++ library into the Application-Bundle if it is  
>> not
>> available on the system by default.
>> MacSword of course has automatic build scripts which create universal
>> binaries of the Sword library for the current versions of Mac OSX.  
>> For
>> iPhone / iPod touch the only thing that needs to be changed is the
>> architecture parameter to gcc to build a version for iPhone/iPod  
>> touch
>> for ARM CPU.
>> A ARM only build of Sword library with stripping as much as possible
>> would not be bigger than 800kByte I guess.
>
> The only supported way to build apps for the iPhone/iPod Touch and to
> test them in the emulator and on the device is to build them with
> XCode.  Thus, the iPhone app will need to be built with the XCode
> application.

Well, there is always a manual way of building Application Bundles and  
I'm pretty sure there is a manual way for the iPhone platform too.
But why do that, Xcode is great and much more convenient.

Btw: Xcode is spelled "Xcode", not "XCode". ;)

> Building the library on the command line shouldn't be
> much of an issue, and including it with the App bundle will also not
> be a problem.  I trust that just passing in the target architecture to
> the configure/build tools for Sword should do the trick?

I think so, yes.

> It still
> would be easier to build it in XCode, so I'll see about both options.

Actually I would say it is not easier. A lot of configuration is  
needed in the target settings in Xcode to make it compile or even  
cross-compile which might be much easier from command line.

>>> , in the same way that BibleCS is.  Minimally, it would
>>> be nice if there was an XCode project included with the Sword API  
>>> for
>>> just such reasons.
>>
>> As said above a Mac like Framework can be created using the backend
>> portion of the MacSword application.
>> But Mac OSX is still Unix and can easily use dylibs which Sword C++
>> library is after building on Mac. I wouldn't change that.
>
> It's probably easiest, for the purpose of the mobile app, to link the
> C/C++ library directly to the application, rather than try to link the
> Sword library into an Objective-C 2.0 wrapper and then wrap that into
> the application.  I only say that because my background is in C/C++
> and I can easier manipulate the code if I use as many of those
> features as possible and as little of the Objective-C as necessary
> (i.e. for only GUI portions).  It also, on the mobile platform, would
> mean fewer layers of abstraction and probably better runtimes.  If I'm
> thinking in the wrong direction, please let me know.

Hmm. Well, in order to create an application which uses Cocoa you  
would need to do some conversation anyway because Cocoa can't deal  
with C++ classes right away. And it uses NSArray, NSDictionary  
collections rather than any C++ templates.
This is what the Objectice-C wrapper does, make it work in Cocoa.
And it is so much more convenient in a Cocoa environment that you  
actually can use the Cocoa/Objective-C classes instead of C++ classes.

>>> If MacSword was designed to be checked out into a
>>> subdirectory of the Sword project the way that BibleCS is, then
>>> perhaps there could be an XCode Project at the head of the sword
>>> folder which builds the library,
>>> and a checkout for the MacSword UI
>>> that built against that library back in the sword folder. (Am I  
>>> being
>>> clear here?)
>>
>> Not sure if I understood you correctly.
>> MacSword is designed to use a compiled Sword dynamic library dylib
>> whereever this library comes from doesn't matter.
>> I think it can't be more flexible.
>
> True, I was just thinking from the build point, because I thought you
> had been using an XCode project to build the Sword library.  Since
> you're not, that is no longer an issue.  Although, if there was an
> XCode project, it would make building for both iPhone and for MacSword
> equally easy, as the compiler would only be required to select the
> SDK/Framework in the build menu of XCode at compile time.

I understand your point-
But it is as easy using command line. We use a makefile with different  
targets for ppc only, intel only, fat with debug or without. It would  
be easy to add a new target for ARM platform.

>>> Leveraging your work on MacSword would be a wonderful springboard  
>>> for
>>> iSwordTouch (or whatever other whimsical name comes up for the
>>> project) which would cut out most of my guesswork thus far as to
>>> necessary and superfluous files for a front-end to utilize.
>>
>> My guess is (I don't have an iPhone), like I said before, that the
>> MacSword UI is not really usable on iPhone because of the multi- 
>> window
>> design. Having one main window would be much better.
>> I don't have much information about the runtime system on Mac OSX.  
>> But
>> a strong guess is that it is minimal and could use the Objective-C  
>> 2.0
>> runtime only using Garbage Collector. Beside that I don't think it is
>> a big problem to have something on an iPhone/iPod touch very quickly
>> if there are answres to a couple of questions.
>
> No, the MacSword UI probably isn't usable on the iPhone, but then
> again, it would be foolish to think that any desktop app should work
> well on a mobile device.  I really love your multi-window approach on
> MacSword, and that was one of my thoughts in making the switch from PC
> to Mac... I would finally have a Sword front-end that allowed multiple
> arbitrary windows.  I have long thought that the inability to do that
> in BibleCS and GnomeSword was my personal preference against those UI
> designs and Mac Sword was the inspiration for my own wxSword project
> which I've tinkered with over the past 2 years.

Hmm. alright. The new trend goes more to something like workspace  
environments which just have a floating window for information and  
settings like it is in Numbers, Pages and many more Cocoa applications.
The multi-window thing is actually not done any longer by most of the  
application developers.

>>> I also
>>> have access to both Tiger and Leopard simultaneously, so I can biuld
>>> the system and test on Tiger if you would like to continue  
>>> supporting
>>> that at least for the time being.
>>
>> I would go to a version 1.5 of MacSword which would support Leopard
>> and above because a good part of the backend work is done in  
>> Objective-
>> C 2.0 which is not compatible with Objective-C.
>> But there still is the current version 1.3.x which is still  
>> compatible
>> to Panther (Mac OSX 10.3).
>
> Ah, that makes more sense.  I wasn't sure if it was an incompatibility
> or simply a build-system problem.  Is it possible to build against the
> Tiger SDK from a Leopard machine, even if the program is written in
> Objective-C 2.0 and still run the program on Tiger, or do the
> libraries and executables come out incompatible?

No, that is not possible. If you use Objective-C 2.0 which comes with  
some new language structures then you can't use it on Tiger.
You can of course build against the Tiger SDK in Leopard which makes  
the application run in both Tiger and Leopard. But then you can't use  
any Objective-C 2.0 things and also not the garbage collector.


Manfred


>>
>>
>>
>>
>>
>>> On Tue, Mar 11, 2008 at 2:39 PM, Jon Brisbin <jon at jbrisbin.com>  
>>> wrote:
>>>> I for one am STOKED about an iPhone/iPod Touch Sword app! :)
>>>>
>>>> I'm okay with Leopard-only for the time being, particularly as some
>>>> of
>>>> the main apps I'm using these days are Leopard-only...
>>>>
>>>> Thanks!
>>>>
>>>> Jon Brisbin
>>>> http://jbrisbin.com
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 11, 2008, at 12:37 PM, Manfred Bergmann wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> Although MacSword is quite old and it would be more than time for
>>>>> something new I found that it will still take a good amount of  
>>>>> time
>>>>> until something usable is there that can replace MacSword.
>>>>> I'm the only one developing in this area ATM and was quite busy  
>>>>> with
>>>>> my daily work the last months/weeks, so it hasn't gotten as far  
>>>>> as I
>>>>> would have liked it.
>>>>>
>>>>> I have put many hours of work into refactoring the Sword  
>>>>> Objective-C
>>>>> Backend (coming from MacSword) and in a module installer that is  
>>>>> now
>>>>> in Eloquent (btw: a new version has been released with some
>>>>> enhancements).
>>>>> My thinking was that until something new is there I would branch
>>>>> MacSword and backport the backend and the module installer into
>>>>> MacSword. The UI would stay the same and it would be a Leopard  
>>>>> only
>>>>> application.
>>>>> IIRC the majority of users that had questions about MacSword
>>>>> actually
>>>>> were using Leopard.
>>>>>
>>>>> Altough the UI of MacSword is hardly usable in iPhone, having
>>>>> something Leopard compatible or Leopard only would ease the port  
>>>>> to
>>>>> iPhone tremendously.
>>>>>
>>>>> What are your thoughts about this?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Manfred
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>>>
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

More information about the sword-devel mailing list