emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon port emacs-unicode-2 build problem under MacOSX


From: YAMAMOTO Mitsuharu
Subject: Re: Carbon port emacs-unicode-2 build problem under MacOSX
Date: Wed, 07 Nov 2007 14:52:23 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Tue, 06 Nov 2007 23:24:22 -0600, Ted Zlatanov <address@hidden> said:

YM> Could you precisely describe in what aspects you think it's "much
YM> better"?

> Well, the short answer is that it actually takes input from the
> keyboard.  I'd say that's a big improvement over today's Carbon port
> builds.

OK, I'm not interested in the comparison between a working one and a
not working one.

> That aside, it has better integration with the MacOS, a nice
> Preferences dialog, better font rendering, and other improvements
> listed in the ChangeLog.

What is "better integration with the MacOS", concretely?  In what
sense the font rendering in the Carbon port is worse?

And I don't think the Preference dialog that can't be controlled from
Emacs Lisp is suitable for Emacs.

YM> If it were really deprecated, Apple wouldn't have added any new
YM> frameworks to Carbon in Leopard.

> According to this article:

> http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6

> "Yep, it's (finally) the end of the line for Carbon GUI applications
> in Mac OS X. Oh, sure, they'll be around for years and years to
> come, but the lack of 64-bit support is a long-term death sentence.

> The last vestiges of the original Macintosh API are finally being
> put to rest. They've done their job and are being given a decent
> burial, I think. A slow, almost natural transition. Bugs will be
> fixed in the 32-bit Carbon APIs, of course, but no new features will
> be added. All new GUI APIs in Leopard and future Mac OS X releases
> will be added as Cocoa-only APIs."

> This is based on Apple's official announcements, not the author's
> opinion.

It says about the *GUI* APIs in Carbon, not the whole Carbon APIs.
That's why I'm making the Carbon+AppKit port (for Emacs 22) mentioned
elsewhere:

  http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg00395.html

YM> Did that cause any real problems?

YM> I'm asking because they are related not only to the effectively
YM> unmaintained Carbon port for Emacs 23 but also to the maintained
YM> one for Emacs 22.

> No, deprecation warnings are not a problem in themselves, they
> indicate the API will go away.  That's their purpose, generally.

> I assumed that the deprecation warnings I saw while compiling the
> Carbon port were Apple's way of telling developers the Carbon APIs
> are deprecated.  Am I wrong?

It wouldn't go away soon for the binary compatibility for existing
Carbon applications.  And the warnings are not about the whole Carbon,
again.  Actually, as for the Carbon+AppKit port in 64-bit environment,
it compiles without any `deprecated' warnings and runs, though there
still remain a few major problems such as suspected ATSUI bug, which
I've already reported to Apple, and some unexec problem.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]