Re: Mac OS-compatible ports

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 1 Jan 2012 10:47:38 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

YM> On 2011/12/31, at 22:22, Ted Zlatanov wrote:

>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
>> "in its defense" it is compatible with GNUstep by using the Cocoa API,
>> which your port isn't.  So, to make the current situation clear, the
>> Mac OS port choice is between:
>> 
>> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
>> with GNUstep and can work there (it needs lots of work though).  Apple
>> has repeatedly stated Cocoa is the preferred API for Mac OS X
>> developers, especially for new software.
>> 
>> 2) your Carbon-based port: works on Mac OS X well, can't be compatible
>> with GNUstep.  Apple has not been clear about Carbon's future, even
>> though Carbon seems to be well entrenched at this point.

YM> As I've been repeatedly saying, the Mac port uses Cocoa for its
YM> GUI implementation.  If you call the Mac port Carbon-based, lots
YM> of the applications including those bundled with Mac OS X such as
YM> Safari.app should also be called Carbon-based.

I'll avoid calling it "Carbon-based" in the future so there's no
misunderstanding.

YM> Also, I would like to note that some of recent improvements to
YM> Mac OS X and iOS are provided outside Cocoa, especially if they
YM> are not directly related to GUI.  They are not classified as
YM> Carbon, but they are also C APIs and not provided by GNUstep.
YM> For example, Grand Central Dispatch (GCD) I mentioned in the
YM> `select' emulation without periodic polling is a C API and
YM> provided by both Mac OS X and iOS, but not by GNUstep.

YM>   http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00694.html

I recall that API was brought into Mac OS X recently and is not
available in older versions of the same OS, at least for PowerPC
architecture.  I think it makes sense to use it opportunistically, but
if using it in the NS port makes the NS port incompatible with GNUstep,
then that's a harder decision.  I'm not qualified to make that decision,
in any case.

YM> The Core Text framework I'm using for the font backend driver in
YM> the Mac port is also a C API.  Interestingly, in iOS Apple
YM> provides an advanced low-level text layout API (Core Text) only
YM> at C level, rather than copying such API (NSLayoutManager etc.)
YM> from Mac OS X Cocoa AppKit to iOS UIKit.  I think this implies
YM> Apple's preference of C API to Cocoa for advanced low-level tasks
YM> that applications such as text editors want to use.

Interesting.  So Apple's direction seems to be towards plain C APIs now,
because of the emergence of iOS, and the profitability and popularity of
that platform makes a change in that direction unlikely.  That makes
compatibility with GNUstep much harder for the NS port.  It also means
that GNU Emacs has to keep up with Apple's business choices and custom
APIs to provide a great user experience on their proprietary platform.
That seems like a difficult choice for the GNU project, and I'm sure it
will come up again in other GNU software that aims to run on Mac OS X.

I think the NS port needs to make the decision whether it will keep
trying to be compatible with GNUstep, which will make the users'
experience worse on Mac OS X, or if it will use these C APIs and lose
the GNUstep advantage.

In the latter case it may be sensible and even advantageous to GNU Emacs
to merge the Mac port's improvements into the NS port, or vice versa,
and have just one Mac OS X compatible port.  That would leave GNUstep
without a viable GNU Emacs port, though, and it may not suit your plans
for the Mac port.

So this is up to the Emacs maintainers; the NS port maintainers (at
least Adrian Robert) and developers; and possibly you, if you want to
participate in such a discussion.  FWIW, as an Emacs user on Mac OS X, I
think such a merge would benefit the Emacs users, especially if there
was a way to provide some GNUstep compatibility.  I hope all of you find
a middle ground that satisfies everyone's goals and needs.

YM> Because the Mac port already uses Cocoa AppKit for GUI, the
YM> argument about Apple's preference of Cocoa to Carbon (with
YM> respect to GUI) you made above is rather pointless.  I even have
YM> an impression that the Mac port usually behaves more like other
YM> Cocoa applications than the NS port does.

OK, I'll keep that in mind, and thank you for explaining.

Ted