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,
    >
    > This is *NOT* true.
    >
    As you point out, this depends on the situation. I can certainly write
    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 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. 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 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)
    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. 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.
previous month october 2002 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today