Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Changing shape on property change
Changing shape on property change [message #176791] Wed, 12 March 2008 06:53 Go to next message
Eclipse User
Originally posted by: nico.lammers.gmail.com

I've searched a bit on the newsgroups, but I couldn't really find an
answer to this:

I have a property that describes the 'type' of the shape. Depending on
the value of the property (set in the propertysheet OR programmatically)
the shape's background color should change.

I want to avoid adding things to generated code as much as possible.. I
feel I can do this with an EditPolicy extension, but I'm not sure.

Regards,
Nico Lammers
Re: Changing shape on property change [message #176899 is a reply to message #176791] Wed, 12 March 2008 11:05 Go to previous messageGo to next message
Boris Blajer is currently offline Boris Blajer
Messages: 217
Registered: July 2009
Senior Member
Hi Nico,

If the type<-->color mapping is static (and the types are predefined),
you may define a separate NodeMapping for each value of type. This may
be a bit cumbersome if there are many types, but you won't have to add a
single line of code manually :).

Best regards,
Boris

Nico Lammers wrote:
> I've searched a bit on the newsgroups, but I couldn't really find an
> answer to this:
>
> I have a property that describes the 'type' of the shape. Depending on
> the value of the property (set in the propertysheet OR programmatically)
> the shape's background color should change.
>
> I want to avoid adding things to generated code as much as possible.. I
> feel I can do this with an EditPolicy extension, but I'm not sure.
>
> Regards,
> Nico Lammers
Re: Changing shape on property change [message #177156 is a reply to message #176899] Thu, 13 March 2008 11:25 Go to previous messageGo to next message
Eclipse User
Originally posted by: nico.lammers.gmail.com

Hmm, I'm not sure what you mean..

Basically I have a shape.. that shape has a property, which is an
enumeration.

i.e. if the enumeration was OwnerNames, the shape should be blue when
'John' is selected, but red when 'Peter' is selected.

I managed to do something with handleNotificationEvent in a custom
CanonicalEditPolicy though, now to set it at creation time :-)


Boris Blajer wrote:
> Hi Nico,
>
> If the type<-->color mapping is static (and the types are predefined),
> you may define a separate NodeMapping for each value of type. This may
> be a bit cumbersome if there are many types, but you won't have to add a
> single line of code manually :).
>
> Best regards,
> Boris
>
> Nico Lammers wrote:
>> I've searched a bit on the newsgroups, but I couldn't really find an
>> answer to this:
>>
>> I have a property that describes the 'type' of the shape. Depending on
>> the value of the property (set in the propertysheet OR
>> programmatically) the shape's background color should change.
>>
>> I want to avoid adding things to generated code as much as possible..
>> I feel I can do this with an EditPolicy extension, but I'm not sure.
>>
>> Regards,
>> Nico Lammers
Re: Changing shape on property change [message #177164 is a reply to message #177156] Thu, 13 March 2008 12:30 Go to previous messageGo to next message
Boris Blajer is currently offline Boris Blajer
Messages: 217
Registered: July 2009
Senior Member
Hi Nico,

My suggestion was to create distinct NodeMappings for each of the values
in the enumeration, each with a feature sequence initializer and a
constraint. Something similar has been implemented for link mappings
representing relationships of different kinds in the mindmap sample. In
your example, there would be two (more if there's more people in the
enum) shapes with different colors declared in the gmfgraph, two
NodeMappings in the gmfmap (each will reference the same underlying
model element, define a FSInitializer, a specialization constraint and
they will reference the shapes from the gmfgraph model with their
respective color).

The main advantage of this approach is that you only modify gmf models,
not the generated code; the gmf model persists the knowledge about the
colors that represent each of the enumerated value.
The main disadvantage is that you end up with several edit part classes
which are almost identical (but after all, probably once they are
separated, they may start getting different behavior other than just
color?) The performance may slightly be affected, too: using ocl engine
to read the value of a single attribute seems suboptimal in terms of
performance.

Best regards,
Boris

Nico Lammers wrote:
>
> Hmm, I'm not sure what you mean..
>
> Basically I have a shape.. that shape has a property, which is an
> enumeration.
>
> i.e. if the enumeration was OwnerNames, the shape should be blue when
> 'John' is selected, but red when 'Peter' is selected.
>
> I managed to do something with handleNotificationEvent in a custom
> CanonicalEditPolicy though, now to set it at creation time :-)
>
>
> Boris Blajer wrote:
>> Hi Nico,
>>
>> If the type<-->color mapping is static (and the types are predefined),
>> you may define a separate NodeMapping for each value of type. This may
>> be a bit cumbersome if there are many types, but you won't have to add
>> a single line of code manually :).
>>
>> Best regards,
>> Boris
>>
>> Nico Lammers wrote:
>>> I've searched a bit on the newsgroups, but I couldn't really find an
>>> answer to this:
>>>
>>> I have a property that describes the 'type' of the shape. Depending
>>> on the value of the property (set in the propertysheet OR
>>> programmatically) the shape's background color should change.
>>>
>>> I want to avoid adding things to generated code as much as possible..
>>> I feel I can do this with an EditPolicy extension, but I'm not sure.
>>>
>>> Regards,
>>> Nico Lammers
Re: Changing shape on property change [message #177186 is a reply to message #177156] Thu, 13 March 2008 12:38 Go to previous messageGo to next message
Kristian O'Connor is currently offline Kristian O'Connor
Messages: 29
Registered: July 2009
Junior Member
For creation time

use the XXXEditHelper...
protected ICommand getConfigureCommand(ConfigureRequest req)

{

return new ConfigureXXXCommand(req);

}

;o) I think.

