Hi,
I’ve been thinking a little bit more about this, and you probably don’t need to wait for the actual
EditPart refresh operations. All you need is to detect this “refresh request” (not actual refresh operation), and poll the isCanonical() property again.
We have such a mechanism in the (full) Refresh action (which also resets the stylesheets), but not
for the simple refresh request. So the idea would be to extend this:
org.eclipse.papyrus.infra.gmfdiag.common.helper.DiagramHelper.refreshDiagrams()
to be able to register refresh participants
Would this work in your case?
Camille
Hi Christian,
Ø
Why is the diagram refresh run asynchronously by the CSSEngine?
Like the ModelExplorer refresh, the CSS Refresh is executed many times (currently, after any change
in the Diagram, or in an Element displayed in the diagram). Using synchronous refreshes would have catastrophic performances, similar to what we experienced with Model Explorer. So we now have an asynchronous refresh strategy:
-
When a modification in the diagram is detected, record that a refresh is needed
-
Schedule a refresh action
-
If additional refresh requests are received before the refresh action starts, ignore them
-
If additional refresh requests are received during or after the refresh action, schedule another refresh action
It is especially important for batch modifications, affecting several elements, and I suspect it
is not only related to modifications in the Style properties view. For example, if you want all Concrete classes to be synchronized, and you select 10 classes and change their isAbstract property, you will have (at least) 10 refresh requests. Executing them
synchronously would trigger a ~100ms refresh operation for each selected class. Since the refresh is currently not scoped (a change on a single graphical element triggers a refresh on the complete diagram, because we currently are not able to analyze the CSS
Rules to find all impacts a change can have on other element’s styles)
I’m not sure how this can be solved. Interesting issue :)
Camille
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : vendredi 6 mars 2015 03:52
À : Papyrus Project list
Objet : [mdt-papyrus.dev] CSS diagram refresh interaction with CanonicalEditPolicy
Hi, Team,
I have a small problem with the implementation of diagram refresh when CSS styles are changed (in particular, adding a stylesheet to a diagram or adding a style class to a view). The problem is that the refresh is
performed asynchronously. Consequently, the CanonicalEditPolicy will do its refresh (creating child views and connections) in a non-undoable
context (an unprotected write transaction).
If, instead, the refresh were done synchronously in the context of the command execution that added the stylesheet or style class, then the
CanonicalEditPolicy would take advantage of that transaction and let its changes be recorded for undo/redo.
Why is the diagram refresh run asynchronously by the CSSEngine?
Ordinarily, the unprotected nature of canonical changes isn’t a problem because undoing and redoing edits in the semantic model will be detected by the
CanonicalEditPolicy and it will make the corresponding changes in the diagram. However, in this case, there are some non-trivial problems:
-
undo the CSS change leaves possibly very significant updates to the diagram intact,
but it undoes the activation of the CanonicalEditPolicy
-
subsequent undo of creation of semantic elements that were shown in the diagram by
CanonicalEditPolicy will
not delete views created by CanonicalEditPolicy because that edit policy is no longer active
-
the end result is that we can get stale views (circle-X or worse) in the diagrams
Any suggestions how I can resolve this problem? Would it be safe to make the CSS-triggered diagram refresh synchronous?
Thanks,
Christian
