Carbon vs Cocoa arguments
-
Hello,
I'm very new to programming.
I've never code in C or anything else, but I wanna begin to learn
C and Cocoa. And I do that with a friend. But he irritates me about
Carbon.
I don't wanna touch Carbon. Carbon is great to port application from OS
9
but it's not as good as Cocoa...
But for me, as I know nothing about programming, it's just a feeling...
I say to my friend + look, carbon app are not as beautif as Cocoa, and
they're slower etc...;
and he respond that Carbon is evolving (that is true, like the new
Drawer.h etc),
and will be the major API for OS X.
Some of other of theirs arguments that no big software company haven't
already port an app
in Cocoa, just because Carbon's code is nearer the Windows'app
code(that is in some case true) and they'll
never do a completely different code for a really smaller market etc
etc...
He takes the example of Microsoft and Adobe. But for me, Photoshop,
Illustrator etc... and Office X
are not great at all on OS X. I don't feel them good in OS X. Slow...
ugly (OS X is for me just a make up on
Office 2001)
Where can i found documentation that compares Carbon and Cocoa up to
the smallest level in the system
integration... I want to prove him that Cocoa is better with something
else that my feelings.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
This actually goes against what you're trying to prove, but might give
you a little different viewpoint on Carbon.
http://www.unsanity.org/archives/000024.php
On Tuesday, October 8, 2002, at 04:26 PM, Benjamin Frere wrote:
> Hello,_______________________________________________
>
> I'm very new to programming.
> I've never code in C or anything else, but I wanna begin to learn
> C and Cocoa. And I do that with a friend. But he irritates me about
> Carbon.
> I don't wanna touch Carbon. Carbon is great to port application from
> OS 9
> but it's not as good as Cocoa...
> But for me, as I know nothing about programming, it's just a feeling...
> I say to my friend + look, carbon app are not as beautif as Cocoa, and
> they're slower etc...;
> and he respond that Carbon is evolving (that is true, like the new
> Drawer.h etc),
> and will be the major API for OS X.
> Some of other of theirs arguments that no big software company haven't
> already port an app
> in Cocoa, just because Carbon's code is nearer the Windows'app
> code(that is in some case true) and they'll
> never do a completely different code for a really smaller market etc
> etc...
> He takes the example of Microsoft and Adobe. But for me, Photoshop,
> Illustrator etc... and Office X
> are not great at all on OS X. I don't feel them good in OS X. Slow...
> ugly (OS X is for me just a make up on
> Office 2001)
>
> Where can i found documentation that compares Carbon and Cocoa up to
> the smallest level in the system
> integration... I want to prove him that Cocoa is better with something
> else that my feelings.
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I probably shouldn't be sucked in by what is probably a troll, but I can't resist.
Here's the long and short of it: Don't bother trying to persuade your friend. While I agree with your assessment of the merits of Cocoa (I'm a convert from Classic Toolbox programming and haven't done any Carbon or Toolbox since the first time I launched into ProjectBuilder), but that doesn't make your friend's opinion wrong: There are good arguments for choosing Carbon over Cocoa in some situations, and a good many people who believe that Carbon stands on its merits as an API. It cannot be denied that there are some advantages to Carbon, especially for entrenched toolbox developers.
As for whether Carbon will be the "major" API, I can't say. Certainly there are now more Carbon developers than Cocoa developers, and that will continue to be true for the foreseeable future, but Apple is not hedging their bets with Cocoa - they are using it extensively for development, and several smaller Cocoa developers are able to compete with much larger companies creating Carbon apps.
If your friend likes Carbon and is comfortable with that environment and has made an informed decision that you simply disagree with, let it be. There's nothing to stop you from learning Cocoa --- please do. And you'll have an advantage if you do so: You'll be able to use any code your friend writes from within your Cocoa application, whereas, he won't have the same option to incorporate your code. In most cases, he'll also have to write more lines of code to create apps that conform to the UI guidelines, and have a slower application to boot.
My advice is: Learn Cocoa and create some killer apps. That will convince your friend more assuredly than any words or documentation or Cocoa-mailing-list epistles.
Just my two cents.
Jeff
On Tuesday, Oct 08, 2002, at 02:26PM, Benjamin Frere <saxo...> wrote:
> Hello,_______________________________________________
>
> I'm very new to programming.
> I've never code in C or anything else, but I wanna begin to learn
> C and Cocoa. And I do that with a friend. But he irritates me about
> Carbon.
> I don't wanna touch Carbon. Carbon is great to port application from OS
> 9
> but it's not as good as Cocoa...
> But for me, as I know nothing about programming, it's just a feeling...
> I say to my friend + look, carbon app are not as beautif as Cocoa, and
> they're slower etc...;
> and he respond that Carbon is evolving (that is true, like the new
> Drawer.h etc),
> and will be the major API for OS X.
> Some of other of theirs arguments that no big software company haven't
> already port an app
> in Cocoa, just because Carbon's code is nearer the Windows'app
> code(that is in some case true) and they'll
> never do a completely different code for a really smaller market etc
> etc...
> He takes the example of Microsoft and Adobe. But for me, Photoshop,
> Illustrator etc... and Office X
> are not great at all on OS X. I don't feel them good in OS X. Slow...
> ugly (OS X is for me just a make up on
> Office 2001)
>
> Where can i found documentation that compares Carbon and Cocoa up to
> the smallest level in the system
> integration... I want to prove him that Cocoa is better with something
> else that my feelings.
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, October 8, 2002, at 05:26 PM, Benjamin Frere wrote:
> I say to my friend + look, carbon app are not as beautif as Cocoa, and
> they're slower etc...;
Neither of which is true - both appear as standard Aqua apps, and there
are no speed differences that I'm aware of.
> and he respond that Carbon is evolving (that is true, like the new
> Drawer.h etc),
> and will be the major API for OS X.
It's *a* major API for OS X, not *the* major API. Cocoa and Carbon are
equals in this respect.
> Some of other of theirs arguments that no big software company haven't
> already port an app
> in Cocoa, just because Carbon's code is nearer the Windows'app code
Not at all. Most of the big companies that have chosen Carbon did so
because it's much, much closer to the API used for the Mac prior to OS X.
> He takes the example of Microsoft and Adobe. But for me, Photoshop,
> Illustrator etc... and Office X
> are not great at all on OS X. I don't feel them good in OS X. Slow...
> ugly (OS X is for me just a make up on
> Office 2001)
Perhaps - but that's a subjective opinion, and regardless, it has
nothing at all to do with them using Carbon.
> Where can i found documentation that compares Carbon and Cocoa up to
> the smallest level in the system
> integration...
The lowest level is Core Foundation and BSD; both Carbon and Cocoa are
layers atop that.
> I want to prove him that Cocoa is better with something else that my
> feelings.
But, that's the *best* reason there is to use Cocoa. Use what works best
for you - your users won't know or care which toolkit you used. And let
your friend use whatever works best for him; unless you're working
together on a project, his choice of toolkit doesn't affect you in the
least.
sherm--
Precious burden, I capture deep inside.
What would my life be, without pain in me?
"Enter my Mind" - Drain S.T.H
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, Oct 8, 2002, at 23:48 Europe/Ljubljana, Scott Corliss wrote:
> This actually goes against what you're trying to prove, but might give
> you a little different viewpoint on Carbon.
>
> http://www.unsanity.org/archives/000024.php
>
>
> On Tuesday, October 8, 2002, at 04:26 PM, Benjamin Frere wrote:
>
>>
>> Where can i found documentation that compares Carbon and Cocoa up to
>> the smallest level in the system
>> integration... I want to prove him that Cocoa is better with
>> something else that my feelings.
>> _______________________________________________
>>
It naturally depends on what you do, but for developing a normal
application with GUI, there is simply no way Carbon can be compared to
Cocoa. It is much easier and faster to develop such an application in
Cocoa with less bugs. Just compare source examples from Apple for
somehow similar apps - TextEdit in Cocoa and SimpleText in Carbon. And
then see the Sketch in Cocoa for example of drawing app. If these
examples won't convince you, well, there's Apple's recommendation to
develop new apps in Cocoa, which they adhere to (everything new is
Cocoa).
Why is this so?
Cocoa is a real object-oriented platform (with all the benefits of such
a thing) with concepts (patterns) which are useful to you even if you
just learn them and use them in a different environment (e.g. C++ and
MS Windows). Carbon is a C environment with all the weaknesses and
strengths of such procedural approach (it does try to emulate OO with
opaque types, but that's just that - emulation which does get in a way
and causes code to be not as legible and bug-free as with real OO
environment). You can also use most of Carbon API in Cocoa app, such as
QuickTime (and encapsulate it in OO if you like, so it can fit
naturally), but not reverse (Cocoa in Carbon app does not make much
sense, because of concept mismatch).
And there is also a catch - it is a big problem if your developers
cannot grasp object-oriented development! In this case (speaking from
experiences) it is better to use procedural approach such as C and
Carbon, because in OO environment they will use procedural approach
anyway (despite the code being in OO language), but the mismatch will
show as a very bad code.
So developers should at least try to do some examples, go through
tutorial, and then if they cannot see any positive side of going with
Cocoa, leave them to do it the old way.
izidor
P.S. A little bit of history - the great OO bible Design Patterns by a
gang of four was an offspring of a project, commisioned by a bank,
which investigated how could a software be migrated from NeXT platform
(predecessor of Cocoa) to some other, in case of vendor problems. They
tried to distill an essence of NeXT for use in C++. The byproduct was a
very successful book - so you see, knowing Cocoa can be useful for C++
programmers, too (but if they do know it, they would not want to be C++
programmers for long :-)
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thu, Oct 10, 2002 at 10:48:07AM +0200, Izidor Jerebic wrote:
:
: On Tuesday, Oct 8, 2002, at 23:48 Europe/Ljubljana, Scott Corliss wrote:
: >
: >This actually goes against what you're trying to prove, but might give
: >you a little different viewpoint on Carbon.
: >
: >http://www.unsanity.org/archives/000024.php
:
: It naturally depends on what you do, but for developing a normal
: application with GUI, there is simply no way Carbon can be compared to
: Cocoa. It is much easier and faster to develop such an application in
: Cocoa with less bugs. Just compare source examples from Apple for
: somehow similar apps - TextEdit in Cocoa and SimpleText in Carbon. And
: then see the Sketch in Cocoa for example of drawing app. If these
: examples won't convince you, well, there's Apple's recommendation to
: develop new apps in Cocoa, which they adhere to (everything new is
: Cocoa).
These are RAD-type arguments to be made to developers. I'd like to see
more discussion on performance that is more visible to the end user.
The section that I found most interesting was this one:
Cocoa is generally SLOWER than Carbon, despite what most public
thinks. (When a Carbon app wants to call a function in itself,
it jumps directly to the function address; when Cocoa app wants
to do the same, it goes through a single (ok, there are a few
variations of it) function called objc_msgSend which finds the
correct address and jumps to there. This means each time a Cocoa
method calls another Cocoa method there's 16 to 80 instructions
overhead compared to Carbon. A true bottleneck, however it is
not a design flaw but rather a decision that makes objc quite
flexible to make it achieve what it needs to).
So, my point? Cocoa is not better than Carbon; its just
different. Do not assume Cocoa applications are better than
Carbon. This is often true (bug-wise) due to the fact Cocoa
implements lot of high-level sh*t Carbon developers have to much
with themselves, which cuts the number of bugs in UI code
significantly. However, not all Carbon applications are crap.
Look at Finder (lets keep aside the missing functionality
aspects here) - it is a PowerPlant C++ application. Compare it
to SNAX. Which is faster? When it comes down to tables drawing
speed, Finder wins hands down. So don't think Finder would be
all that faster and better if it was Cocoa. It wouldn't.
Some of the feedback has been interesting:
- Cocoa is a very high level API. It provides an awesome amount
of power and consistency for free. Cocoa is also designed to
solve a relatively general purpose set of development
problems. As such, it is not highly optimized to any one
particular development problem. While it is often trivial to
create a powerful application that exhibits most of the
desired features in a relatively short amount of time, it can
be require a lot of effort to make the program work extremely
efficiently.
Posted by: b.bumgarner on October 1, 2002 06:18 PM
As for mixing and matching APIs:
In 10.2 Carbon & Cocoa UIs can be mixed at the window level --
that means that a Carbon app can host a Cocoa window and vice
versa. I haven't tried this myself, but it looks promising and
is a peek at what future plans are.
Post 10.2 Apple will make it possible to mix and match Cocoa &
Carbon at the widget level - Cocoa popup menu & Carbon checkbox
in the same window. That's the marketing spin on it (After all,
Apple has to market to devs =). My theory is that this means
that Cocoa is going to move to complete sit on top of Carbon. Of
course, for this to happen really means that everything that
Cocoa does today will arrive in Carbon, and must.
Posted by: Rincewind on October 2, 2002 07:50 AM
And as for Finder:
As for speed of PowerPlant vs Cocoa. An application is not fast
because of its API, Language, or Framework - it's fast because
of design and implementation details. The Cocoa based Finder
(known as WorkSpace Manager) on NeXTStep 2.0 on 68040 hardware
was faster than the finder in Mac OS X 10.0 on a G4. It was
comparable to the Finder in 10.1. NOW the Finder has finally
gotten up to speed. And it finally has some of the cool
inter-application communication and services that the original
NeXTStep Workspace Manager. IE 5 had dismal performance as a
Carbon app until recently. A lot of this has had to do with lack
of use (or improper use) of Carbon Events. But for Apple's
supposed flagship application, the Finder, to suffer speedwise
like it did until Jaguar, is NOT a ringing endorsement for
Carbon. While again - Workspace Manager ported fine to Mac OS X
Server 1.x (which was essentially NeXTStep 5.x).
Posted by: j.shell on October 2, 2002 10:47 AM
Thoughts from the developer gallery?
--
Eugene Lee
<eugene...>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, October 8, 2002, at 11:26 PM, Benjamin Frere wrote:
> He takes the example of Microsoft and Adobe. But for me, Photoshop,
> Illustrator etc... and Office X are not great at all on OS X. I don't
> feel them good in OS X. Slow... ugly (OS X is for me just a make up on
> Office 2001)
>
> Where can i found documentation that compares Carbon and Cocoa up to
> the smallest level in the system integration... I want to prove him
> that Cocoa is better with something else that my feelings.
Assuming that you have no plans of having a Windows version of your
application...
The essential difference is in programming style. It is becoming harder
and harder to see differences between mostly Carbon and mostly Cocoa
apps (mostly, because you can mix and use both, for instance when some
Carbon API has no Cocoa counterpart, like KeyChain and others). Some
things may be faster with one or another, but I don't see a clear cut
advantage here (except for scrolling through large iTunes-like tables
where Carbon beats Cocoa hands down).
I think that Cocoa programming is much more modern, elegant and fast
than Carbon programming, and this is what you should do.
There's at least one large Mac developer that took the Cocoa route:
Apple.
- Most if not all of the new iApps are Cocoa: iPhoto, iCal, iChat,
Address Book...
- The "NeXTSTEP legacy" apps are Cocoa: Mail, TextEdit, Preview,
Terminal, most Utilities...
- Other traditional Mac apps are rewritten using Cocoa: Sherlock, and
others to come I'm sure.
It looks to me that Cocoa is very much the present and future of Mac
programming, and I wouldn't start a new Mac development with anything
else. And BTW, all these Cocoa apps are made with Objective-C.
Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thursday, Oct 10, 2002, at 12:51 Europe/Ljubljana, Eugene Lee wrote:
> On Thu, Oct 10, 2002 at 10:48:07AM +0200, Izidor Jerebic wrote:
> :
> : On Tuesday, Oct 8, 2002, at 23:48 Europe/Ljubljana, Scott Corliss
> wrote:
> : >
> : >This actually goes against what you're trying to prove, but might
> give
> : >you a little different viewpoint on Carbon.
> : >
> : >http://www.unsanity.org/archives/000024.php
> :
> : It naturally depends on what you do, but for developing a normal
> : application with GUI, there is simply no way Carbon can be compared
> to
> : Cocoa. It is much easier and faster to develop such an application in
> : Cocoa with less bugs. Just compare source examples from Apple for
> : somehow similar apps - TextEdit in Cocoa and SimpleText in Carbon.
> And
> : then see the Sketch in Cocoa for example of drawing app. If these
> : examples won't convince you, well, there's Apple's recommendation to
> : develop new apps in Cocoa, which they adhere to (everything new is
> : Cocoa).
>
> These are RAD-type arguments to be made to developers. I'd like to see
> more discussion on performance that is more visible to the end user.
> The section that I found most interesting was this one:
>
> Cocoa is generally SLOWER than Carbon, despite what most public
> thinks. (When a Carbon app wants to call a function in itself,
> it jumps directly to the function address; when Cocoa app wants
> to do the same, it goes through a single (ok, there are a few
> variations of it) function called objc_msgSend which finds the
> correct address and jumps to there. This means each time a Cocoa
> method calls another Cocoa method there's 16 to 80 instructions
> overhead compared to Carbon. A true bottleneck, however it is
> not a design flaw but rather a decision that makes objc quite
> flexible to make it achieve what it needs to).
>
>
Now, this is really really misleading...
First, there is no such thing as "Cocoa method". Applications that use
Cocoa are normally written in Objective-C, but speed-critical parts of
Cocoa app may be written in C, C++, assembler, or anything else you
want to use for that.
Second, end-user in principle cannot distinguish Carbon from Cocoa app
(also because applications may have mixed widgets, custom widgets,
etc.). But well-written Carbon app may take so much more resources to
implement what Cocoa gives for free or much easier that management
decides it is not worth it - in that case one may spot badly written
Carbon apps (it seems that they are in majority, though).
And, finally, speed is the result of good design and optimizations, not
the API you work with. Speed-critical sections of your program are
typically implemented by custom code, which does the job in fastest
possible way given the parameters of your application. And since
putting together an application is faster and less buggier in Cocoa
(and uses sound OO principles implicitly), there remains more time for
optimizations. So using the same amount of resources (time, people),
Cocoa app is supposed to be faster and less buggy and better optimized,
because you spend less time on non-essential things.
izidor
P.S. As for Cocoa application speed: you can do your Cocoa application
about panel with custom assembler code that writes directly to video
memory for maximum performance so it appears on screen extremely fast
(just in case somebody misses the point: this is a joke to show how
performance can be utterly pointless for some parts of your
application).
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thursday, October 10, 2002, at 12:51 , Eugene Lee wrote:
> Cocoa is generally SLOWER than Carbon,
This is *NOT* true.
> despite what most public
> thinks. (When a Carbon app wants to call a function in itself,
> it jumps directly to the function address; when Cocoa app wants
> to do the same, it goes through a single (ok, there are a few
> variations of it) function called objc_msgSend which finds the
> correct address and jumps to there. This means each time a Cocoa
> method calls another Cocoa method there's 16 to 80 instructions
> overhead compared to Carbon.
This is truth, *but*...
> A true bottleneck
...it is far from true bottleneck. A bottleneck is not just a relatively
slow code; a bottleneck is a relatively slow code used in a place where it
harms. Message sending would become that in case you used it, eg. with
NSNumbers for a computation-intensive task -- say, fractals. Nobody does
that; it is why Objective C has the -C part.
Normally though the exact opposite is true: the much higher abstraction
level and easy-to-useness of ObjC with Cocoa libraries allows you to focus
on the problem, which tends to end with a better algorithm. The inevitable
result is that Cocoa apps tend to be actually *FASTER* than
Carbon-or-whatever-other-API apps, made with roughly comparable effort:
you lose some ticks here and there, but get O(n) instead of O(n*n) for
exchange ;)
From the practical experience side I guess the best support is
> But for Apple's supposed flagship application, the Finder, to suffer
> speedwise like it did until Jaguar, is NOT a ringing endorsement for
> Carbon. While again - Workspace Manager ported fine to Mac OS X Server 1.
> x (which was essentially NeXTStep 5.x)
You know, comparing the speed of function call vs. message send (which is
truthfully in average twice or thrice slower) is just as reasonable as
comparing the frequency of G4 and a Pentium, so far as its impact on the
application speed is concerned ;)
Cocoa suffers somehow in OSX (precisely: suffered in 10.0 and 10.1, haven'
t checked in 10.2) by substantial re-writing of its foundation (Foundation,
actually ;), whose new incarnation, split to Core and OO Foundation, is
(or, hopefully, was) considerably less effective than the original thing.
There are also some well-known issues with redrawing (mainly the terrible
redraw-a-rectangle-union-of-all-invalidated-rects howler). That all though
is a library implementation problem, far from a conceptual OOP problem.
Also it might be worth adding that
> These are RAD-type arguments to be made to developers.
RAD-type arguments are *not* for developers, but for users. A developer is
happy developing (presumed it is paid well ;), so the idea of endless
optimization and fixing bugs does not look as too repulsive to him.
It is the user, OTOH, who wants
- a nice and stable application;
- reasonably featured;
- as soon as possible;
- to be upgraded reasonably often;
- with as little number of new bugs in a new release as possible.
All those factors are very very RADdy or, in Mac OS X, Cocoaish.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
on 02-10-10 8:04 AM, Marco Scheurer at <marco...> wrote:
> Other traditional Mac apps are rewritten using Cocoa: Sherlock, and
> others to come I'm sure.
In Jaguar: Apple System Profiler, Help Viewer, Print Center, and System
Events, to name a few.
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thursday, October 10, 2002, at 03:47 PM, Bill Cheeseman wrote:
> on 02-10-10 8:04 AM, Marco Scheurer at <marco...> wrote:
>
>> Other traditional Mac apps are rewritten using Cocoa: Sherlock, and
>> others to come I'm sure.
>
> In Jaguar: Apple System Profiler, Help Viewer, Print Center, and System
> Events, to name a few.
And of course, I also left out all the development apps:
ProjectBuilder, InterfaceBuilder...
Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
You'll notice that Apple System Profiler lost *all* it's drag and
drop ability as well. System Events? Help Viewer always sucked. It
still sucks and it's still slow ;)
Ack, at 10/10/02, Bill Cheeseman said:
> In Jaguar: Apple System Profiler, Help Viewer, Print Center, and System
> Events, to name a few.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
---
Please include any previous correspondence in replies, it helps me
remember what we were talking about. Thanks.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
What drag and drop abilities did ASP have before? I'm curious.
Drag-and-drop is still more limited in Cocoa than in Carbon, but with
Jaguar the situation is much better than it was before.
As for Help Viewer, I wonder why they couldn't just have carbonized
Apple Guide?
Charles
On Thursday, October 10, 2002, at 03:48 PM, Rosyna wrote:
> You'll notice that Apple System Profiler lost *all* it's drag and drop_______________________________________________
> ability as well. System Events? Help Viewer always sucked. It still
> sucks and it's still slow ;)
>
> Ack, at 10/10/02, Bill Cheeseman said:
>
>> In Jaguar: Apple System Profiler, Help Viewer, Print Center, and
>> System
>> Events, to name a few.
>
> --
>
>
> Sincerely,
> Rosyna Keller
> Technical Support/Holy Knight/Always needs a hug
>
> Unsanity: Unsane Tools for Insanely Great People
> ---
>
> Please include any previous correspondence in replies, it helps me
> remember what we were talking about. Thanks.
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Ack, at 10/10/02, Charles Srstka said:
> What drag and drop abilities did ASP have before? I'm curious.
> Drag-and-drop is still more limited in Cocoa than in Carbon, but
> with Jaguar the situation is much better than it was before.
You could drag and drop *everything*. say someone needs the mem
capacity, drag and drop the container onto a text field and it was
all nicely formatted for you. (Below is from the 10.0.4 version of
ASP)
Memory overview
Built-in memory: 768 MB
Location Size Memory type
DIMM0/J21 128
MB SDRAM
DIMM1/J22 128
MB SDRAM
DIMM2/J23 512
MB SDRAM
External L2 cache: 1 MB
> As for Help Viewer, I wonder why they couldn't just have carbonized
> Apple Guide?
I have no clue what it was ever killed. it was the greatest thing
EVER! (but dang hard to program for)
Actually, with the accessibility API, you could probably pretty
easily make a cocoa implementation of it.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
---
Please include any previous correspondence in replies, it helps me
remember what we were talking about. Thanks.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
on 02-10-10 4:48 PM, Rosyna at <rosyna...> wrote:
> You'll notice that Apple System Profiler lost *all* it's drag and
> drop ability as well. System Events? Help Viewer always sucked. It
> still sucks and it's still slow
Apple System Profiler also lost almost all of its formerly good AppleScript
support, but my guess is that it will be coming back shortly.
Why do you put a question mark after System Events? Its AppleScript support
is now vastly increased, allowing scripters to control the file system
without being tied to Finder, to add and remove Folder Actions (AppleScripts
attached to folders) for the first time since Mac OS 9, to add and remove
items from the Login Items list, and other things.
Help Viewer has certainly taken its lumps under Mac OS X, but though not yet
cured it is IMHO much improved in Jaguar. It's AppleScript support has also
been somewhat enhanced.
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thursday, October 10, 2002, at 04:58 PM, Rosyna wrote:
>> As for Help Viewer, I wonder why they couldn't just have carbonized
>> Apple Guide?
>
> I have no clue what it was ever killed. it was the greatest thing
> EVER! (but dang hard to program for)
Just think - we could have had that instead of the piece-of-trash Help
Viewer, and it probably would have been less work to boot, since they
wouldn't have had to completely rewrite the thing.
> Actually, with the accessibility API, you could probably pretty easily
> make a cocoa implementation of it.
Wouldn't be any good, because it wouldn't be preinstalled with Macs,
and therefore newbies wouldn't have it. Plus, there's the whole issue
of getting developers all to use your tool... if no one wrote
documentation for it, it would be useless.
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> Cocoa is generally SLOWER than Carbon,As you point out, this depends on the situation. I can certainly write
>
> This is *NOT* true.
>
a Carbon application that is much faster than its Cocoa counterpoint.
But this is due in part to many things, including the Obj-C runtime.
> Normally though the exact opposite is true: the much higher abstractionThis depends on the programmer and the application. A lazy programmer
> level and easy-to-useness of ObjC with Cocoa libraries allows you to
> focus
> on the problem, which tends to end with a better algorithm. The
> inevitable
> result is that Cocoa apps tend to be actually *FASTER* than
> Carbon-or-whatever-other-API apps, made with roughly comparable effort:
> you lose some ticks here and there, but get O(n) instead of O(n*n) for
> exchange ;)
will take the easy road, which is to use NSNumer's stored in an
NSArray. Very few applications are doing heavy number crunching. IMHO,
a faceless applicaiton like a command line tool should be doing that
stuff and not wasting cycles in the UI. But when an app is doing number
crunching, it's usually without the aid of the operating systemit's
custom code that's portable and as fast as possible. So in the general
case (which is a typical application showing windows and accepting user
feedback 95% of the time) Cocoa can very well be slower than Carbon.
> From the practical experience side I guess the best support isThe Finder has many issues with it. I can make a Cocoa applicaiton
>
>> But for Apple's supposed flagship application, the Finder, to suffer
>> speedwise like it did until Jaguar, is NOT a ringing endorsement for
>> Carbon. While again - Workspace Manager ported fine to Mac OS X
>> Server 1.
>> x (which was essentially NeXTStep 5.x)
however that's just as slow as the Finder, if not slower. Much of the
Finder's problems stem from problems that Cocoa has as well: the UI is
_not_ thread safe for the most part. The Finder was sped up in Jaguar
from spawning new threads, which was possible due to improved threading
capabilities in Jaguar (much more of Jaguar is thread-safe in Carbon
and Cocoa). Using the Finder as an example of Carbon's speed is like
using the sloth-like Mail.app (or worse, ProjectBuilder, the slowest
IDE ever made) as an example of Cocoa's speed.
Cocoa developers have a slight knee-jerk reaction to Carbon, shying
away from it as much as possible. Carbon is still very viable, and has
to be if the Mac will be a major player in the PC market considering no
major commerical applications have been written in Cocoa yet. Carbon
and Cocoa use eachother, but many things still exist in only one
framework (disclosure button, clock control, checkbox group box, to
name a few, are all missing from Cocoa still).
The point is, use whatever you want. Cocoa uses Carbon but is easier to
program for. Carbon is backwards compatible for those 80% of the Mac
users still using OS 9. And in the future, they will merge further and
become dependant on the other, making stupid arguments like this moot.
Ryan
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
What is System Events? The Standard Additions OSAX is the one that
handles the AppleScript for the system, if thats what you mean?
Ack, at 10/10/02, Bill Cheeseman said:
> Why do you put a question mark after System Events? Its AppleScript support
> is now vastly increased, allowing scripters to control the file system
> without being tied to Finder, to add and remove Folder Actions (AppleScripts
> attached to folders) for the first time since Mac OS 9, to add and remove
> items from the Login Items list, and other things.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
---
Please include any previous correspondence in replies, it helps me
remember what we were talking about. Thanks.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Friday, October 11, 2002, at 06:44 , Ryan McGann wrote:
>>> Cocoa is generally SLOWER than Carbon,
>>
>> This is *NOT* true.
>>
> As you point out, this depends on the situation.
Yup. And therefore is just is not *generally* true. Am I not understand
plain English or what?
> I can certainly write
> a Carbon application that is much faster than its Cocoa counterpoint.
Certainly. And I can write an assembler-based one which would be a blue
lightning compared to the one of yours.
The most important point is that the Cocoa app would be finished in a week
(presumed a simple app), whilst its Carbon counterpart -- if you wanted it
to offer comparable services, stability, and also the speed -- would take
at least a month, probably more. Moreover, it would be a bitch to maintain
and upgrade, whilst with the Cocoa app it tends to be comparatively a
child's play.
Of course, the same stands for the assembler one: it would be much more
faster than Carbon, but it would be also much more difficult to make,
maintain, and upgrade.
This is very natural, and if you think of it also quite understandable,
rule: the more hi-level and abstract API you use, the faster and simpler
development, the easier maintenance and upgrades -- and the slower the
result (presumed algorithms are precisely the same).
Even if we stopped at that, it would mean generally Cocoa's better, since
for *VAST* majority of apps the development speed, stability, simple
maintenance and upgrading is just *so much* more important than raw speed.
Nevertheless, there's more to that -- with the time spared you can, as I'
ve already written, use it to polish algorithms and optimize bottlenecks,
which means that in practice a Cocoa app would not only sooner hit market,
be more stable, more featured, easier to maintenance and upgrade, but
*also* faster.
Of course, you can trade: you can eg. use the time saved to overstuff the
thing by features, leaving out any optimization (like it seems to be with
ProjectBuilder).
>> Normally though the exact opposite is true: the much higher abstraction
>> level and easy-to-useness of ObjC with Cocoa libraries allows you to
>> focus
>> on the problem, which tends to end with a better algorithm. The
>> inevitable
>> result is that Cocoa apps tend to be actually *FASTER* than
>> Carbon-or-whatever-other-API apps, made with roughly comparable effort:
>> you lose some ticks here and there, but get O(n) instead of O(n*n) for
>> exchange ;)
> This depends on the programmer and the application. A lazy programmer
> will take the easy road, which is to use NSNumer's stored in an
> NSArray.
Yup. And since...
> Very few applications are doing heavy number crunching.
...it would very probably show that his laziness was the most reasonable
thing to do, for the lost of speed would prove completely unimportant (in
order of a tenth of second at a keyclick or so), whilst the difference in
development speed (=price), result stability, maintenance-freeness (=again
price), and upgradability is *VASTLY* important.
If not, well, profiling would show the bottleneck and it would be time to
re-write it using C++ and Carbon API, or more probably plain C and BSD API,
or even -- if the worst comes to the worst -- assembler and
hand-optimized Altivec code.
Again, what is *immensely* important to grasp is that the speed of the
original Cocoa development makes free time for this. OTOH, if you have to
implement Services or spellchecking (and zillion of other things) yourself
lest they don't work, as it is in Carbon, you lose this time futilely in
tasks which could and should work automagically -- and there would be no
remaining one for necessary optimization (if any).
> The Finder has many issues with it. I can make a Cocoa applicaiton
> however that's just as slow as the Finder, if not slower.
This doesn't seem to be the right way of argument. I surely can make an
AltiVec-assembler-optimized application slower than anything given, just
exploiting a few exponential algorithms. So what?
> Much of the
> Finder's problems stem from problems that Cocoa has as well: the UI is
> _not_ thread safe for the most part. The Finder was sped up in Jaguar
> from spawning new threads, which was possible due to improved threading
> capabilities in Jaguar
I don't know Finder implementation, but did you appreciate that the UI
does not need to be thread-safe the slightest bit to allow multithreaded
apps? With a half-decent design, there's the one UI thread, and any number
of worker ones. After all, the OpenStep UI was much less thread-safe than
OSX one is; nevertheless, Workspace Manager did much better multithreading
than Finder does now.
> Cocoa developers have a slight knee-jerk reaction to Carbon, shying
> away from it as much as possible.
That's quite simple: if you got used to an excellent set of power tools,
you naturally shy away from home-made rough half-nonfunctional bend
screwdrivers and hammers with loose heads. The somewhat allergic reaction
is there sice, due to the very sad fact there are some APIs which are *not*
available in Cocoa, we are *forced to* use the measly API quite often,
which of course increases our aversion.
> Carbon is still very viable, and has
> to be if the Mac will be a major player in the PC market considering no
> major commerical applications have been written in Cocoa yet.
This is another can of worms I would rather not open again: it was
discussed to death and over already. The short answer: had Apple not
pollute Mac OS X by the Carbon stuff, there would be -- after all, there
*were* ones even for NeXTStep with its infinitely less userbase ages ago,
from companies like Adobe(!) or Lotus.
> The point is, use whatever you want. Cocoa uses Carbon but is easier to
> program for. Carbon is backwards compatible for those 80% of the Mac
> users still using OS 9. And in the future, they will merge further and
> become dependant on the other, making stupid arguments like this moot.
Should we just argue each other, it would be moot all right. Don't forget
though the thread begun by a question of someone who does not know either
Cocoa or Carbon yet, *selecting what to learn*!
That's where this argument comes very very useful. Unless the person needs
OS9-codebase-compatibility, it would be extremely unclever to go the
Carbon route: the difference is just too big. The point is that unless he
tries he can't know -- and from posts like yours it might seem that it's
roughly equivalent to write in Carbon and Cocoa, since the advantages and
disadvantages more or less balance -- and *that* is far from truth. Unless
you explicitly *do need* Carbon for some reason or other, it would be just
*futile* to select it over Cocoa.
In short: the rational Mac OS X development is
(a) if you for some reason need to stick with any specific API (be it
Carbon, BSD, Java Swing...), just use it;
(b) otherwise, always use ObjC/Cocoa as the main API;
(c) with very small parts, preferrably in separate wrappers, for those
things Cocoa does not support (yet).
---
Ondra Hada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
on 02-10-11 4:20 AM, Rosyna at <rosyna...> wrote:
> What is System Events? The Standard Additions OSAX is the one that
> handles the AppleScript for the system, if thats what you mean?
>
> Ack, at 10/10/02, Bill Cheeseman said:
>
>> Why do you put a question mark after System Events? Its AppleScript support
>> is now vastly increased, allowing scripters to control the file system
>> without being tied to Finder, to add and remove Folder Actions (AppleScripts
>> attached to folders) for the first time since Mac OS 9, to add and remove
>> items from the Login Items list, and other things.
No. The Standard Additions OSAX does have a number of commands that are
considered standard in any AppleScript implementation, including the
read/write commands that let you create, write and read text and other files
via AppleScript. But it is ancillary to the main AppleScript command set
(i.e., the AppleScript language). The language and engine reside in the
AppleScript component in /System/Library/Components. The Finder contains a
great many commands of its own for scripting the file system, processes, and
other aspects of the system. In addition, an increasing number of
applications installed by the system installer are themselves scriptable,
such as Help Viewer, Apple System Profiler, System Preferences, and others.
For many years, the Finder has been the primary focus of file system and
system AppleScripting, both in the classic Mac OS and on Mac OS X. It is
true that Standard Additions has some older commands (it predates the
scriptable Finder) that can be used as alternatives to access the file
system, but the Finder's commands are much more extensive and powerful.
One or two releases ago, the Mac OS X System Events application began to
take on some of the Finder's AppleScript file system and processes
responsibilities. You could still send these Apple events to the Finder, but
the Finder passed them along to the System Events application for execution
(and, behind the scenes, the loginwindow application may play a role, too).
Now, in Jaguar, the System Events application has acquired substantial
additional AppleScript support, and Apple's AppleScript team now recommends
that the commands it supports be sent directly to the System Events
application. System Events now implements many AppleScript commands that the
Finder does not implement, and the ones that the Finder also implements are
now marked as deprecated (or "legacy") in the Finder.
The System Events and loginwindow applications are in
/System/Library/CoreServices. You can drag the System Events application to
the Script Editor icon in /Applications/AppleScript to see its scripting
terminology dictionary. There is more information about it in the
AppleScript 1.9 (Jaguar) Release Notes at
<http://www.apple.com/applescript/release_notes/190OSX.html>. (The
loginwindow application does not have a dictionary, but you can send what
AppleScripters call "raw events" to it, anyway, if you know what their codes
are.)
Later today, you can read my new AppleScript Sourcebook report on
AppleScript 1.9 in Mac OS X 10.2 (Jaguar) at
<http://www.AppleScriptSourcebook.com/applescript/applescript190.html>. It
contains more information about the System Events and loginwindow
applications.
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thursday, Oct 10, 2002, at 09:36 America/New_York, Ondra Cada wrote:
> On Thursday, October 10, 2002, at 12:51 , Eugene Lee wrote:
>
>> Cocoa is generally SLOWER than Carbon,
>
> This is *NOT* true.
Frankly, the most prominent Cocoa apps I have on my iBook are
also the slowest apps I have.
iCal is a horrendous, bloated dog. Unaccountably - it does far less than
Pencil Me In did, but is much slower and RAM-hungry.
Mail is awfully slow. The new Preview is slow. ProjectBuilder is a bit
slow.
OmniWeb is slow, unfortunately.
I'm starting to wonder if using a lot of frameworks kills performance,
somehow. Or maybe excessive use of multithreading?
I don't think it's due to the Objective-C runtime. I don't think it's
purely
due to the dirty-rectangles thing, because non-graphical processing is
also very slow.
Something just ain't right in the bowels of Cocoa these days.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I wish to add that Carbon has some useful APIs which sadly are
not available for Cocoa. The File Manager and the Alias
Manager come to mind. There are some others, somebody
already mentioned the keychain APIs (although I thought
Keychain was being merged into CDSA or something).
The File Manager has functions for performing searches within
folders and such which are faster than the Cocoa counterparts.
This is probably due to using HFS+ b-trees or the fact that full
path names aren't used so less memory has to be moved
around. I'm not quite clear why, perhaps somebody could
clarify. The File Manager also has FSRefs which have no
equivalent in the UNIX world (and wouldn't fix the UNIX
methodology of everything-is-a-file-at-a-statc-path). FSRefs
allow the programmer to assume a file's path is variable, not
constant. The assumption is reversed if you use POSIX file
paths as file primitives. There is a common myth that FSRefs
are equivalent to FileIDs or file descriptors which is false.
FSRefs in OS X work with non-HFS+ volumes so they don't
behave like FileIDs, and file descriptors both require the file to
be open and you can't convert a file desciptor to a path. Core
Foundation has an FSRef object which can be converted to a
CFURL, but it's missing from Foundation proper and the open
source Core Foundation.
Alias Manager complements the File Manager in that you can't
store an FSRef (or for that matter a FileID anymore) or share
one with another process, but you can store an Alias. An Alias
is an arbitrary description of how to find a file. This is very
abstract and thus its behavior is limited by whatever filesystem
it describes. For example on UFS volumes Aliases behave like
symlinks. You can also make Aliases on HFS+ volumes which
break like symlinks by deleting the FileID and host FolderID.
Anyway what Apple ought to do here is create a plugin API so
more Alias formats can be created for new filesystems. They
also ought to provide a friggin Cocoa API. Hell, they should
deprecate the gawd-awful filesystem APIs in Cocoa and write
something new.
Lastly I want to add that I still can't develop Cocoa apps which
follow some Mac HI conventions which results in a
schizophrenic interface. I have a feeling I'll have to rewrite
NSTextView or NSLayoutManager which I still haven't figured
out how to do. Maybe somebody could help me out |-\
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tue, Oct 15, 2002 at 02:52:49AM +0000, <bayleyp...> wrote:
> Lastly I want to add that I still can't develop Cocoa apps which
> follow some Mac HI conventions which results in a
> schizophrenic interface. I have a feeling I'll have to rewrite
> NSTextView or NSLayoutManager which I still haven't figured
> out how to do. Maybe somebody could help me out |-\
Cocoa's text system is not perfect, but it's a lot better than
anything else I've used; it's extremely flexible. And of course,
Douglas Davidson regularly goes above and beyond the call of duty to
answer esoteric questions on this list ;-)
So, how about posting your questions individually? I've always found
it difficult but not impossible to make my Cocoa apps behave like real
Mac apps, and I still think I'm saving time compared to writing them
in Carbon. Just lamenting that Cocoa isn't like the Mac isn't going to
help much.
--
=Nicholas Riley <njriley...> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Huh? How so?
10.2 replaced the sensible double click editing of the past in Cocoa
applications with the non-standard and total productivity destroying
stuff that is expected in Mac OS :-)... what more do you need?
On Monday, October 14, 2002, at 10:52 PM, <bayleyp...> wrote:
> Lastly I want to add that I still can't develop Cocoa apps which_______________________________________________
> follow some Mac HI conventions which results in a
> schizophrenic interface. I have a feeling I'll have to rewrite
> NSTextView or NSLayoutManager which I still haven't figured
> out how to do. Maybe somebody could help me out |-\
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
