Re: Understanding the Run loop idea and the updating of controls during long operations
Re: Understanding the Run loop idea and the updating of controls during long operations
- Subject: Re: Understanding the Run loop idea and the updating of controls during long operations
- From: eveningnick eveningnick <email@hidden>
- Date: Mon, 8 Nov 2010 21:33:00 +0200
Hello Fritz
> You are understood: You want to learn how the high-level application and
> event API works by trying to recreate (or at least explain) it using
> lower-level API.
>
> You can't do it. At least not in general.
>
> To provide the high-level functionality, Apple uses the published low-level
> API, but it also uses unpublished API, and adds functionality that isn't in
> any API, and the whole thing relies upon undocumented interactions between
> all the APIs it uses. Apple can do this because every time it revises the
> high-level calls, its engineers know what the low-level and private calls in
> the same OS release will do.
>
> You don't know what Apple knows, and the whole idea of a high-level
> framework is that you do not have to know, and you should not know. You can
> rely on what the documentation says the high-level API does, but you can't
> rely on (or, usually, accurately reproduce) how it does it. Anything you
> try, to duplicate the high-level functionality, is only a partial guess.
>
> The way to understand Cocoa is to use Cocoa as it comes to you. Using Cocoa
> means trusting it to do its job even though you can't see inside it. That is
> in the nature of any modern application framework.
>
> I programmed for the original Mac, in C. It had an API that could be fully
> documented in well under a thousand pages. It was implemented in code that
> was easy to disassemble and read. I could explain what was going on inside
> every call I made. I wrote my own event loop, and handled my own interrupts.
> Those days are gone, and it is horrible to think of going back to them.
>
> Thank you, that's really the topic i am interested in :). I am wondering,
if any kind of "Mac OS Internals" books exist,
except "Mac OS Internals: A system Approach" by Amit Singh? Maybe you know
some blogs of the developers, or something else to read? Or is this kind of
info "a top secret"?
> For your more-specific question, I found many promising leads by googling
> "cocoa application modal progress bar".
>
Yes, i should've typed that in search bar myself before asking the question.
I have found the answer.
> PS: Yes, you can — when necessary — substitute notionally lower-level API
> (ex: Core Foundation, Application Services, BSD) for many things that are in
> Cocoa. (I say "notionally lower-level," because that API is sometimes
> implemented in terms of Cocoa, and not the other way around.) In this
> particular context of learning Cocoa and duplicating the core of
> NSApplication, that's a bad approach.
>
>
That is nothing more than having a good feeling about understanding how
things work in real under the hood. Of course, these things may and will
change with every new version/patch/whatever, but still there are people who
hardly can write any highlevel line of code, without knowing what is really
going on inside the system. And of course, this is insane to put such adhocs
into production.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden