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: Fritz Anderson <email@hidden>
- Date: Sun, 7 Nov 2010 11:01:19 -0600
On 7 Nov 2010, at 9:35 AM, eveningnick eveningnick wrote:
>> You seem to be trying to find ways to use the frameworks in ways that are
>> not intended. Why are you not using NSApplicationMain in the normal way?
>>
> Just for the sake of my own understanding. There's nothing extraordinary i
> am doing there, but for example, i need to "delay" the launch of my
> application and registering all the observers/event taps before the "master
> application" starts
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.
For your more-specific question, I found many promising leads by googling "cocoa application modal progress bar".
— F
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.
_______________________________________________
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