[jbosstools-dev] VPE editor

[Max Areshkau]

Snjezana Peco wrote:
> 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.
>
I just have tried display.asyncExec(new Runnable()) and behavior is 
deferent from  when  i am using proxy. I am see wait cursor, user input 
are interrupted for some time in case display.asyncExec using.
> 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.
>>
>>
>