7:37 p.m.
Hi,
I have two suggestions for improving performance in the VPE editor:
- lazy Visual Editor update
The Visual editor is updated on every keystroke. I propose to postpone
the update for some time. This means - if a user enters a few keys
quickly, the Visual editor will be updated only once. There is the
org.eclipse.wst.sse.ui.sourcevalidation extenison point within the
Webtools project that can be used for adding this feature. It is also
possible to implement this feature using the code I added when fixing
http://jira.jboss.com/jira/browse/JBIDE-1479 (we could use 400 ms during
editing; this is the default value for the sourcevalidation extenison
point).
- adding the Link (Synchronize) action to the Visual editor next to the
Preferences, Refresh, Page Design Options actions.
This action would be a check box similar to the "Link with editor" in
the Package Explorer view. It would be checked/enabled by default. In
that case, the VPE would behave as it does now. If the user disables the
action, the VPE wouldn't be updated (VpeController.notifyChanged()
wouldn't be called). This would be very useful when editing large JSP
files. The user could always call Refresh (or check Link) to show the
visual part of the editor.
These features are easy to implement and don't require a lot of changes
in the code.
Snjeza
8:21 p.m.
- lazy Visual Editor update
The Visual editor is updated on every keystroke. I propose to postpone
the update for some time. This means - if a user enters a few keys
quickly, the Visual editor will be updated only once. There is the
org.eclipse.wst.sse.ui.sourcevalidation extenison point within the
Webtools project that can be used for adding this feature. It is also
possible to implement this feature using the code I added when fixing
http://jira.jboss.com/jira/browse/JBIDE-1479 (we could use 400 ms during
editing; this is the default value for the sourcevalidation extenison
point).
If we don't have that already (I thought we had) then definitly since I even
did that for my trivial HQL to SQL view and that gave a tremendous speedup (at
least it is perceived to the user as such)
- adding the Link (Synchronize) action to the Visual editor next to
the
Preferences, Refresh, Page Design Options actions.
This action would be a check box similar to the "Link with editor" in
the Package Explorer view. It would be checked/enabled by default. In
that case, the VPE would behave as it does now. If the user disables the
action, the VPE wouldn't be updated (VpeController.notifyChanged()
wouldn't be called). This would be very useful when editing large JSP
files. The user could always call Refresh (or check Link) to show the
visual part of the editor.
I see what you mean here, and I like the idea but what happens when the user
disabled the synchronization and changes from one part of the view to the other -
I guess it should be forcefully updated to make sure the two views are in sync when
they edit each others models ?
/max
8:34 p.m.
Max Rydahl Andersen wrote:
....
> I see what you mean here, and I like the idea but what happens when the user
> disabled the synchronization and changes from one part of the view to the other -
> I guess it should be forcefully updated to make sure the two views are in sync when
> they edit each others models ?
>
We could add a preference (using dialog settings or IPersistableElement)
for every editor that has a non-default value for this action. The
action would be changed using IPartListener interface.
Snjeza
10:58 p.m.
> ....
>> I see what you mean here, and I like the idea but what happens when the user
>> disabled the synchronization and changes from one part of the view to the other
-
>> I guess it should be forcefully updated to make sure the two views are in sync
when
>> they edit each others models ?
>>
We could add a preference (using dialog settings or IPersistableElement)
for every editor that has a non-default value for this action. The
action would be changed using IPartListener interface.
I don't understand how having a preference will prevent the synchronization issues
between
the split-view in the VPE editor?
-max
12:41 a.m.
Max Rydahl Andersen wrote:
>> ....
>>
>>> I see what you mean here, and I like the idea but what happens when the user
>>> disabled the synchronization and changes from one part of the view to the
other -
>>> I guess it should be forcefully updated to make sure the two views are in
sync when
>>> they edit each others models ?
>>>
>>>
> We could add a preference (using dialog settings or IPersistableElement)
> for every editor that has a non-default value for this action. The
> action would be changed using IPartListener interface.
>
I don't understand how having a preference will prevent the synchronization issues
between
the split-view in the VPE editor?
-max
I understood that you were talking about different editors with
different state of the Link action.
As to the split-view, the visual and source part wouldn't be
synchronized automatically when the Link action is disabled.
In that case, the user would use only the source part (it is possible to
disable the visual part in order the user not to use actions...).
The user would manually synchronize these parts by calling Refresh. This
would be used only for editing large files.
For instance, when editing employee.xhtml (attached to
http://jira.jboss.com/jira/browse/JBIDE-675), I have to wait for a few
minutes between keystrokes.
In my opinion, it would be nice to have the following feature:
- disabling the visual part using the Link action
- editing a file in the source editor (fast when the visual part is
inactive)
- clicking Refresh periodically to sync the visual and source part
Snjeza
7:42 a.m.
> I don't understand how having a preference will prevent the
synchronization issues between
> the split-view in the VPE editor?
>
> -max
>
>
I understood that you were talking about different editors with
different state of the Link action.
No, talking about what will/should happen when the linking is disabled and user
edits the source part and then jumps to the visual part...can you reliably force an update
of the visual part to make sure the two are not out of sync to avoid any internal
synchronization issues?
As to the split-view, the visual and source part wouldn't be
synchronized automatically when the Link action is disabled.
So what happens when I jump between them?
In that case, the user would use only the source part (it is possible
to
disable the visual part in order the user not to use actions...).
Ok - so when linking is disabled the visual part will become readonly?
The user would manually synchronize these parts by calling Refresh.
This
would be used only for editing large files.
For instance, when editing employee.xhtml (attached to
http://jira.jboss.com/jira/browse/JBIDE-675), I have to wait for a few
minutes between keystrokes.
yeah thats bad ;(
In my opinion, it would be nice to have the following feature:
- disabling the visual part using the Link action
- editing a file in the source editor (fast when the visual part is
inactive)
- clicking Refresh periodically to sync the visual and source part
I agree having that as an option sounds good.
/max
3 p.m.
Max Rydahl Andersen wrote:
>> I don't understand how having a preference will prevent
the synchronization issues between
>> the split-view in the VPE editor?
>>
>> -max
>>
>>
>>
> I understood that you were talking about different editors with
> different state of the Link action.
>
No, talking about what will/should happen when the linking is disabled and user
edits the source part and then jumps to the visual part...can you reliably force an
update of the visual part to make sure the two are not out of sync to avoid any internal
synchronization issues?
> As to the split-view, the visual and source part wouldn't be
> synchronized automatically when the Link action is disabled.
>
So what happens when I jump between them?
> In that case, the user would use only the source part (it is possible to
> disable the visual part in order the user not to use actions...).
>
Ok - so when linking is disabled the visual part will become readonly?
> The user would manually synchronize these parts by calling Refresh. This
> would be used only for editing large files.
> For instance, when editing employee.xhtml (attached to
> http://jira.jboss.com/jira/browse/JBIDE-675), I have to wait for a few
> minutes between keystrokes.
>
yeah thats bad ;(
> In my opinion, it would be nice to have the following feature:
> - disabling the visual part using the Link action
> - editing a file in the source editor (fast when the visual part is
> inactive)
> - clicking Refresh periodically to sync the visual and source part
>
I agree having that as an option sounds good.
/max
I like the idea of Denis Golovin with two toggle buttons visual and
source on eclipse toolbar. The splitter between source and visual part
can play a role of visual toggle button.
And I suggest to keep only two tabs in our editor the source/visual and
the preview.
/sergey
3:09 p.m.
>
I like the idea of Denis Golovin with two toggle buttons visual and
source on eclipse toolbar. The splitter between source and visual part
can play a role of visual toggle button.
And I suggest to keep only two tabs in our editor the source/visual and
the preview.
yes, I even think Snjezana already got the code for this. Snjezana could you get it in ?
(with proper default colored arrows ;)
/max
4:02 p.m.
Max Rydahl Andersen wrote:
> - lazy Visual Editor update
> The Visual editor is updated on every keystroke. I propose to postpone
> the update for some time. This means - if a user enters a few keys
> quickly, the Visual editor will be updated only once. There is the
> org.eclipse.wst.sse.ui.sourcevalidation extenison point within the
> Webtools project that can be used for adding this feature. It is also
> possible to implement this feature using the code I added when fixing
> http://jira.jboss.com/jira/browse/JBIDE-1479 (we could use 400 ms during
> editing; this is the default value for the sourcevalidation extenison
> point).
>
If we don't have that already (I thought we had) then definitly since I even
did that for my trivial HQL to SQL view and that gave a tremendous speedup (at
least it is perceived to the user as such)
> - adding the Link (Synchronize) action to the Visual editor next to the
> Preferences, Refresh, Page Design Options actions.
> This action would be a check box similar to the "Link with editor" in
> the Package Explorer view. It would be checked/enabled by default. In
> that case, the VPE would behave as it does now. If the user disables the
> action, the VPE wouldn't be updated (VpeController.notifyChanged()
> wouldn't be called). This would be very useful when editing large JSP
> files. The user could always call Refresh (or check Link) to show the
> visual part of the editor.
>
I see what you mean here, and I like the idea but what happens when the user
disabled the synchronization and changes from one part of the view to the other -
I guess it should be forcefully updated to make sure the two views are in sync when
they edit each others models ?
/max
Right now we are thinking about if it possible to use caching to avoid
rebuild children tags when we are editing the parent. If the parent tag
has a lot of children tags rebuilding all of them can take a lot of time.
In my opinion after we have separated source and visual editors to
reduce time to rebuild visual part a user can simply switch to source
tab, and there is no necessity in check box link/unlink to visual editor.
/sergey
8:19 a.m.
Right now we are thinking about if it possible to use caching to
avoid
rebuild children tags when we are editing the parent. If the parent tag
has a lot of children tags rebuilding all of them can take a lot of time.
Sure, but at least waiting a few miliseconds while users are typing in something in the
source editor
would be an easy way of giving better performance - correct?
In my opinion after we have separated source and visual editors to
reduce time to rebuild visual part a user can simply switch to source
tab, and there is no necessity in check box link/unlink to visual editor.
So does this work now ? If I go to the source-only tab will the visual editor stop
listening ?
/max
10:47 a.m.
Max Rydahl Andersen wrote:
> Right now we are thinking about if it possible to use caching to
avoid
> rebuild children tags when we are editing the parent. If the parent tag
> has a lot of children tags rebuilding all of them can take a lot of time.
>
Sure, but at least waiting a few miliseconds while users are typing in something in the
source editor
would be an easy way of giving better performance - correct?
Of course.
> In my opinion after we have separated source and visual editors
to
> reduce time to rebuild visual part a user can simply switch to source
> tab, and there is no necessity in check box link/unlink to visual editor.
>
So does this work now ? If I go to the source-only tab will the visual editor stop
listening ?
It doesn't work in such manner, but we are going to have it. :)
/sergey
/max
1:35 p.m.
Sergey Vasilyev wrote:
Max Rydahl Andersen wrote:
>> Right now we are thinking about if it possible to use caching to avoid
>> rebuild children tags when we are editing the parent. If the parent tag
>> has a lot of children tags rebuilding all of them can take a lot of
>> time.
>>
>
> Sure, but at least waiting a few miliseconds while users are typing
> in something in the source editor
> would be an easy way of giving better performance - correct?
>
>
Of course.
>> In my opinion after we have separated source and visual editors to
>> reduce time to rebuild visual part a user can simply switch to source
>> tab, and there is no necessity in check box link/unlink to visual
>> editor.
>>
>
> So does this work now ? If I go to the source-only tab will the
> visual editor stop listening ?
>
It doesn't work in such manner, but we are going to have it. :)
/sergey
> /max
>
I have tried to edit in the Source tab. The nofitifyChanged method is
called, but it doesn't do anything.
The following is at the beginning of the notifyChangedInUiThread method
if
(!switcher.startActiveEditor(ActiveEditorSwitcher.ACTIVE_EDITOR_SOURCE)) {
return;
}
switcher.startActiveEditor(ActiveEditorSwitcher.ACTIVE_EDITOR_SOURCE)
returns false and this method isn't executed.
Editing in the source tab is fast what was confirmed by the user in
http://jira.jboss.com/jira/browse/JBDS-259 (see Note 2).
However, I still think that Link/Unlink makes sense because switching
requires 2 clicks (switching to the visual part and returning to the
source part). Except that, when using the Link
action, the user can see the source and visual part at the same time.
Switch from the source to the visual part rebuilds dom every time (even
if we didn't edit anything).
I think that the implementation of this feature is very simple.
Snjeza
5:01 p.m.
However, I still think that Link/Unlink makes sense because
switching
requires 2 clicks (switching to the visual part and returning to the
source part). Except that, when using the Link
action, the user can see the source and visual part at the same time.
I buy the 2 click argument. I think we should do it. Adding a "linked editing"
toggle button
in the upper left corner sounds like a small but nice enhancement.
I was thinking we could use the current "refresh" button to avoid adding extra
code but if
I remember correctly that button is still relevant since it forces a full refresh updating
CSS
styles etc. If you have an idea of just combining them would be good.
Switch from the source to the visual part rebuilds dom every time
(even
if we didn't edit anything).
I think that the implementation of this feature is very simple.
Ok, so lets implement the "delay a few miliseconds before update" feature.
Svetlana, please create two seperate jira issues for this then Sergey et.al. can comment
there
if needed.
/max
5:56 p.m.
Snjezana Peco wrote:
Sergey Vasilyev wrote:
> Max Rydahl Andersen wrote:
>>> Right now we are thinking about if it possible to use caching to avoid
>>> rebuild children tags when we are editing the parent. If the parent
>>> tag
>>> has a lot of children tags rebuilding all of them can take a lot of
>>> time.
>>>
>>
>> Sure, but at least waiting a few miliseconds while users are typing
>> in something in the source editor
>> would be an easy way of giving better performance - correct?
>>
>>
> Of course.
>>> In my opinion after we have separated source and visual editors to
>>> reduce time to rebuild visual part a user can simply switch to source
>>> tab, and there is no necessity in check box link/unlink to visual
>>> editor.
>>>
>>
>> So does this work now ? If I go to the source-only tab will the
>> visual editor stop listening ?
>>
> It doesn't work in such manner, but we are going to have it. :)
>
> /sergey
>> /max
>>
>
>
I have tried to edit in the Source tab. The nofitifyChanged method is
called, but it doesn't do anything.
The following is at the beginning of the notifyChangedInUiThread method
if
(!switcher.startActiveEditor(ActiveEditorSwitcher.ACTIVE_EDITOR_SOURCE))
{
return;
}
switcher.startActiveEditor(ActiveEditorSwitcher.ACTIVE_EDITOR_SOURCE)
returns false and this method isn't executed.
Editing in the source tab is fast what was confirmed by the user in
http://jira.jboss.com/jira/browse/JBDS-259 (see Note 2).
However, I still think that Link/Unlink makes sense because switching
requires 2 clicks (switching to the visual part and returning to the
source part).
Snjeza, welcome :)
Lets assign hot key to switch between source/visual and source, that
will be faster then using mouse. The same about Link/Unlink - hot key
would be fine for that.
Regards
Denis.
Except that, when using the Link
action, the user can see the source and visual part at the same time.
Switch from the source to the visual part rebuilds dom every time
(even if we didn't edit anything).
I think that the implementation of this feature is very simple.
Snjeza
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:19 p.m.
Lets assign hot key to switch between source/visual and source, that
will be faster then using mouse. The same about Link/Unlink - hot key
would be fine for that.
Switch between pages is Ctrl+PgUp/PgDown, and we should actually switch the Visual/Source
pages - it would make it more logical too imo.
I'm not sure if we can find any good shortcut for link/unlink since almost every key
is already taken.
But let's get the button first, assigning a shortcut we can do down the road..
/max
12:55 a.m.
I agree with lazy Visual Editor update idea, it should be implemented
some way, for example Swing also does it for painting swing Components.
It looks like now all events are processed in the same thread, where
they were fired.
I have one more idea about VPE layout. I have crazy idea about getting
rid of tabs at all. We have a Source/Visual part that have a split lets
just have button that can hide source part or visual it almost the same
like having source and visual tabs. You'll say, but we have preview tab.
Why we cannot just let user switch visual part from edit mode to preview
mode.
This way it could be any combination of source/visual editing/preview.
All actions to control the editor can be placed to Editor Related
toolbar it will contains:
1. Preview Mode toggle button with two states (preview/visual editing);
2. Show Source with two states (source visible/source invisible)
3. Show Visual (visual visible/visual invisible)
4. Enabling/disabling formatting toolbar
5. Refresh
7. Synchronize
4. Preferences
So the case for those people who dont like wisaul editor at all will simple:
1. Open editor first
2. Unset Show Visual
3. Editor becomes just source editor
For visual editing only hide source
For editing with preview switch preview mode
For asynchronous preview set Synchronize
So if we are generating ides about VPE, I also have some after playing with
http://jira.jboss.com/jira/browse/JBIDE-1304,
http://jira.jboss.com/jira/browse/JBIDE-1600,
http://jira.jboss.com/jira/browse/JBIDE-1227
I just have finished DocBook preview, it is preview because there are
actually some issues in VPE that doesn't allow me to say it is editor.
Short comment how to use it can be found here
http://jira.jboss.com/jira/browse/JBIDE-1304#action_12402618 with
several screen-shots.
What I did:
1. I created plug-in with VPE template (see attachment for
http://jira.jboss.com/jira/browse/JBIDE-1304) that is just a simple
template that cover only DocBook tags I found in
https://svn.jboss.org/repos/jbosstools/trunk/documentation/development/us...
and
https://svn.jboss.org/repos/jbosstools/trunk/documentation/guides/Legacy-...
2. Then I tried to make Visual Editor available in open with menu for
XML files, but there is a simple way to handle it by menu Open
With/Other... .
3. Start JBossTools with attached plug-in
4. Checkout Documentation plug-in from SVN
5. Open separate module mentioned above and see how it looks like.
During my quest I realized there are several problems with VPE:
1. It always handle tags without prefixes as HTML tags
2. all tags without prefix is stored in same hash map in
VpeTemplateManager and there is no way separate templates for html tags
from docbook tags. That means I can use html tags in DocBook XML and it
will work fine and vice versa.
3. It doesn't shows attributes for xml tags because some exceptions
4. There is no way to process <![CDATA[]> blocks
What would be nice to have:
1. There is dialog with settings for unknown tags, it would be nice not
only setup predefined parameters but do something meaningful: show
unknown tag as known html tag
2. It wold be nice to say VPE use this template from eclipse workspace
or local file system or even load all templates from defined location
(related to http://jira.jboss.com/jira/browse/JBIDE-1600)
3. VPE should provide the way to change default template for unknown tags.
4. VPE should allow points to location where to save templates created
by Template Dialog mentioned above.
5. Combination of points 1 and 4 is a fast way to create simple
templates as I did for DocBook.
Regards
Denis
Snjezana Peco wrote:
Hi,
I have two suggestions for improving performance in the VPE editor:
- lazy Visual Editor update
The Visual editor is updated on every keystroke. I propose to postpone
the update for some time. This means - if a user enters a few keys
quickly, the Visual editor will be updated only once. There is the
org.eclipse.wst.sse.ui.sourcevalidation extenison point within the
Webtools project that can be used for adding this feature. It is also
possible to implement this feature using the code I added when fixing
http://jira.jboss.com/jira/browse/JBIDE-1479 (we could use 400 ms
during editing; this is the default value for the sourcevalidation
extenison point).
- adding the Link (Synchronize) action to the Visual editor next to
the Preferences, Refresh, Page Design Options actions.
This action would be a check box similar to the "Link with editor" in
the Package Explorer view. It would be checked/enabled by default. In
that case, the VPE would behave as it does now. If the user disables
the action, the VPE wouldn't be updated (VpeController.notifyChanged()
wouldn't be called). This would be very useful when editing large JSP
files. The user could always call Refresh (or check Link) to show the
visual part of the editor.
These features are easy to implement and don't require a lot of
changes in the code.
Snjeza
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:35 a.m.
I agree with lazy Visual Editor update idea, it should be
implemented
some way, for example Swing also does it for painting swing Components.
It looks like now all events are processed in the same thread, where
they were fired.
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 one more idea about VPE layout. I have crazy idea about
getting
rid of tabs at all. We have a Source/Visual part that have a split lets
just have button that can hide source part or visual it almost the same
like having source and visual tabs. You'll say, but we have preview tab.
Why we cannot just let user switch visual part from edit mode to preview
mode.
At first I liked this idea..but I actually think it has value to have multiple
tabs for things like preview and possible other types of preview, see e.g.
http://www-128.ibm.com/developerworks/opensource/library/os-eclipse-iphon...
where they have different types of preview.
That being said if we had the "hide/show" visual editor then Source/Visual,
Source and Visual could
be collapsed into one - leaving Source/Visual and Preview - but then we should definitly
find a good shortcut for toggling the visual part.
This way it could be any combination of source/visual
editing/preview.
Yes, but sometime collapsing things too much can make users not realize the feature is
there.
All actions to control the editor can be placed to Editor Related
toolbar it will contains:
1. Preview Mode toggle button with two states (preview/visual editing);
2. Show Source with two states (source visible/source invisible)
3. Show Visual (visual visible/visual invisible)
4. Enabling/disabling formatting toolbar
5. Refresh
7. Synchronize
4. Preferences
The problem with this is where should users click if they want the visual editor back ?
That part will disappear when you click hide, how do you get it back ?
Maybe adding a simple toolbar to the editor that has:
1. the "selection bar" (the one that shows where you are in the xml)
2. Toggle for source/visual part (possibly let it be an dropdown button with option of
what to show (Source only, Visual only, Visual/Source)
For asynchronous preview set Synchronize
I don't understand this last option ?
So if we are generating ides about VPE, I also have some after
playing with
http://jira.jboss.com/jira/browse/JBIDE-1304,
http://jira.jboss.com/jira/browse/JBIDE-1600,
http://jira.jboss.com/jira/browse/JBIDE-1227
I just have finished DocBook preview, it is preview because there are
actually some issues in VPE that doesn't allow me to say it is editor.
Short comment how to use it can be found here
http://jira.jboss.com/jira/browse/JBIDE-1304#action_12402618 with
several screen-shots.
Nice! I can use that for my Eclipsecon talk ;)
I think you should put these observations in to a VPE jira and we can take it from there.
/max
During my quest I realized there are several problems with VPE:
1. It always handle tags without prefixes as HTML tags
2. all tags without prefix is stored in same hash map in
VpeTemplateManager and there is no way separate templates for html tags
from docbook tags. That means I can use html tags in DocBook XML and it
will work fine and vice versa.
3. It doesn't shows attributes for xml tags because some exceptions
4. There is no way to process <![CDATA[]> blocks
What would be nice to have:
1. There is dialog with settings for unknown tags, it would be nice not
only setup predefined parameters but do something meaningful: show
unknown tag as known html tag
2. It wold be nice to say VPE use this template from eclipse workspace
or local file system or even load all templates from defined location
(related to http://jira.jboss.com/jira/browse/JBIDE-1600)
3. VPE should provide the way to change default template for unknown tags.
4. VPE should allow points to location where to save templates created
by Template Dialog mentioned above.
5. Combination of points 1 and 4 is a fast way to create simple
templates as I did for DocBook.
Regards
Denis
Snjezana Peco wrote:
> Hi,
>
> I have two suggestions for improving performance in the VPE editor:
>
> - lazy Visual Editor update
> The Visual editor is updated on every keystroke. I propose to postpone
> the update for some time. This means - if a user enters a few keys
> quickly, the Visual editor will be updated only once. There is the
> org.eclipse.wst.sse.ui.sourcevalidation extenison point within the
> Webtools project that can be used for adding this feature. It is also
> possible to implement this feature using the code I added when fixing
> http://jira.jboss.com/jira/browse/JBIDE-1479 (we could use 400 ms
> during editing; this is the default value for the sourcevalidation
> extenison point).
>
> - adding the Link (Synchronize) action to the Visual editor next to
> the Preferences, Refresh, Page Design Options actions.
> This action would be a check box similar to the "Link with editor" in
> the Package Explorer view. It would be checked/enabled by default. In
> that case, the VPE would behave as it does now. If the user disables
> the action, the VPE wouldn't be updated (VpeController.notifyChanged()
> wouldn't be called). This would be very useful when editing large JSP
> files. The user could always call Refresh (or check Link) to show the
> visual part of the editor.
>
> These features are easy to implement and don't require a lot of
> changes in the code.
>
> Snjeza
>
>
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
11:02 a.m.
Actually - wouldn't it be enough with a toggle for what mode to show (e.g. two buttons
- visual and source, and if both is enabled split screen ?)
When is it interesting/relevant to show the VPE when it is not being updated ?
/max
3:17 p.m.
That's what I'm talking about :
2. Show Source with two states (source visible/source invisible)
3. Show Visual (visual visible/visual invisible)
These are toggle buttons, like Synchronize on Package Explorer.
Denis
Max Rydahl Andersen wrote:
Actually - wouldn't it be enough with a toggle for what mode to
show (e.g. two buttons - visual and source, and if both is enabled split screen ?)
When is it interesting/relevant to show the VPE when it is not being updated ?
/max
3:21 p.m.
Snjezana reminded me on how simple this can be done...just have a split pane with two
arrows pointing up/down.
e.g. http://www.ibm.com/developerworks/opensource/library/os-ecvisual/VisEdit.gif
Minimal and functional. (as long as the visual editor will stop receiving updates when it
is hidden.
-max
That's what I'm talking about :
2. Show Source with two states (source visible/source invisible)
3. Show Visual (visual visible/visual invisible)
These are toggle buttons, like Synchronize on Package Explorer.
Denis
Max Rydahl Andersen wrote:
> Actually - wouldn't it be enough with a toggle for what mode to show (e.g. two
buttons - visual and source, and if both is enabled split screen ?)
>
> When is it interesting/relevant to show the VPE when it is not being updated ?
>
> /max
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
12:26 p.m.
Max Rydahl Andersen wrote:
> I agree with lazy Visual Editor update idea, it should be
implemented
> some way, for example Swing also does it for painting swing Components.
> It looks like now all events are processed in the same thread, where
> they were fired.
>
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.
Also i have tried to add some delay after change in source editor before
update visual editor, I have experimented with different delay
intervals, but this doesn't changed the performance situation and
doesn't helped to make vpe more responsible for user.
Other way that can usefull for us to improve performance it's change
event processing in VpeController.notifyChanged, for example
if we add 's' letter to '<te' and get '<tes' first event
what we catch
it's delete event and we removing all child nodes for '<te' tag, than we
catch add and doesn't processing it, and third event is update event which
we catch for parent node of '<tes' and we updating all children nodes
and '<tes' too. Instead of all this for example we can collect all this
events
and in result made only update of '<te' to '<tes', and
doesn't
update parent node and all children nodes.This three modification event
we catch in very short
interval.
Also applying cash for VpeCreation data can improve performance by my
opinion.
> I have one more idea about VPE layout. I have crazy idea about
getting
> rid of tabs at all. We have a Source/Visual part that have a split lets
> just have button that can hide source part or visual it almost the same
> like having source and visual tabs. You'll say, but we have preview tab.
> Why we cannot just let user switch visual part from edit mode to preview
> mode.
>
At first I liked this idea..but I actually think it has value to have multiple
tabs for things like preview and possible other types of preview, see e.g.
http://www-128.ibm.com/developerworks/opensource/library/os-eclipse-iphon...
where they have different types of preview.
That being said if we had the "hide/show" visual editor then Source/Visual,
Source and Visual could
be collapsed into one - leaving Source/Visual and Preview - but then we should definitly
find a good shortcut for toggling the visual part.
> This way it could be any combination of source/visual editing/preview.
>
Yes, but sometime collapsing things too much can make users not realize the feature is
there.
> All actions to control the editor can be placed to Editor Related
> toolbar it will contains:
> 1. Preview Mode toggle button with two states (preview/visual editing);
> 2. Show Source with two states (source visible/source invisible)
> 3. Show Visual (visual visible/visual invisible)
> 4. Enabling/disabling formatting toolbar
> 5. Refresh
> 7. Synchronize
> 4. Preferences
>
The problem with this is where should users click if they want the visual editor back ?
That part will disappear when you click hide, how do you get it back ?
Maybe adding a simple toolbar to the editor that has:
1. the "selection bar" (the one that shows where you are in the xml)
2. Toggle for source/visual part (possibly let it be an dropdown button with option of
what to show (Source only, Visual only, Visual/Source)
> For asynchronous preview set Synchronize
>
I don't understand this last option ?
> So if we are generating ides about VPE, I also have some after playing with
>
> http://jira.jboss.com/jira/browse/JBIDE-1304,
> http://jira.jboss.com/jira/browse/JBIDE-1600,
> http://jira.jboss.com/jira/browse/JBIDE-1227
>
> I just have finished DocBook preview, it is preview because there are
> actually some issues in VPE that doesn't allow me to say it is editor.
> Short comment how to use it can be found here
> http://jira.jboss.com/jira/browse/JBIDE-1304#action_12402618 with
> several screen-shots.
>
Nice! I can use that for my Eclipsecon talk ;)
I think you should put these observations in to a VPE jira and we can take it from
there.
/max
> During my quest I realized there are several problems with VPE:
> 1. It always handle tags without prefixes as HTML tags
> 2. all tags without prefix is stored in same hash map in
> VpeTemplateManager and there is no way separate templates for html tags
> from docbook tags. That means I can use html tags in DocBook XML and it
> will work fine and vice versa.
> 3. It doesn't shows attributes for xml tags because some exceptions
> 4. There is no way to process <![CDATA[]> blocks
>
> What would be nice to have:
> 1. There is dialog with settings for unknown tags, it would be nice not
> only setup predefined parameters but do something meaningful: show
> unknown tag as known html tag
> 2. It wold be nice to say VPE use this template from eclipse workspace
> or local file system or even load all templates from defined location
> (related to http://jira.jboss.com/jira/browse/JBIDE-1600)
> 3. VPE should provide the way to change default template for unknown tags.
> 4. VPE should allow points to location where to save templates created
> by Template Dialog mentioned above.
> 5. Combination of points 1 and 4 is a fast way to create simple
> templates as I did for DocBook.
>
> Regards
> Denis
>
> Snjezana Peco wrote:
>
>> Hi,
>>
>> I have two suggestions for improving performance in the VPE editor:
>>
>> - lazy Visual Editor update
>> The Visual editor is updated on every keystroke. I propose to postpone
>> the update for some time. This means - if a user enters a few keys
>> quickly, the Visual editor will be updated only once. There is the
>> org.eclipse.wst.sse.ui.sourcevalidation extenison point within the
>> Webtools project that can be used for adding this feature. It is also
>> possible to implement this feature using the code I added when fixing
>> http://jira.jboss.com/jira/browse/JBIDE-1479 (we could use 400 ms
>> during editing; this is the default value for the sourcevalidation
>> extenison point).
>>
>> - adding the Link (Synchronize) action to the Visual editor next to
>> the Preferences, Refresh, Page Design Options actions.
>> This action would be a check box similar to the "Link with editor" in
>> the Package Explorer view. It would be checked/enabled by default. In
>> that case, the VPE would behave as it does now. If the user disables
>> the action, the VPE wouldn't be updated (VpeController.notifyChanged()
>> wouldn't be called). This would be very useful when editing large JSP
>> files. The user could always call Refresh (or check Link) to show the
>> visual part of the editor.
>>
>> These features are easy to implement and don't require a lot of
>> changes in the code.
>>
>> Snjeza
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
12:44 p.m.
> 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 ?
Also i have tried to add some delay after change in source editor
before
update visual editor, I have experimented with different delay
intervals, but this doesn't changed the performance situation and
doesn't helped to make vpe more responsible for user.
Well, if you still process all events then sure it will be the same.
The idea is like you describe below to not do an visual page update
until after the user stops typing.
Other way that can usefull for us to improve performance it's
change
event processing in VpeController.notifyChanged, for example
if we add 's' letter to '<te' and get '<tes' first event
what we catch
it's delete event and we removing all child nodes for '<te' tag, than we
catch add and doesn't processing it, and third event is update event which
we catch for parent node of '<tes' and we updating all children nodes
and '<tes' too. Instead of all this for example we can collect all this
events
and in result made only update of '<te' to '<tes', and
doesn't
update parent node and all children nodes.This three modification event
we catch in very short
interval.
-max
12:59 p.m.
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
7:37 p.m.
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....
7:59 p.m.
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
6:04 p.m.
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.
Index:
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe/src/org/jboss/tools/vpe/editor/VpeVisualDomBuilder.java
===================================================================
---
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe/src/org/jboss/tools/vpe/editor/VpeVisualDomBuilder.java (revision
6924)
+++
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe/src/org/jboss/tools/vpe/editor/VpeVisualDomBuilder.java (working
copy)
@@ -71,6 +71,7 @@
import org.jboss.tools.vpe.editor.util.TextUtil;
import org.jboss.tools.vpe.editor.util.VisualDomUtil;
import org.jboss.tools.vpe.editor.util.VpeStyleUtil;
+import org.jboss.tools.vpe.xulrunner.ProxyManager;
import org.jboss.tools.vpe.xulrunner.editor.XulRunnerEditor;
import org.jboss.tools.vpe.xulrunner.editor.XulRunnerVpeUtils;
import org.mozilla.interfaces.nsIDOMAttr;
@@ -848,8 +849,11 @@
nsIDOMNode visualContainer = visualOldNode.getParentNode();
nsIDOMNode visualNextNode = visualOldNode.getNextSibling();
if (visualContainer != null) {
+
+ //jbide-675 non ui thread added by Max Areshkau
+ visualContainer=ProxyManager.createProxyForNode(visualContainer);
visualContainer.removeChild(visualOldNode);
- addNode(sourceNode, visualNextNode, visualContainer);
+ addNode(sourceNode, ProxyManager.createProxyForNode(visualNextNode),
visualContainer);
}
} else {
// Max Areshkau Why we need update parent node when we update text
Index:
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe/src/org/jboss/tools/vpe/editor/VpeController.java
===================================================================
---
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe/src/org/jboss/tools/vpe/editor/VpeController.java (revision
6924)
+++
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe/src/org/jboss/tools/vpe/editor/VpeController.java (working
copy)
@@ -144,6 +144,7 @@
import org.jboss.tools.vpe.selbar.SelectionBar;
import org.jboss.tools.vpe.xulrunner.browser.util.DOMTreeDumper;
import org.jboss.tools.vpe.xulrunner.editor.XulRunnerEditor;
+import org.mozilla.interfaces.nsIComponentManager;
import org.mozilla.interfaces.nsIDOMDocument;
import org.mozilla.interfaces.nsIDOMElement;
import org.mozilla.interfaces.nsIDOMEvent;
@@ -151,8 +152,12 @@
import org.mozilla.interfaces.nsIDOMMouseEvent;
import org.mozilla.interfaces.nsIDOMMutationEvent;
import org.mozilla.interfaces.nsIDOMNode;
+import org.mozilla.interfaces.nsIEventQueue;
+import org.mozilla.interfaces.nsIEventQueueService;
+import org.mozilla.interfaces.nsIProxyObjectManager;
import org.mozilla.interfaces.nsISelection;
import org.mozilla.interfaces.nsISelectionListener;
+import org.mozilla.interfaces.nsIServiceManager;
import org.mozilla.interfaces.nsISupports;
import org.mozilla.xpcom.Mozilla;
import org.w3c.dom.Attr;
@@ -378,7 +383,18 @@
display= PlatformUI.getWorkbench().getDisplay();
if (display != null && (Thread.currentThread() == display.getThread()))
{
- notifyChangedInUiThread(notifier, eventType, feature, oldValue, newValue, pos);
+ Job nonUIJob = new Job("Update Job"){ //$NON-NLS-1$
+
+ @Override
+ protected IStatus run(IProgressMonitor monitor) {
+ synchronized (this) {
+ notifyChangedInUiThread(notifier, eventType, feature, oldValue, newValue, pos);
+ }
+ return Status.OK_STATUS;
+ }};
+ nonUIJob.setPriority(Job.LONG);
+ nonUIJob.schedule();
+// notifyChangedInUiThread(notifier, eventType, feature, oldValue, newValue,
pos);
return;
}
//start job when we modify file in non ui thread
Index:
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/browser/XulRunnerBrowser.java
===================================================================
---
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/browser/XulRunnerBrowser.java (revision
6924)
+++
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/browser/XulRunnerBrowser.java (working
copy)
@@ -93,7 +93,7 @@
webBrowser = (nsIWebBrowser) browser.getWebBrowser();
if (webBrowser == null) {
- throw new XulRunnerException("nsIWebBrowser is not available");
// $NON-NLS-1$
+ throw new XulRunnerException("nsIWebBrowser is not available");
//$NON-NLS-1$
}
setBoolRootPref(PREFERENCE_DISABLEOPENDURINGLOAD, true);
@@ -108,7 +108,7 @@
// nsIWebProgressListener.NS_IWEBPROGRESSLISTENER_IID);
nsIServiceManager serviceManager = mozilla.getServiceManager();
nsIWebProgress webProgress = (nsIWebProgress) serviceManager
- .getServiceByContractID("(a)mozilla.org/docloaderservice;1", //
$NON-NLS-1$
+ .getServiceByContractID("(a)mozilla.org/docloaderservice;1",
//$NON-NLS-1$
nsIWebProgress.NS_IWEBPROGRESS_IID);
webProgress.addProgressListener(this, nsIWebProgress.NOTIFY_ALL);
Index:
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/browser/util/DOMTreeDumper.java
===================================================================
---
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/browser/util/DOMTreeDumper.java (revision
6924)
+++
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/browser/util/DOMTreeDumper.java (working
copy)
@@ -63,6 +63,12 @@
dumpDocument(doc);
}
+ public void dumpNodeToStream(PrintStream ps, nsIDOMNode domNode) {
+
+ this.ps=ps;
+ dumpNode(domNode);
+ }
+
private void dumpDocument(nsIDOMDocument doc) {
if (doc == null) {
return;
Index:
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/editor/XulRunnerEditor.java
===================================================================
---
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/editor/XulRunnerEditor.java (revision
6924)
+++
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/editor/XulRunnerEditor.java (working
copy)
@@ -22,6 +22,7 @@
import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.widgets.Listener;
import org.jboss.tools.vpe.xulrunner.BrowserPlugin;
+import org.jboss.tools.vpe.xulrunner.ProxyManager;
import org.jboss.tools.vpe.xulrunner.XPCOM;
import org.jboss.tools.vpe.xulrunner.XulRunnerException;
import org.jboss.tools.vpe.xulrunner.browser.XulRunnerBrowser;
@@ -392,7 +393,9 @@
nsIServiceManager serviceManager = Mozilla.getInstance().getServiceManager();
iFlasher = (inIFlasher)
serviceManager.getServiceByContractID(XPCOM.IN_FLASHER_CONTRACTID,
inIFlasher.INIFLASHER_IID);
iFlasher.setThickness(2);
+// iFlasher = ProxyManager.createProxyForFlasher(iFlasher);
}
+ iFlasher = ProxyManager.createProxyForFlasher(iFlasher);
return iFlasher;
}
Index:
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/ProxyManager.java
===================================================================
---
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/ProxyManager.java (revision
0)
+++
/Users/mareshkau/develop/rhds/normal_update/org.jboss.tools.vpe.xulrunner/src/org/jboss/tools/vpe/xulrunner/ProxyManager.java (revision
0)
@@ -0,0 +1,90 @@
+/*******************************************************************************
+* Copyright (c) 2007 Red Hat, Inc.
+* Distributed under license by Red Hat, Inc. All rights reserved.
+* This program is made available under the terms of the
+* Eclipse Public License v1.0 which accompanies this distribution,
+* and is available at http://www.eclipse.org/legal/epl-v10.html
+*
+* Contributors:
+* Red Hat, Inc. - initial API and implementation
+******************************************************************************/
+package org.jboss.tools.vpe.xulrunner;
+
+import org.mozilla.interfaces.inIFlasher;
+import org.mozilla.interfaces.nsIComponentManager;
+import org.mozilla.interfaces.nsIDOMElement;
+import org.mozilla.interfaces.nsIDOMNode;
+import org.mozilla.interfaces.nsIEventQueue;
+import org.mozilla.interfaces.nsIEventQueueService;
+import org.mozilla.interfaces.nsIProxyObjectManager;
+import org.mozilla.interfaces.nsIServiceManager;
+import org.mozilla.xpcom.Mozilla;
+
+/**
+ * @author mareshkau
+ * We can access from mozilla DOM only from proxy in non ui threads
+ */
+public class ProxyManager {
+
+ private static nsIProxyObjectManager proxyObjectManager;
+
+ private static nsIEventQueue eventQueue;
+
+ /**
+ * Creates a proxy for node
+ * @param proxy for nodes
+ * @return
+ */
+ public static nsIDOMNode createProxyForNode(nsIDOMNode node) {
+
+ nsIDOMNode proxyNode =null;
+ proxyNode = (nsIDOMNode)getProxyObjectManager().getProxyForObject(getEventQueue(),
nsIDOMNode.NS_IDOMNODE_IID,
+ node, nsIProxyObjectManager.INVOKE_SYNC);
+ return proxyNode;
+ }
+ /**
+ *
+ * @param element
+ * @return proxy for element
+ */
+ public static nsIDOMElement createProxyForElement(nsIDOMElement element) {
+
+ nsIDOMElement proxyElement =null;
+ proxyElement =
(nsIDOMElement)getProxyObjectManager().getProxyForObject(getEventQueue(),
nsIDOMElement.NS_IDOMELEMENT_IID,
+ element, nsIProxyObjectManager.INVOKE_SYNC);
+ return proxyElement;
+ }
+ /**
+ *
+ * @param element
+ * @return proxy for element
+ */
+ public static inIFlasher createProxyForFlasher(inIFlasher flasher) {
+
+ inIFlasher proxyFlasher =null;
+ proxyFlasher = (inIFlasher)getProxyObjectManager().getProxyForObject(getEventQueue(),
inIFlasher.INIFLASHER_IID,
+ flasher, nsIProxyObjectManager.INVOKE_ASYNC);
+ return proxyFlasher;
+ }
+ /**
+ * @return the proxyObjectManager
+ */
+ private static nsIProxyObjectManager getProxyObjectManager() {
+ if(proxyObjectManager==null) {
+ nsIComponentManager componentManager = Mozilla.getInstance().getComponentManager();
+ proxyObjectManager =
(nsIProxyObjectManager)componentManager.createInstanceByContractID("(a)mozilla.org/xpcomproxy;1",null,nsIProxyObjectManager.NS_IPROXYOBJECTMANAGER_IID);
//$NON-NLS-1$
+ }
+ return proxyObjectManager;
+ }
+ /**
+ * @return the eventQueue
+ */
+ 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;
+ }
+}
7:17 p.m.
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.
7:36 p.m.
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("(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.
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_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.
>
>
3:14 p.m.
It is already there
http://jira.jboss.com/jira/secure/attachment/12318848/org.jboss.tools.vpe...
Denis
Max Rydahl Andersen wrote:
Nice! I can use that for my Eclipsecon talk ;)
I think you should put these observations in to a VPE jira and we can take it from
there.
/max
3:22 p.m.
I was talking about the bullet points on what is missing/bad in VPE.
-max
It is already there
http://jira.jboss.com/jira/secure/attachment/12318848/org.jboss.tools.vpe...
Denis
Max Rydahl Andersen wrote:
>
> Nice! I can use that for my Eclipsecon talk ;)
>
> I think you should put these observations in to a VPE jira and we can take it from
there.
>
> /max
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
5869
days inactive
5890
days old
jbosstools-dev@lists.jboss.org
30 comments
5 participants
participants (5)
-
Denis Golovin -
Max Areshkau -
Max Rydahl Andersen -
Sergey Vasilyev -
Snjezana Peco