Re: bypass NSApp
Re: bypass NSApp
- Subject: Re: bypass NSApp
- From: Julien Isorce <email@hidden>
- Date: Sat, 11 Jul 2009 01:50:21 +0200
2009/7/11 Mike Abdullah <email@hidden>
>
> On 11 Jul 2009, at 00:33, Julien Isorce wrote:
>
> Hi,
>>
>> First, thx for your reply.
>>
>> 2009/7/10 Scott Thompson <email@hidden>
>>
>>
>>> On Jul 10, 2009, at 3:40 PM, Julien Isorce wrote:
>>>
>>> In GNUstep it's possible to decide which pthread is the "main thread".
>>>
>>>> I mean the first pthread which call GSRegisterCurrentThread, is the main
>>>> thread.
>>>>
>>>> And then the NSApp must be init and run in this main thread, as it's
>>>> required on MacOSX.
>>>>
>>>> Is it possible to change the "main thread" as far as Cocoa is concerned,
>>>> on
>>>> MacOSX ? (something like GSRegisterCurrentThread)
>>>>
>>>>
>>> What is the point of such a routine?
>>>
>>> Suppose that the application starts and we give the main thread the label
>>> "Thread A". You spin up an new thread that we will give the label
>>> "Thread
>>> B. You then use your routine to make the thread with the label "Thread
>>> B"
>>> to be the main thread. Now the main thread has a "Thread B" sign and
>>> there
>>> is another thread with a "Thread A" sign hanging off of it.
>>>
>>> How is this different than if you had simply started the application gave
>>> the the main thread the label "Thread B", then started a new thread and
>>> gave
>>> it the label "Thread A"?
>>>
>>>
>> sure but in the previous mails I tried to explain that I am making a
>> plugin
>> (which consists of a dynamic library) of a program which I have not the
>> source code.
>>
>> So in your example, the difference is that I can run the NSApp in the main
>> thread (Thread B).
>> And it's usefull because I have no access to the thread A.
>>
>> With GNUstep Cocoa, in the plugin I create a pthread (thread B) and then I
>> am registering it to be the main thread. Then I am running NSApp in there.
>>
>>
>>
>>>
>>> In this way no performInMainThreads are borken, and it's a solution to my
>>>
>>>> problem.
>>>>
>>>>
>>> It's still not clear what your problem is.
>>>
>>> What exactly is it that are you trying to do on Mac OS X? What is the
>>> environment in which your code is running and what effect are you trying
>>> to
>>> achieve?
>>>
>>> The only guess I can make is that you are trying to create a plugin for
>>> something like the GIMP and you want to use Cocoa from that plugin.
>>>
>>
>> yup something like that.
>>
>>
>>>
>>> There may be a way to solve your problem properly in Mac OS X,
>>>
>>
>>
>> I experimented on MacOSX and it seems that a pthread (I mean a thread
>> created using native C api) is automatically converted to a NSThread so
>> it's
>> cool. (whereas on GNUstep I have to call GSRegisterCurrentThread)
>>
>> So the final question: is there a way to make [NSThread isMainThread]
>> return
>> YES in a thread different that the main thread of a process, on MacOSX ?
>>
>
> But as has already been pointed out, consider the wider implications of
> this. If somebody else wrote a plug-in using the same technique, there would
> be two plug-ins contending for the definition of "the main thread." This
> alone should be reason enough why Cocoa does not offer such an API (or at
> least that I am aware of)
you are enterely right so then we are moving to the other solution: bypass
NSApp,
making a classic NSRunLoop but add to it the ability to perform/handle the
events that the NSApp usually is the only one able to do.
I am open to any solution, even if it requires to have only one plugin which
has the "main thread" (=only one plugin based on Cocoa)
Sincerely
Julien
>
>
> Mike.
>
>
_______________________________________________
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