Mac OS Build (was Re: Abiword gets "recognition" at MacHack)


Subject: Mac OS Build (was Re: Abiword gets "recognition" at MacHack)
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Mon Jun 25 2001 - 08:31:58 CDT


At 9:41 AM +0200 6/25/01, Hubert Figuiere wrote:
>Here are my thought of the MacOS X port of AbiWord.
>I think there are several path to go with this port.
>
>1/ continue like I begun: target Carbon. This provide a code base that will
>be usable for a MacOS 8.5 port. But this is probably not the best, but far
>from being the worst.

        At this point, I wouldn't spend time worrying about anything
less than OS X, since those users already have a choice of word
processors. I believe we should focus on the future and potential
"customers".

>2/ go like you suggested: compile AbiWord as a UNIX/GTK build and use it
>with XFree. While this would be quick to do, this would not be the best.

        Agreed, it is NOT the best though it would be the quickest!

>Currently XFree is not installed by default. It is still experimental. On
>also the integration with the existing environment won't be optimum. If
>someone wants to try it, he is welcome.

        When running in "rootless" mode, X applications integrate
just like every other application - BUT they have their own "look and
feel", which isn't all that great unless you're running at least a
Platinum or Aqua theme. See
<http://www.macgimp.org/X/rootlessXgimp.gif> for an example of GIMP
running this way.

>3/ use the MacOS 9 port of GTK a go as above. No need for XFree, less
>optimum, more work as MacGTK is not really usable.

        Yeah, MacGTK is definitely WAY behind...

>4/ Port GTK to MacOS X using CoreGraphics and go as in 2.

        Darin Adler and I were talking about this at MacHack as a way
to bring GNOME apps (like say Nautilus) to Mac OS X in a "more
compatible" fashion than relying on XFree. We believe that it could
probably be done in less than a week with someone(s) working on it
full time.

        However...

>Solution 2, 3 and 4 would lead to a program that does not meet MacOS X GUI
>standards like menu bar, etc.

        EXACTLY! That's one definite problem with the GTK model is
that it doesn't use platform-native UI elements (menus, controls,
etc.) and although that's probably OK for many Windows folks, Mac
users would SCREAM!!

>5/ This is a variant of 1: use Cocoa instead of Carbon. That would speed up
>the development time of AbiWord for MacOS X, but the code base would not be
>compatible with MacOS 9.

        As noted above, I don't have a problem dropping OS 9 support
- but I think there are other issues with using Cocoa...

        The main problem, in my mind, with going to Cocoa is the same
one that has been discussed over time with using PowerPlant, MFC,
etc. is that it means breaking away from common code for the
framework and only using common code for the editing "core".

> The biggest problem with this solution, that makes
>me not choosing it is the fact that AbiWord is C++ and Cocoa requires
>Objective-C or Java that are really hard to mix. I'm still hesitating to
>make the move and port to Cocoa....

        Actually, there is now Objective-C++ (they announced this at
WWDC) and allows you to easily integrate ObjC, Java and C++ in the
same application.

>Keep in mind that Mac users have strong requirements against GUI and that
>doing a quick and dirty port with a clumsy (ie not mac-like) GUI will only
>leads to a failure.

        No argument from me!!

        I only suggested the X/GTK option as perhaps a "stop gap"
until we could get a "native" OS X build available....

LDR

-- 
----------------------------------------------------------------------------
                   You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol     			Internet:       leonardr@lazerware.com
Web Site: <http://www.lazerware.com/>
Coola Signature: <http://signature.coola.com/?leonardr@lazerware.com>
PGP Fingerprint: C76E 0497 C459 182D 0C6B  AB6B CA10 B4DF 8067 5E65



This archive was generated by hypermail 2b25 : Mon Jun 25 2001 - 08:32:54 CDT