Obviously XXX is the name of your class and ConfigureXXXCommand needs to
extend
org.eclipse.gmf.runtime.emf.type.core.commands.ConfigureElem entCommand

Hope that helps.

Laters
Kristian.


"Nico Lammers" <nico.lammers@gmail.com> wrote in message
news:frbh0s$nu2$1@build.eclipse.org...
>
> Hmm, I'm not sure what you mean..
>
> Basically I have a shape.. that shape has a property, which is an
> enumeration.
>
> i.e. if the enumeration was OwnerNames, the shape should be blue when
> 'John' is selected, but red when 'Peter' is selected.
>
> I managed to do something with handleNotificationEvent in a custom
> CanonicalEditPolicy though, now to set it at creation time :-)
>
>
> Boris Blajer wrote:
>> Hi Nico,
>>
>> If the type<-->color mapping is static (and the types are predefined),
>> you may define a separate NodeMapping for each value of type. This may be
>> a bit cumbersome if there are many types, but you won't have to add a
>> single line of code manually :).
>>
>> Best regards,
>> Boris
>>
>> Nico Lammers wrote:
>>> I've searched a bit on the newsgroups, but I couldn't really find an
>>> answer to this:
>>>
>>> I have a property that describes the 'type' of the shape. Depending on
>>> the value of the property (set in the propertysheet OR programmatically)
>>> the shape's background color should change.
>>>
>>> I want to avoid adding things to generated code as much as possible.. I
>>> feel I can do this with an EditPolicy extension, but I'm not sure.
>>>
>>> Regards,
>>> Nico Lammers
Re: Changing shape on property change [message #177309 is a reply to message #177164] Fri, 14 March 2008 06:43 Go to previous messageGo to next message
Eclipse User
Originally posted by: nico.lammers.gmail.com

Okay, this appears to work, but there's one problem with it; when I
change the 'ownerName' property in the PropertySheet, the other color
will only be shown after I refresh the diagram.. that's not really what
I want.. :| Do you have any thoughts on this?

Boris Blajer wrote:
> Hi Nico,
>
> My suggestion was to create distinct NodeMappings for each of the values
> in the enumeration, each with a feature sequence initializer and a
> constraint. Something similar has been implemented for link mappings
> representing relationships of different kinds in the mindmap sample. In
> your example, there would be two (more if there's more people in the
> enum) shapes with different colors declared in the gmfgraph, two
> NodeMappings in the gmfmap (each will reference the same underlying
> model element, define a FSInitializer, a specialization constraint and
> they will reference the shapes from the gmfgraph model with their
> respective color).
>
> The main advantage of this approach is that you only modify gmf models,
> not the generated code; the gmf model persists the knowledge about the
> colors that represent each of the enumerated value.
> The main disadvantage is that you end up with several edit part classes
> which are almost identical (but after all, probably once they are
> separated, they may start getting different behavior other than just
> color?) The performance may slightly be affected, too: using ocl engine
> to read the value of a single attribute seems suboptimal in terms of
> performance.
>
> Best regards,
> Boris
>
> Nico Lammers wrote:
>>
>> Hmm, I'm not sure what you mean..
>>
>> Basically I have a shape.. that shape has a property, which is an
>> enumeration.
>>
>> i.e. if the enumeration was OwnerNames, the shape should be blue when
>> 'John' is selected, but red when 'Peter' is selected.
>>
>> I managed to do something with handleNotificationEvent in a custom
>> CanonicalEditPolicy though, now to set it at creation time :-)
>>
>>
>> Boris Blajer wrote:
>>> Hi Nico,
>>>
>>> If the type<-->color mapping is static (and the types are
>>> predefined), you may define a separate NodeMapping for each value of
>>> type. This may be a bit cumbersome if there are many types, but you
>>> won't have to add a single line of code manually :).
>>>
>>> Best regards,
>>> Boris
>>>
>>> Nico Lammers wrote:
>>>> I've searched a bit on the newsgroups, but I couldn't really find an
>>>> answer to this:
>>>>
>>>> I have a property that describes the 'type' of the shape. Depending
>>>> on the value of the property (set in the propertysheet OR
>>>> programmatically) the shape's background color should change.
>>>>
>>>> I want to avoid adding things to generated code as much as
>>>> possible.. I feel I can do this with an EditPolicy extension, but
>>>> I'm not sure.
>>>>
>>>> Regards,
>>>> Nico Lammers
Re: Changing shape on property change [message #177415 is a reply to message #177309] Fri, 14 March 2008 12:16 Go to previous messageGo to next message
Boris Blajer is currently offline Boris Blajer
Messages: 217
Registered: July 2009
Senior Member
Hi Nico,

This seems like a bug. I believe it used to be handled correctly some
time ago. I'm sorry my suggestion was misleading.

Best regards,
Boris


Nico Lammers wrote:
> Okay, this appears to work, but there's one problem with it; when I
> change the 'ownerName' property in the PropertySheet, the other color
> will only be shown after I refresh the diagram.. that's not really what
> I want.. :| Do you have any thoughts on this?
>
> Boris Blajer wrote:
>> Hi Nico,
>>
>> My suggestion was to create distinct NodeMappings for each of the
>> values in the enumeration, each with a feature sequence initializer
>> and a constraint. Something similar has been implemented for link
>> mappings representing relationships of different kinds in the mindmap
>> sample. In your example, there would be two (more if there's more
>> people in the enum) shapes with different colors declared in the
>> gmfgraph, two NodeMappings in the gmfmap (each will reference the same
>> underlying model element, define a FSInitializer, a specialization
>> constraint and they will reference the shapes from the gmfgraph model
>> with their respective color).
>>
>> The main advantage of this approach is that you only modify gmf
>> models, not the generated code; the gmf model persists the knowledge
>> about the colors that represent each of the enumerated value.
>> The main disadvantage is that you end up with several edit part
>> classes which are almost identical (but after all, probably once they
>> are separated, they may start getting different behavior other than
>> just color?) The performance may slightly be affected, too: using ocl
>> engine to read the value of a single attribute seems suboptimal in
>> terms of performance.
>>
>> Best regards,
>> Boris
>>
>> Nico Lammers wrote:
>>>
>>> Hmm, I'm not sure what you mean..
>>>
>>> Basically I have a shape.. that shape has a property, which is an
>>> enumeration.
>>>
>>> i.e. if the enumeration was OwnerNames, the shape should be blue when
>>> 'John' is selected, but red when 'Peter' is selected.
>>>
>>> I managed to do something with handleNotificationEvent in a custom
>>> CanonicalEditPolicy though, now to set it at creation time :-)
>>>
>>>
>>> Boris Blajer wrote:
>>>> Hi Nico,
>>>>
>>>> If the type<-->color mapping is static (and the types are
>>>> predefined), you may define a separate NodeMapping for each value of
>>>> type. This may be a bit cumbersome if there are many types, but you
>>>> won't have to add a single line of code manually :).
>>>>
>>>> Best regards,
>>>> Boris
>>>>
>>>> Nico Lammers wrote:
>>>>> I've searched a bit on the newsgroups, but I couldn't really find
>>>>> an answer to this:
>>>>>
>>>>> I have a property that describes the 'type' of the shape. Depending
>>>>> on the value of the property (set in the propertysheet OR
>>>>> programmatically) the shape's background color should change.
>>>>>
>>>>> I want to avoid adding things to generated code as much as
>>>>> possible.. I feel I can do this with an EditPolicy extension, but
>>>>> I'm not sure.
>>>>>
>>>>> Regards,
>>>>> Nico Lammers
Re: Changing shape on property change [message #177603 is a reply to message #177415] Mon, 17 March 2008 06:45 Go to previous messageGo to next message
Eclipse User
Originally posted by: nico.lammers.gmail.com

Don't worry about it :)

I seem to have find a runtime solution using the editpartProvider.
I can use this to extend my existing EditPart and make the needed
changes by doing some constructor magic and overriding the
handleNotificationEvent method.

Thanks for the help :)

