[jbosstools-dev] VPE editor
Snjezana Peco
snjeza.peco at gmail.com
Fri Mar 14 14:17:02 EDT 2008
Max,
I haven't applied the patch because I have some changes in my code.
However, I have seen that you are using the following method:
proxyNode =
(nsIDOMNode)getProxyObjectManager().getProxyForObject(getEventQueue(),
nsIDOMNode.NS_IDOMNODE_IID,
node,
nsIProxyObjectManager.INVOKE_SYNC);
The method:
private static nsIEventQueue getEventQueue() {
if(eventQueue==null) {
nsIServiceManager serviceManager =
Mozilla.getInstance().getServiceManager();
nsIEventQueueService eventQueueServive =
(nsIEventQueueService)serviceManager.getServiceByContractID("@mozilla.org/event-queue-service;1",nsIEventQueueService.NS_IEVENTQUEUESERVICE_IID);
//$NON-NLS-1$
eventQueue =
eventQueueServive.getSpecialEventQueue(nsIEventQueueService.UI_THREAD_EVENT_QUEUE);
}
return eventQueue;
}
returns event queue in the UI thread what means that your proxy is
created in the UI thread. That is required behavior for
mozilla/xulrunner methods.
The getProxyObjectManager() method is called with the INVOKE_SYNC flag.
This means that you could get a such behavior if you called
notifyChangedInUiThread with display.asyncExec like the following:
VpeController.java (notifyChanged(...) around line 379)
- if (display != null && (Thread.currentThread() == display.getThread())) {
- notifyChangedInUiThread(notifier, eventType, feature, oldValue,
newValue, pos);
- return;
- }
+if (display != null && (Thread.currentThread() == display.getThread())) {
+ display.asyncExec(new Runnable() {
+ public void run() {
+ notifyChangedInUiThread(notifier, eventType,
feature, oldValue, newValue, pos);
+ }
+ });
+ return;
+ }
I believe that you have got the following behavior:
- when a user enter a key, it is shown immediately, but the user waits
for the notifyChanged method to finish, like before.
Snjeza
Max Areshkau wrote:
> Snjezana Peco wrote:
>> 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
>>
> I have tried to implement creation of proxy for modification DOM
> nodes and with it's eclipse doesn't crashes and user can edit source
> page while visual
> part is updated. I have attached my changes. If I run the some code
> without proxy eclipse crashes, but with proxy objects it's works.
> XPCOM methods are executed from non ui thread.
>
>
More information about the jbosstools-dev
mailing list