[sword-devel] Future MacSword
greg.hellings at gmail.com
Tue Mar 11 13:42:37 MST 2008
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. 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? It still
would be easier to build it in XCode, so I'll see about both options.
> MacSword/Eloquent has a Objective-C++ wrapper to the library which
> altogether could be exported to a Mac like Framework. Currently this
> is not the case but UI si still seperated from Sword backend.
> > It seems easiest, to me, if the MacSword UI, etc, were just portions
> > of the SVN tree
> Backend is, all other stuff is UI basically.
> > , 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.
> > 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.
> > Having such would greatly enhance my ability to build for
> > Aspen/iPhone/iPod Touch. I have the plan for the basic UI on iPhone
> > worked out, but I don't yet know how and if apps will have access to
> > the file system, etc. My guess is that modules will have to be
> > installed to the root of the App bundle, which also makes sense for
> > the behavior of the App in OS X.
> I have no idea how the Filesystem on iPhone/iPoid touch looks like.
Nor I, but I think that's in one of the upcoming documents I haven't
yet finished reading in the iPhone Dev Center.
> > 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.
An app for the iPhone would probably function similar to the e-Sword
reader for Windows Mobile (which probably functions similar to our own
Sword for mobile platforms, though I haven't installed that yet, being
that I'm very very rarely in Windows. Obviously, some of the sizes
and layouts would be slightly modified to work with the Cocoa widgets
and iPhone's touch-sized interfaces rather than Windows Mobile's
> > 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? At least maintaining
support for Tiger in the go-forward for a while would be nice, rather
than stranding Tiger users with a version compatible only with Sword
1.5.8 (which seems, according to Sourceforge to be the latest version
against which 1.3 is built at current).
> > 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
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel