[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