Boris Blajer wrote:
> Hi Nico,
>
> This seems like a bug. I believe it used to be handled correctly some
> time ago. I'm sorry my suggestion was misleading.
>
> Best regards,
> Boris
>
>
> Nico Lammers wrote:
>> Okay, this appears to work, but there's one problem with it; when I
>> change the 'ownerName' property in the PropertySheet, the other color
>> will only be shown after I refresh the diagram.. that's not really
>> what I want.. :| Do you have any thoughts on this?
>>
>> Boris Blajer wrote:
>>> Hi Nico,
>>>
>>> My suggestion was to create distinct NodeMappings for each of the
>>> values in the enumeration, each with a feature sequence initializer
>>> and a constraint. Something similar has been implemented for link
>>> mappings representing relationships of different kinds in the mindmap
>>> sample. In your example, there would be two (more if there's more
>>> people in the enum) shapes with different colors declared in the
>>> gmfgraph, two NodeMappings in the gmfmap (each will reference the
>>> same underlying model element, define a FSInitializer, a
>>> specialization constraint and they will reference the shapes from the
>>> gmfgraph model with their respective color).
>>>
>>> The main advantage of this approach is that you only modify gmf
>>> models, not the generated code; the gmf model persists the knowledge
>>> about the colors that represent each of the enumerated value.
>>> The main disadvantage is that you end up with several edit part
>>> classes which are almost identical (but after all, probably once they
>>> are separated, they may start getting different behavior other than
>>> just color?) The performance may slightly be affected, too: using ocl
>>> engine to read the value of a single attribute seems suboptimal in
>>> terms of performance.
>>>
>>> Best regards,
>>> Boris
>>>
>>> Nico Lammers wrote:
>>>>
>>>> Hmm, I'm not sure what you mean..
>>>>
>>>> Basically I have a shape.. that shape has a property, which is an
>>>> enumeration.
>>>>
>>>> i.e. if the enumeration was OwnerNames, the shape should be blue
>>>> when 'John' is selected, but red when 'Peter' is selected.
>>>>
>>>> I managed to do something with handleNotificationEvent in a custom
>>>> CanonicalEditPolicy though, now to set it at creation time :-)
>>>>
>>>>
>>>> Boris Blajer wrote:
>>>>> Hi Nico,
>>>>>
>>>>> If the type<-->color mapping is static (and the types are
>>>>> predefined), you may define a separate NodeMapping for each value
>>>>> of type. This may be a bit cumbersome if there are many types, but
>>>>> you won't have to add a single line of code manually :).
>>>>>
>>>>> Best regards,
>>>>> Boris
>>>>>
>>>>> Nico Lammers wrote:
>>>>>> I've searched a bit on the newsgroups, but I couldn't really find
>>>>>> an answer to this:
>>>>>>
>>>>>> I have a property that describes the 'type' of the shape.
>>>>>> Depending on the value of the property (set in the propertysheet
>>>>>> OR programmatically) the shape's background color should change.
>>>>>>
>>>>>> I want to avoid adding things to generated code as much as
>>>>>> possible.. I feel I can do this with an EditPolicy extension, but
>>>>>> I'm not sure.
>>>>>>
>>>>>> Regards,
>>>>>> Nico Lammers
Re: Changing shape on property change [message #678812 is a reply to message #177186] Thu, 09 June 2011 11:30 Go to previous messageGo to next message
vincent988923 is currently offline vincent988923
Messages: 29
Registered: June 2011
Junior Member
Hi, I have same problem right now. After see all the reply, I still don't know how to deal with it. Could you please tell me how to do it in detail. I'm a brand new GMFer.
Sad

Thank you very much

Vincent
Re: Changing shape on property change [message #686093 is a reply to message #678812] Tue, 21 June 2011 12:58 Go to previous messageGo to next message
Vick  is currently offline Vick
Messages: 1
Registered: June 2011
Junior Member
I was trying to do the same thing and after fiddling with the OCL approach I came across the decorator service (see eclipse help and search for decorator service as this thing won't let me post the link cause I'm wet behind the ears per it's standard)

Works very nicely however I've run into a layering issue where the image doesn't behave as nicely as the one inside the node itself. By that I mean that it appears to be in the foreground in all cases (cutting links, etc) as opposed to blending.
Re: Changing shape on property change [message #937720 is a reply to message #177164] Tue, 09 October 2012 03:58 Go to previous messageGo to next message
Iqbal Hossain is currently offline Iqbal Hossain
Messages: 101
Registered: May 2011
Location: Bangladesh
Senior Member
can u describe it in details? better if u provide some screen shot....
Re: Changing shape on property change [message #940869 is a reply to message #177164] Thu, 11 October 2012 22:48 Go to previous message
Iqbal Hossain is currently offline Iqbal Hossain
Messages: 101
Registered: May 2011
Location: Bangladesh
Senior Member
Boris Blajer.... can u provide some screen shoot? what to white in constraint and feature seq initializer???





Hi Nico,

My suggestion was to create distinct NodeMappings for each of the values
in the enumeration, each with a feature sequence initializer and a
constraint. Something similar has been implemented for link mappings
representing relationships of different kinds in the mindmap sample. In
your example, there would be two (more if there's more people in the
enum) shapes with different colors declared in the gmfgraph, two
NodeMappings in the gmfmap (each will reference the same underlying
model element, define a FSInitializer, a specialization constraint and
they will reference the shapes from the gmfgraph model with their
respective color).

The main advantage of this approach is that you only modify gmf models,
not the generated code; the gmf model persists the knowledge about the
colors that represent each of the enumerated value.
The main disadvantage is that you end up with several edit part classes
which are almost identical (but after all, probably once they are
separated, they may start getting different behavior other than just
color?) The performance may slightly be affected, too: using ocl engine
to read the value of a single attribute seems suboptimal in terms of
performance.

Best regards,
Boris

[Updated on: Thu, 11 October 2012 22:50]

Report message to a moderator

Previous Topic:How to enable the "show/hide all compartments" feature?
Next Topic:How to use Xtext(M2M with Xtend) and GMF to create diagramm? (Beginner)
Goto Forum:
  


Current Time: Fri Aug 01 03:51:30 EDT 2014

Powered by FUDForum. Page generated in 0.12523 seconds