Re: copy & paste between Carbon and Cocoa
Re: copy & paste between Carbon and Cocoa
- Subject: Re: copy & paste between Carbon and Cocoa
- From: "David W. Halliday" <email@hidden>
- Date: Mon, 21 Jan 2002 10:47:54 -0600
- Organization: Latin AmeriCom, formerly Latino Online
"Simson L.Garfinkel" wrote:
>
I've noticed that copy & paste between Carbon and Cocoa, while it sort
>
of works, is generally broken.
>
>
* Create a document with the Simple Text Carbon demonstration
>
application in /Developer.
>
* Put some bold, itallics, etc.
>
* copy
>
* start up TextEdit.
>
* paste. You get it without font attributes (at least, I do).
>
>
What's worse, though, is if you copy from Microsoft Word office:X (a
>
Carbon application) into Mail.app (a Cocoa application), you frequently
>
don't get all of what you are pasting. Or the past deletes information
>
from the Cocoa TextView.
>
>
All of this wouldn't be annoying if there were simply no Carbon
>
applicaitons. But they are going to be around for a long time. And right
>
now, it's easy to envision people complaining to me that my application
>
don't handle copy-and-paste correctly.
>
>
What to do? Is Apple fixing this?
I expect Apple is indeed working on trying to fix this, since even if there were
no Carbon applications there would still be the need to copy/paste to and from
Classic. I also don't accept that the Classic/Carbon HFS TYPE "symbol" based typing
system is the best way to go: We need something more general, and less tied to any
file system (this includes "file name extensions").
The problem is that there are two different type systems: Carbon/Classic and
Cocoa. The Classic/Carbon type system is steeped in the HFS file system specific
TYPE designation. While the Carbon (YellowBox/OpenStep) system is designed to be an
abstract type system (for portability reasons, if for no other). However, since
most of the pasteboard types (and, similarly, the file types) have, historically,
been "file name extensions, without the period", many (most?) developers (probably
including many within Apple, judging by the documentation) have assumed they were
one and the same. (Hence, many from the Classic/Carbon camp have accused Cocoa of
being strictly "file name extension" based.)
In my opinion, the solution lies in making the type system explicitly abstract
(probably using the [localizable] abstract type names that are now storable in Info
Plists [though I further think that there needs to be the addition of hierarchical
type information]), and moving both Carbon and Cocoa to this system. Admittedly,
there will still need to be a translation between the Classic, and older Carbon,
type system to this universal, abstract type system, but we will at least have a
framework from which to make future progress. (The transition for Cocoa should be
rather straight forward, though programmers that have historically assumed that the
implementation of the type system would always equate the type with "file name
extensions, without the period", stored within NSStrings, will have to mend their
ways---as have all programmers that have ever made assumptions based upon
implementation details. Perhaps someone more familiar with Carbon can comment on
how difficult it would be to make the transition within Carbon.)
Just my thoughts.
David email@hidden