Re: [mdt-papyrus.dev] [PROVENANCE INTERNET] Re: CSS diagram refresh inte

["Christian W. Damus" <give.a.damus@xxxxxxxxx>]

Thanks, Camille,

I think something like what you suggest will have to work.  :-)

It should be straightforward to determine efficiently whether the activation of CanonicalEditPolicy needs to change (either on or off) and, if so, to do the canonical refresh on the spot.

Going all-out with refresh extensible refresh participants may be a bit heavy-weight on performance.  I have a core interface for canonical concerns that should suffice.  We shall see.

Cheers,

Christian

On Fri, Mar 6, 2015 at 5:14 AM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

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

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille
Envoyé : vendredi 6 mars 2015 10:28
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] CSS diagram refresh interactionwithCanonicalEditPolicy

 

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