[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