Re: [jbosstools-dev] VPE editor

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("(a)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_Jav.... >>> >>> >> >> 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. > >