Community
Participate
Working Groups
We should check if the way styles work today is really good or if there is room for improvement. Especially the need for setting a specific value to null before the stly value is used by the framework is questionable
Would like to target for Juno. Requested by AiE (SH) and others in the community (see related Bugzillas)
An alternative implementation I could imagine would be not to set any default values at metamodel level (leaving null there) and defining the default in the framework. That would ease the use of themes and probably would make it clearer for the user of themes what he needs to do.
Your last suggestion sounds most reasonable for me. That way the "visual appearance" for objects created by the factory methods would be the same as of today, but the users won't be confused by style attributes set during creation which may collide with their own styles.
you can create a fallback style to use if style is null and not set any valaue in metamodel as in comment 2 or use a framework style and set only that style in metamodel
(In reply to comment #4) > you can create a fallback style to use if style is null > and not set any valaue in metamodel as in comment 2 > or use a framework style and set only that style in metamodel That would be another idea. Thanks for the input! But that would mean that every GA needs a style, wouldn't it?
(In reply to comment #5) > That would be another idea. Thanks for the input! > But that would mean that every GA needs a style, wouldn't it? I suppose every GA has already a style. style is a property of GA
(In reply to comment #6) > (In reply to comment #5) > I suppose every GA has already a style. > style is a property of GA It can have one. As of today for most GAs the property is simply null.
(In reply to comment #5) > That would be another idea. Thanks for the input! > But that would mean that every GA needs a style, wouldn't it? I suppose every GA has already a style. style is a property of GA (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > I suppose every GA has already a style. > > style is a property of GA > > It can have one. As of today for most GAs the property is simply null. I propose to set a default style in place of multiple default value for other property
another solution is to get style from container if style is missing and set a style for diagram if possible
We have had an intensive discussion about this problem. We would not reset the default values from the metamodel, because diagrams from existing tools would have another appearance. We decided not to implement a default style, because we found no solution how to persist it without having the necessity to build a migration tool for existing diagrams, and we found a better, more coherent solution. Besides the old create-methods there are now corresponding createPlain-methods, which are creating "naked" graphics algorithms without style attributes, and a createPlainStyle method without default values. Using these new methods, makes it more transparent when working with styles, and very explicit in coding, which style attributes are set. The chapter about styles in the tutorial will be adjusted accordingly. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=357922.
Bookkeeping: Set target release
Part of Graphiti 0.9.0 (Eclipse Juno)
