[jbosstools-dev] VPE editor

Snjezana Peco snjeza.peco at gmail.com
Thu Mar 13 14:59:48 EDT 2008


Max Areshkau wrote:
> Snjezana Peco wrote:
>> Max Rydahl Andersen wrote:
>>>>> Doing it in a seperate thread is a different enhancement I think, 
>>>>> but definitly
>>>>> also worth it. The current idea is just to not update on every 
>>>>> stroke since users
>>>>> would normally write more than one letter and while he is typing 
>>>>> the visual view
>>>>> does not need to be updated 100% live (especially not when its 
>>>>> update seem to be
>>>>> so slow in special cases).
>>>>>
>>>>>
>>>>>       
>>>> I have tried to separate of visual editor update on user input into
>>>> different thread(you can see commnets for JBIDE-675),
>>>> and I founded following problems:
>>>> 1) Modifications of nsIDOM* nodes can be done only in UI thread, if 
>>>> it's
>>>> done in non UI thread it's crashes a
>>>> eclipse.
>>>> 2)If we update nodes in UI thread, the user input thread are 
>>>> suspended.
>>>>     
>>>
>>> Too bad ;( Do we know why there is this limitation ?
>>>
>>>   
>>
>> Mozilla requires DOM modifications to be done in the UI thread. It is 
>> possible to split the VPE action (notifyChanged) into the UI and 
>> non-UI part.
>> This wouldn't be trivial.
>>
>> Snjeza
> Looks like we can modify  DOM not only from UI thread, for it we 
> should use proxy objects (nsIProxyObjectManager), according following
> documentation 
> http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM. 
>
>

The article is talking about calling XPCOM UI from another thread (in 
Eclipse, you can do it using  display.syncExec() or 
display.asyncExec()). However, you can't execute XPCOM methods in non-UI 
thread. In most of the cases, that would crash the application. You can 
separate non-UI part from the UI part and call XPCOM UI using the 
mentioned methods.

Snjeza




More information about the jbosstools-dev mailing list