Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Viewpoint configurations and Default Styles in the Diagrams

Hi, Camille,

Thanks for your replies.

I have got inference of specific styles from CSS attributes working, as demonstrated with a new ‘canonical’ style attribute here:

    http://youtu.be/cfoQQKPlsxw

As described in Bug 433206 [1], I have taken a similar approach to the support for NamedStyles to infer standard styles that define only a single attribute (such as CanonicalStyle with its ‘canonical’ attribute) from correspondingly named CSS attributes.

    Hopefully nobody is using a ‘canonical’ BooleanValueStyle for their own purposes!

This seems to be working.  I think CSS should be the preferred way to implement default canonical synchronization in diagrams.  Accordingly, I would suggest that the Viewpoint’s control of default styles (whether canonical or any other) should be implemented by CSS.  That puts it out of the scope of the Diagram Synchronization feature, being a more generic problem with (I anticipate) a suitably generic solution.

What do you think?

Cheers,

Christian

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=433206#c4




On Thu, Feb 26, 2015 at 12:14 PM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

Hi Christian,

 

I need to think more about the implications of each option, but I can at least give a short answer for the CSS Stylesheets:

 

Ø  But can CSS handle the case where the Style doesn’t actually exist?

 

Only for NamedStyles, i.e. custom styles (Which we use a lot in Mars). When you call View#getNamedStyle(name, type), the CSS implementation is able to instantiate a transient NamedStyle on-the-fly if it doesn’t exist. However, in this case, if you want to manipulate the existing CanonicalStyle, this doesn’t apply.

 

Regarding the properties view, it is however possible to implement a ModelElement which creates Styles on-the-fly when a user tries to change its value. I’m sure we’re already doing that somewhere (Maybe for NamedStyles; I don’t remember).

 

Ø  on opening a diagram that has default styles defined in the viewpoint configuration, we could quietly add all of the default styles. If the user saves the diagram, then these defaults are made persistent. But this has scary team implications

 

For the style-driven Stereotypes/Stereotype Properties, we’re considering a mechanism to instantiate and serialize parts of the Notation model on the fly (Only when the values change to non-default). Maybe we could use something similar

 

Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : jeudi 26 février 2015 17:46
À : Papyrus Project list
Objet : [mdt-papyrus.dev] Viewpoint configurations and Default Styles in the Diagrams

 

Hi, Team,

For the diagram synchronization feature, I am basically elaborating the GMF notion of a “canonical” view. GMF expresses this as a style (named Canonical, of course) having a single boolean attribute indicating whether canonical-ness is on. I would like to use this style also to control the enablement of model-view synchronization in Papyrus diagrams because, well, that’s what the style is for and other GMF-aware tools expect it to have this meaning.

So, the problem I have is that the Canonical style is not actually installed on any compartments in our Papyrus diagrams[1], so it doesn’t appear in the Properties view for users to control it. It also isn’t then available for our synchronizing edit policy to query, and we want canonical-ness to be off by default.

The Viewpoints configuration model looks like it would be a good place to define rules for default canonical style enablement: every diagram references a configuration that constrains it. However, this configuration model does not (yet) provide any constraints on the notation. It provides for constraints on the model’s semantic content, including automatic creation of required model elements, but I don’t see that there is any provision for similar constraints on the notation.

Am I just missing something? Are the different kinds of Rules in the configuration model applicable to the notation, too? If so, how?

I’d like the viewpoint configuration for a diagram to be able to specify

  • which notation views should have which styles installed by default

    • for default styles, default attribute values as appropriate. Essentially, style prototypes

  • style constraints for notation views

    • for any style, whether it is required, permitted, or forbidden. The Rule::permit attribute in the configuration model doesn’t cover the “required” case. But in any case, the Papyrus tooling doesn’t provide users a means to add new styles to notation views, so it’s rather a moot point so far

Who is the prime for the Viewpoints configuration model, whom I should contact for reviews and discussion?

Furthermore, defining rules in the viewpoint configuration is good insofar as it goes, but it doesn’t cover diagrams that already existed before the configuration was updated. There could be at least three ways to handle extant diagrams:

  • consider default styles as implicitly applied even where they don’t exist. This is problematic for several reasons: how to present an implicit style in the Properties view, how should code that is unaware of viewpoint configurations learn about implicit styles, and how to distinguish this from the case where a user explicitly deleted a default style?

  • on opening a diagram that has default styles defined in the viewpoint configuration, we could quietly add all of the default styles. If the user saves the diagram, then these defaults are made persistent. But this has scary team implications

  • only support default styles via CSS stylesheets. Currently, the styles in our diagrams can delegate to CSS for line styles, gradients, etc. But can CSS handle the case where the Style doesn’t actually exist? (the notation view has no style instance, so there’s nothing that would delegate to CSS)

Or, maybe I'm barking up the wrong tree?

Thanks in advance for your comments.

Christian

------

  1. the Compartment style is a kind of Canonical but I don’t know that Papyrus uses it, either



Back to the top