Home » Modeling » GMF (Graphical Modeling Framework) » External labels and their position in the figure hierarchy
| External labels and their position in the figure hierarchy [message #98747] |
Tue, 30 January 2007 13:05  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm trying to define a label for an object that is located in a narrow
compartment along the side of its parent. Since the compartment is
narrow and anyway on the side of the parent, it seems reasonable that
the label is external, to ensure that it is not limited by the
compartment's or parent's bounding boxes. Thus, the label figure is
defined outside the object's figure. However, the label still is
placed inside the compartment and is clipped accordingly. I've looked
at the code generated for the Taipan example, and there the edit parts
for objects with external labels has code that is not generated in my
case, and that is clearly related to inserting external label figures
in a separate layer. There's also a reference to a layer that seems to
be for this purpose, that I don't find in the code that is generated
for my gmfgen model. The only difference compared to the Taipan
example is that my label is not a feature label (I provide my own
IParser).
If I look at the gmfgen model, my label is shown as an External Node
Label. So what remains to make GMF generate code that places the
external label outside the parents?
Hallvard
|
|
|
| Re: External labels and their position in the figure hierarchy [message #99623 is a reply to message #98747] |
Wed, 31 January 2007 15:09  |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Pre-M4, the labels were generated like they are in the Taipan Example --
on another layer. However, there were some issues with this approach,
so now they are generated as border items. See bugzilla 127491 for a
complete discussion if you are interested.
As to your problem, is the label a border item of the top level shape?
- Cherie
Hallvard Trætteberg wrote:
> Hi,
>
> I'm trying to define a label for an object that is located in a narrow
> compartment along the side of its parent. Since the compartment is
> narrow and anyway on the side of the parent, it seems reasonable that
> the label is external, to ensure that it is not limited by the
> compartment's or parent's bounding boxes. Thus, the label figure is
> defined outside the object's figure. However, the label still is
> placed inside the compartment and is clipped accordingly. I've looked
> at the code generated for the Taipan example, and there the edit parts
> for objects with external labels has code that is not generated in my
> case, and that is clearly related to inserting external label figures
> in a separate layer. There's also a reference to a layer that seems to
> be for this purpose, that I don't find in the code that is generated
> for my gmfgen model. The only difference compared to the Taipan
> example is that my label is not a feature label (I provide my own
> IParser).
>
> If I look at the gmfgen model, my label is shown as an External Node
> Label. So what remains to make GMF generate code that places the
> external label outside the parents?
>
> Hallvard
>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #99927 is a reply to message #99623] |
Thu, 01 February 2007 07:59 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>Pre-M4, the labels were generated like they are in the Taipan Example --
>on another layer. However, there were some issues with this approach,
>so now they are generated as border items. See bugzilla 127491 for a
>complete discussion if you are interested.
>
>As to your problem, is the label a border item of the top level shape?
My hierarchy is as follows:
Diagram
-- Process with three compartments, one on each side and one in the
middle
---- left compartment
------ Gate (port) with label as border item
---- middle compartment
------ Computation with label as border item
---- right compartment
------ Gate (port) with label as border item
Both label kinds are border items located and clipped by the
compartment that their owner is inside. However, since the left and
right compartments are very narrow (just wide enough to contain the
gates), the gate labels are almost invisible. I want the labels to be
hanging left (as a default) of the gates in the left compartment and
right of the ones in the right compartment.
Hallvard
>
>- Cherie
>
>Hallvard Trætteberg wrote:
>> Hi,
>>
>> I'm trying to define a label for an object that is located in a narrow
>> compartment along the side of its parent. Since the compartment is
>> narrow and anyway on the side of the parent, it seems reasonable that
>> the label is external, to ensure that it is not limited by the
>> compartment's or parent's bounding boxes. Thus, the label figure is
>> defined outside the object's figure. However, the label still is
>> placed inside the compartment and is clipped accordingly. I've looked
>> at the code generated for the Taipan example, and there the edit parts
>> for objects with external labels has code that is not generated in my
>> case, and that is clearly related to inserting external label figures
>> in a separate layer. There's also a reference to a layer that seems to
>> be for this purpose, that I don't find in the code that is generated
>> for my gmfgen model. The only difference compared to the Taipan
>> example is that my label is not a feature label (I provide my own
>> IParser).
>>
>> If I look at the gmfgen model, my label is shown as an External Node
>> Label. So what remains to make GMF generate code that places the
>> external label outside the parents?
>>
>> Hallvard
>>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #100043 is a reply to message #99927] |
Thu, 01 February 2007 12:44 |
Eclipse User |
|
|
|
Originally posted by: 5d5.mail.ru
I guess that's the limitation of border items - they are clipped by
their grandparent border. I think that in this case labels (ports)
should be defined for the Process node and special layout of Process
should place them close to compartments.
Hallvard Trætteberg wrote:
> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
> <crevells@ca.ibm.com> wrote:
>
>> Pre-M4, the labels were generated like they are in the Taipan Example --
>> on another layer. However, there were some issues with this approach,
>> so now they are generated as border items. See bugzilla 127491 for a
>> complete discussion if you are interested.
>>
>> As to your problem, is the label a border item of the top level shape?
>
> My hierarchy is as follows:
> Diagram
> -- Process with three compartments, one on each side and one in the
> middle
> ---- left compartment
> ------ Gate (port) with label as border item
> ---- middle compartment
> ------ Computation with label as border item
> ---- right compartment
> ------ Gate (port) with label as border item
>
> Both label kinds are border items located and clipped by the
> compartment that their owner is inside. However, since the left and
> right compartments are very narrow (just wide enough to contain the
> gates), the gate labels are almost invisible. I want the labels to be
> hanging left (as a default) of the gates in the left compartment and
> right of the ones in the right compartment.
>
> Hallvard
>
>> - Cherie
>>
>> Hallvard Trætteberg wrote:
>>> Hi,
>>>
>>> I'm trying to define a label for an object that is located in a narrow
>>> compartment along the side of its parent. Since the compartment is
>>> narrow and anyway on the side of the parent, it seems reasonable that
>>> the label is external, to ensure that it is not limited by the
>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>> defined outside the object's figure. However, the label still is
>>> placed inside the compartment and is clipped accordingly. I've looked
>>> at the code generated for the Taipan example, and there the edit parts
>>> for objects with external labels has code that is not generated in my
>>> case, and that is clearly related to inserting external label figures
>>> in a separate layer. There's also a reference to a layer that seems to
>>> be for this purpose, that I don't find in the code that is generated
>>> for my gmfgen model. The only difference compared to the Taipan
>>> example is that my label is not a feature label (I provide my own
>>> IParser).
>>>
>>> If I look at the gmfgen model, my label is shown as an External Node
>>> Label. So what remains to make GMF generate code that places the
>>> external label outside the parents?
>>>
>>> Hallvard
>>>
>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #100184 is a reply to message #100043] |
Thu, 01 February 2007 16:41 |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
I think it is probably valid to say that if a compartment has a border
item, then the parent's border should extend to hold the compartment's
border item. You can create a bugzilla if you wish against the diagram
runtime component.
However, the issue can be solved using Dmitry's suggestion.
- Cherie
Dmitry Stadnik wrote:
> I guess that's the limitation of border items - they are clipped by
> their grandparent border. I think that in this case labels (ports)
> should be defined for the Process node and special layout of Process
> should place them close to compartments.
>
> Hallvard Trætteberg wrote:
>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>> <crevells@ca.ibm.com> wrote:
>>
>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>> -- on another layer. However, there were some issues with this
>>> approach, so now they are generated as border items. See bugzilla
>>> 127491 for a complete discussion if you are interested.
>>>
>>> As to your problem, is the label a border item of the top level shape?
>>
>> My hierarchy is as follows:
>> Diagram
>> -- Process with three compartments, one on each side and one in the
>> middle
>> ---- left compartment
>> ------ Gate (port) with label as border item
>> ---- middle compartment
>> ------ Computation with label as border item
>> ---- right compartment
>> ------ Gate (port) with label as border item
>>
>> Both label kinds are border items located and clipped by the
>> compartment that their owner is inside. However, since the left and
>> right compartments are very narrow (just wide enough to contain the
>> gates), the gate labels are almost invisible. I want the labels to be
>> hanging left (as a default) of the gates in the left compartment and
>> right of the ones in the right compartment.
>>
>> Hallvard
>>
>>> - Cherie
>>>
>>> Hallvard Trætteberg wrote:
>>>> Hi,
>>>>
>>>> I'm trying to define a label for an object that is located in a narrow
>>>> compartment along the side of its parent. Since the compartment is
>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>> the label is external, to ensure that it is not limited by the
>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>> defined outside the object's figure. However, the label still is
>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>> at the code generated for the Taipan example, and there the edit parts
>>>> for objects with external labels has code that is not generated in my
>>>> case, and that is clearly related to inserting external label figures
>>>> in a separate layer. There's also a reference to a layer that seems to
>>>> be for this purpose, that I don't find in the code that is generated
>>>> for my gmfgen model. The only difference compared to the Taipan
>>>> example is that my label is not a feature label (I provide my own
>>>> IParser).
>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>> Label. So what remains to make GMF generate code that places the
>>>> external label outside the parents?
>>>>
>>>> Hallvard
>>>>
>>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #100266 is a reply to message #100184] |
Thu, 01 February 2007 21:31 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>I think it is probably valid to say that if a compartment has a border
>item, then the parent's border should extend to hold the compartment's
>border item.
I thought the whole point of external labels was that they needn't be
within their parent's or grandparent's bounding box, i.e. that they
were free-floating. Wasn't that the reason they originally (e.g. in
Taipan example) were put in their own layer?
>You can create a bugzilla if you wish against the diagram
>runtime component.
I think I need to. Do you (or Dmitry) remember why the previous
implementation was discarded for the current one? Perhaps I could
reimplement something similar?
>However, the issue can be solved using Dmitry's suggestion.
The number of ports is dynamic, so I cannot declare the port's labels
in gmfmap.
Hallvard
>
>- Cherie
>
>Dmitry Stadnik wrote:
>> I guess that's the limitation of border items - they are clipped by
>> their grandparent border. I think that in this case labels (ports)
>> should be defined for the Process node and special layout of Process
>> should place them close to compartments.
>>
>> Hallvard Trætteberg wrote:
>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>> <crevells@ca.ibm.com> wrote:
>>>
>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>> -- on another layer. However, there were some issues with this
>>>> approach, so now they are generated as border items. See bugzilla
>>>> 127491 for a complete discussion if you are interested.
>>>>
>>>> As to your problem, is the label a border item of the top level shape?
>>>
>>> My hierarchy is as follows:
>>> Diagram
>>> -- Process with three compartments, one on each side and one in the
>>> middle
>>> ---- left compartment
>>> ------ Gate (port) with label as border item
>>> ---- middle compartment
>>> ------ Computation with label as border item
>>> ---- right compartment
>>> ------ Gate (port) with label as border item
>>>
>>> Both label kinds are border items located and clipped by the
>>> compartment that their owner is inside. However, since the left and
>>> right compartments are very narrow (just wide enough to contain the
>>> gates), the gate labels are almost invisible. I want the labels to be
>>> hanging left (as a default) of the gates in the left compartment and
>>> right of the ones in the right compartment.
>>>
>>> Hallvard
>>>
>>>> - Cherie
>>>>
>>>> Hallvard Trætteberg wrote:
>>>>> Hi,
>>>>>
>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>> compartment along the side of its parent. Since the compartment is
>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>> the label is external, to ensure that it is not limited by the
>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>> defined outside the object's figure. However, the label still is
>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>> for objects with external labels has code that is not generated in my
>>>>> case, and that is clearly related to inserting external label figures
>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>> be for this purpose, that I don't find in the code that is generated
>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>> example is that my label is not a feature label (I provide my own
>>>>> IParser).
>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>> Label. So what remains to make GMF generate code that places the
>>>>> external label outside the parents?
>>>>>
>>>>> Hallvard
>>>>>
>>>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #100654 is a reply to message #100266] |
Fri, 02 February 2007 15:47 |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Did you read the comments in bugzilla 127491? It discusses the issues
with having the labels on another layer.
The border items should appear exactly as they did as if they were on
another layer. In the implementation they are contained in the parent
figure's bounds, but on the diagram the user will not see this.
- Cherie
Hallvard Trætteberg wrote:
>
> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
> <crevells@ca.ibm.com> wrote:
>> I think it is probably valid to say that if a compartment has a border
>> item, then the parent's border should extend to hold the compartment's
>> border item.
>
> I thought the whole point of external labels was that they needn't be
> within their parent's or grandparent's bounding box, i.e. that they
> were free-floating. Wasn't that the reason they originally (e.g. in
> Taipan example) were put in their own layer?
>
>> You can create a bugzilla if you wish against the diagram
>> runtime component.
>
> I think I need to. Do you (or Dmitry) remember why the previous
> implementation was discarded for the current one? Perhaps I could
> reimplement something similar?
>
>> However, the issue can be solved using Dmitry's suggestion.
>
> The number of ports is dynamic, so I cannot declare the port's labels
> in gmfmap.
>
> Hallvard
>
>> - Cherie
>>
>> Dmitry Stadnik wrote:
>>> I guess that's the limitation of border items - they are clipped by
>>> their grandparent border. I think that in this case labels (ports)
>>> should be defined for the Process node and special layout of Process
>>> should place them close to compartments.
>>>
>>> Hallvard Trætteberg wrote:
>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>> <crevells@ca.ibm.com> wrote:
>>>>
>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>> -- on another layer. However, there were some issues with this
>>>>> approach, so now they are generated as border items. See bugzilla
>>>>> 127491 for a complete discussion if you are interested.
>>>>>
>>>>> As to your problem, is the label a border item of the top level shape?
>>>> My hierarchy is as follows:
>>>> Diagram
>>>> -- Process with three compartments, one on each side and one in the
>>>> middle
>>>> ---- left compartment
>>>> ------ Gate (port) with label as border item
>>>> ---- middle compartment
>>>> ------ Computation with label as border item
>>>> ---- right compartment
>>>> ------ Gate (port) with label as border item
>>>>
>>>> Both label kinds are border items located and clipped by the
>>>> compartment that their owner is inside. However, since the left and
>>>> right compartments are very narrow (just wide enough to contain the
>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>> hanging left (as a default) of the gates in the left compartment and
>>>> right of the ones in the right compartment.
>>>>
>>>> Hallvard
>>>>
>>>>> - Cherie
>>>>>
>>>>> Hallvard Trætteberg wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>> the label is external, to ensure that it is not limited by the
>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>> defined outside the object's figure. However, the label still is
>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>> for objects with external labels has code that is not generated in my
>>>>>> case, and that is clearly related to inserting external label figures
>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>> example is that my label is not a feature label (I provide my own
>>>>>> IParser).
>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>> external label outside the parents?
>>>>>>
>>>>>> Hallvard
>>>>>>
>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #100885 is a reply to message #100654] |
Fri, 02 February 2007 23:13 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Cherie,
I have read the bugzilla discussion, and understand that the
implementation has changed from adding the labels to a separate layer
to inserting border items around the node. Visually this is very nice,
but the problem with the clipping remains: The labels don't float
freely, they are clipped by the node's parent. Hence, only parts of
the labels in the left and right compartments are visible, since the
compartments are sized based on the node shape without considering the
labels.
A solution has to handle two issues: 1) the lifecycle of the label (it
should appear with the node shape and be removed with it) and 2) the
layout relative to the node shape. One possibility I've been
considering is as follows:
- The LabelEditPart has a method that determines how high up in the
figure hierarchy (above the node) the border item is located. This is
to ensure that the label is clipped high enough up to remain visible
(which depends on the particular diagram class).
- The LabelEditPart or the corresponding figure must make sure to also
remove the label, so the label's lifecycle corresponds to the node
shape's.
- the BorderItemLocator is changed to be able to place the label
relative to the node, even though the label may be further away from
the node in the hierarchy. The main issue here should be to correctly
translate the coordinates.
Shouldn't this be feasible? The main problem I see is if this confuses
the figure that happens to host the border item. It must somehow have
a place for such BorderItems, similar to how the generated nodes
handle them (which is easier, since the node is aware of the label).
Hallvard
On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>Hallvard,
>
>Did you read the comments in bugzilla 127491? It discusses the issues
>with having the labels on another layer.
>
>The border items should appear exactly as they did as if they were on
>another layer. In the implementation they are contained in the parent
>figure's bounds, but on the diagram the user will not see this.
>
>- Cherie
>
>Hallvard Trætteberg wrote:
>>
>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>> <crevells@ca.ibm.com> wrote:
>>> I think it is probably valid to say that if a compartment has a border
>>> item, then the parent's border should extend to hold the compartment's
>>> border item.
>>
>> I thought the whole point of external labels was that they needn't be
>> within their parent's or grandparent's bounding box, i.e. that they
>> were free-floating. Wasn't that the reason they originally (e.g. in
>> Taipan example) were put in their own layer?
>>
>>> You can create a bugzilla if you wish against the diagram
>>> runtime component.
>>
>> I think I need to. Do you (or Dmitry) remember why the previous
>> implementation was discarded for the current one? Perhaps I could
>> reimplement something similar?
>>
>>> However, the issue can be solved using Dmitry's suggestion.
>>
>> The number of ports is dynamic, so I cannot declare the port's labels
>> in gmfmap.
>>
>> Hallvard
>>
>>> - Cherie
>>>
>>> Dmitry Stadnik wrote:
>>>> I guess that's the limitation of border items - they are clipped by
>>>> their grandparent border. I think that in this case labels (ports)
>>>> should be defined for the Process node and special layout of Process
>>>> should place them close to compartments.
>>>>
>>>> Hallvard Trætteberg wrote:
>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>> <crevells@ca.ibm.com> wrote:
>>>>>
>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>> -- on another layer. However, there were some issues with this
>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>
>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>> My hierarchy is as follows:
>>>>> Diagram
>>>>> -- Process with three compartments, one on each side and one in the
>>>>> middle
>>>>> ---- left compartment
>>>>> ------ Gate (port) with label as border item
>>>>> ---- middle compartment
>>>>> ------ Computation with label as border item
>>>>> ---- right compartment
>>>>> ------ Gate (port) with label as border item
>>>>>
>>>>> Both label kinds are border items located and clipped by the
>>>>> compartment that their owner is inside. However, since the left and
>>>>> right compartments are very narrow (just wide enough to contain the
>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>> right of the ones in the right compartment.
>>>>>
>>>>> Hallvard
>>>>>
>>>>>> - Cherie
>>>>>>
>>>>>> Hallvard Trætteberg wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>> IParser).
>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>> external label outside the parents?
>>>>>>>
>>>>>>> Hallvard
>>>>>>>
>>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #100984 is a reply to message #100885] |
Mon, 05 February 2007 16:51 |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
I'm having a hard time visualizing your process node? Could you send a
screenshot or mockup?
- Cherie
Hallvard Trætteberg wrote:
> Cherie,
>
> I have read the bugzilla discussion, and understand that the
> implementation has changed from adding the labels to a separate layer
> to inserting border items around the node. Visually this is very nice,
> but the problem with the clipping remains: The labels don't float
> freely, they are clipped by the node's parent. Hence, only parts of
> the labels in the left and right compartments are visible, since the
> compartments are sized based on the node shape without considering the
> labels.
>
> A solution has to handle two issues: 1) the lifecycle of the label (it
> should appear with the node shape and be removed with it) and 2) the
> layout relative to the node shape. One possibility I've been
> considering is as follows:
> - The LabelEditPart has a method that determines how high up in the
> figure hierarchy (above the node) the border item is located. This is
> to ensure that the label is clipped high enough up to remain visible
> (which depends on the particular diagram class).
> - The LabelEditPart or the corresponding figure must make sure to also
> remove the label, so the label's lifecycle corresponds to the node
> shape's.
> - the BorderItemLocator is changed to be able to place the label
> relative to the node, even though the label may be further away from
> the node in the hierarchy. The main issue here should be to correctly
> translate the coordinates.
>
> Shouldn't this be feasible? The main problem I see is if this confuses
> the figure that happens to host the border item. It must somehow have
> a place for such BorderItems, similar to how the generated nodes
> handle them (which is easier, since the node is aware of the label).
>
> Hallvard
>
> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
> <crevells@ca.ibm.com> wrote:
>
>> Hallvard,
>>
>> Did you read the comments in bugzilla 127491? It discusses the issues
>> with having the labels on another layer.
>>
>> The border items should appear exactly as they did as if they were on
>> another layer. In the implementation they are contained in the parent
>> figure's bounds, but on the diagram the user will not see this.
>>
>> - Cherie
>>
>> Hallvard Trætteberg wrote:
>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>> <crevells@ca.ibm.com> wrote:
>>>> I think it is probably valid to say that if a compartment has a border
>>>> item, then the parent's border should extend to hold the compartment's
>>>> border item.
>>> I thought the whole point of external labels was that they needn't be
>>> within their parent's or grandparent's bounding box, i.e. that they
>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>> Taipan example) were put in their own layer?
>>>
>>>> You can create a bugzilla if you wish against the diagram
>>>> runtime component.
>>> I think I need to. Do you (or Dmitry) remember why the previous
>>> implementation was discarded for the current one? Perhaps I could
>>> reimplement something similar?
>>>
>>>> However, the issue can be solved using Dmitry's suggestion.
>>> The number of ports is dynamic, so I cannot declare the port's labels
>>> in gmfmap.
>>>
>>> Hallvard
>>>
>>>> - Cherie
>>>>
>>>> Dmitry Stadnik wrote:
>>>>> I guess that's the limitation of border items - they are clipped by
>>>>> their grandparent border. I think that in this case labels (ports)
>>>>> should be defined for the Process node and special layout of Process
>>>>> should place them close to compartments.
>>>>>
>>>>> Hallvard Trætteberg wrote:
>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>
>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>
>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>> My hierarchy is as follows:
>>>>>> Diagram
>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>> middle
>>>>>> ---- left compartment
>>>>>> ------ Gate (port) with label as border item
>>>>>> ---- middle compartment
>>>>>> ------ Computation with label as border item
>>>>>> ---- right compartment
>>>>>> ------ Gate (port) with label as border item
>>>>>>
>>>>>> Both label kinds are border items located and clipped by the
>>>>>> compartment that their owner is inside. However, since the left and
>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>> right of the ones in the right compartment.
>>>>>>
>>>>>> Hallvard
>>>>>>
>>>>>>> - Cherie
>>>>>>>
>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>> IParser).
>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>> external label outside the parents?
>>>>>>>>
>>>>>>>> Hallvard
>>>>>>>>
>
|
|
|
| Re: External labels and their position in the figure hierarchy - gate-labels.gif (0/1) [message #101286 is a reply to message #100984] |
Tue, 06 February 2007 08:55 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On Mon, 05 Feb 2007 11:51:59 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>Hallvard,
>
>I'm having a hard time visualizing your process node? Could you send a
>screenshot or mockup?
I screenshot is attached. On the left edge of the process rectangle
there are two triangles (what I called gates). You can see the clipped
labels to the left of the triangles ( '[' and ':-'). The top-level
process figure is a bit larger than the rectangle, to be able to
layout the compartment that the gates are within over the rectangle
edge. As mentioned, the structure is as follows:
-- Process with compartments on each side and one in the middle
---- left compartment on the rectangle edge
------ Gate with label as border item
Since the compartment containing the gates is so tight, it cannot
contain (and clip) the labels, hence the labels must be on the outside
(in the process figure's parent).
If I'm allowed to somewhere decide how far up in the figure hierarchy
the label is placed, and be able to control it's life-cycle, I think I
could make it work. This requires a BorderItemLocator that correctly
handles the coordinates of labels that are far above the "owner".
Hallvard
>
>- Cherie
>
>Hallvard Trætteberg wrote:
>> Cherie,
>>
>> I have read the bugzilla discussion, and understand that the
>> implementation has changed from adding the labels to a separate layer
>> to inserting border items around the node. Visually this is very nice,
>> but the problem with the clipping remains: The labels don't float
>> freely, they are clipped by the node's parent. Hence, only parts of
>> the labels in the left and right compartments are visible, since the
>> compartments are sized based on the node shape without considering the
>> labels.
>>
>> A solution has to handle two issues: 1) the lifecycle of the label (it
>> should appear with the node shape and be removed with it) and 2) the
>> layout relative to the node shape. One possibility I've been
>> considering is as follows:
>> - The LabelEditPart has a method that determines how high up in the
>> figure hierarchy (above the node) the border item is located. This is
>> to ensure that the label is clipped high enough up to remain visible
>> (which depends on the particular diagram class).
>> - The LabelEditPart or the corresponding figure must make sure to also
>> remove the label, so the label's lifecycle corresponds to the node
>> shape's.
>> - the BorderItemLocator is changed to be able to place the label
>> relative to the node, even though the label may be further away from
>> the node in the hierarchy. The main issue here should be to correctly
>> translate the coordinates.
>>
>> Shouldn't this be feasible? The main problem I see is if this confuses
>> the figure that happens to host the border item. It must somehow have
>> a place for such BorderItems, similar to how the generated nodes
>> handle them (which is easier, since the node is aware of the label).
>>
>> Hallvard
>>
>> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
>> <crevells@ca.ibm.com> wrote:
>>
>>> Hallvard,
>>>
>>> Did you read the comments in bugzilla 127491? It discusses the issues
>>> with having the labels on another layer.
>>>
>>> The border items should appear exactly as they did as if they were on
>>> another layer. In the implementation they are contained in the parent
>>> figure's bounds, but on the diagram the user will not see this.
>>>
>>> - Cherie
>>>
>>> Hallvard Trætteberg wrote:
>>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>>> <crevells@ca.ibm.com> wrote:
>>>>> I think it is probably valid to say that if a compartment has a border
>>>>> item, then the parent's border should extend to hold the compartment's
>>>>> border item.
>>>> I thought the whole point of external labels was that they needn't be
>>>> within their parent's or grandparent's bounding box, i.e. that they
>>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>>> Taipan example) were put in their own layer?
>>>>
>>>>> You can create a bugzilla if you wish against the diagram
>>>>> runtime component.
>>>> I think I need to. Do you (or Dmitry) remember why the previous
>>>> implementation was discarded for the current one? Perhaps I could
>>>> reimplement something similar?
>>>>
>>>>> However, the issue can be solved using Dmitry's suggestion.
>>>> The number of ports is dynamic, so I cannot declare the port's labels
>>>> in gmfmap.
>>>>
>>>> Hallvard
>>>>
>>>>> - Cherie
>>>>>
>>>>> Dmitry Stadnik wrote:
>>>>>> I guess that's the limitation of border items - they are clipped by
>>>>>> their grandparent border. I think that in this case labels (ports)
>>>>>> should be defined for the Process node and special layout of Process
>>>>>> should place them close to compartments.
>>>>>>
>>>>>> Hallvard Trætteberg wrote:
>>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>
>>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>>
>>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>>> My hierarchy is as follows:
>>>>>>> Diagram
>>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>>> middle
>>>>>>> ---- left compartment
>>>>>>> ------ Gate (port) with label as border item
>>>>>>> ---- middle compartment
>>>>>>> ------ Computation with label as border item
>>>>>>> ---- right compartment
>>>>>>> ------ Gate (port) with label as border item
>>>>>>>
>>>>>>> Both label kinds are border items located and clipped by the
>>>>>>> compartment that their owner is inside. However, since the left and
>>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>>> right of the ones in the right compartment.
>>>>>>>
>>>>>>> Hallvard
>>>>>>>
>>>>>>>> - Cherie
>>>>>>>>
>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>>> IParser).
>>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>>> external label outside the parents?
>>>>>>>>>
>>>>>>>>> Hallvard
>>>>>>>>>
>>
|
|
| |
| Re: External labels and their position in the figure hierarchy - gate-labels.gif (0/1) [message #101751 is a reply to message #101286] |
Tue, 06 February 2007 19:27 |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Given the way the border items work today, I would suggest you make your
gates border items of the mailboxesView shape (is this what you are
calling your process rectangle?). I'm not sure why you need three
compartments. It looks to me like you just need one compartment of your
mailboxesView to hold the widget lists and inside triangles. Your gates
can be children of the top-level mailboxesView shape, and you can
control their location as you wish using a specialized locator. For
example, if you want to restrict your gates to go around the grey
compartment and not above the mailboxesView title, you could do that
with your border item locator.
I think this would be the easiest way to accomplish what you want;
however, I may be misunderstanding something about your diagram.
- Cherie
Hallvard Trætteberg wrote:
> On Mon, 05 Feb 2007 11:51:59 -0500, Cherie Revells
> <crevells@ca.ibm.com> wrote:
>
>> Hallvard,
>>
>> I'm having a hard time visualizing your process node? Could you send a
>> screenshot or mockup?
>
> I screenshot is attached. On the left edge of the process rectangle
> there are two triangles (what I called gates). You can see the clipped
> labels to the left of the triangles ( '[' and ':-'). The top-level
> process figure is a bit larger than the rectangle, to be able to
> layout the compartment that the gates are within over the rectangle
> edge. As mentioned, the structure is as follows:
>
> -- Process with compartments on each side and one in the middle
> ---- left compartment on the rectangle edge
> ------ Gate with label as border item
>
> Since the compartment containing the gates is so tight, it cannot
> contain (and clip) the labels, hence the labels must be on the outside
> (in the process figure's parent).
>
> If I'm allowed to somewhere decide how far up in the figure hierarchy
> the label is placed, and be able to control it's life-cycle, I think I
> could make it work. This requires a BorderItemLocator that correctly
> handles the coordinates of labels that are far above the "owner".
>
> Hallvard
>
>> - Cherie
>>
>> Hallvard Trætteberg wrote:
>>> Cherie,
>>>
>>> I have read the bugzilla discussion, and understand that the
>>> implementation has changed from adding the labels to a separate layer
>>> to inserting border items around the node. Visually this is very nice,
>>> but the problem with the clipping remains: The labels don't float
>>> freely, they are clipped by the node's parent. Hence, only parts of
>>> the labels in the left and right compartments are visible, since the
>>> compartments are sized based on the node shape without considering the
>>> labels.
>>>
>>> A solution has to handle two issues: 1) the lifecycle of the label (it
>>> should appear with the node shape and be removed with it) and 2) the
>>> layout relative to the node shape. One possibility I've been
>>> considering is as follows:
>>> - The LabelEditPart has a method that determines how high up in the
>>> figure hierarchy (above the node) the border item is located. This is
>>> to ensure that the label is clipped high enough up to remain visible
>>> (which depends on the particular diagram class).
>>> - The LabelEditPart or the corresponding figure must make sure to also
>>> remove the label, so the label's lifecycle corresponds to the node
>>> shape's.
>>> - the BorderItemLocator is changed to be able to place the label
>>> relative to the node, even though the label may be further away from
>>> the node in the hierarchy. The main issue here should be to correctly
>>> translate the coordinates.
>>>
>>> Shouldn't this be feasible? The main problem I see is if this confuses
>>> the figure that happens to host the border item. It must somehow have
>>> a place for such BorderItems, similar to how the generated nodes
>>> handle them (which is easier, since the node is aware of the label).
>>>
>>> Hallvard
>>>
>>> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
>>> <crevells@ca.ibm.com> wrote:
>>>
>>>> Hallvard,
>>>>
>>>> Did you read the comments in bugzilla 127491? It discusses the issues
>>>> with having the labels on another layer.
>>>>
>>>> The border items should appear exactly as they did as if they were on
>>>> another layer. In the implementation they are contained in the parent
>>>> figure's bounds, but on the diagram the user will not see this.
>>>>
>>>> - Cherie
>>>>
>>>> Hallvard Trætteberg wrote:
>>>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>>>> <crevells@ca.ibm.com> wrote:
>>>>>> I think it is probably valid to say that if a compartment has a border
>>>>>> item, then the parent's border should extend to hold the compartment's
>>>>>> border item.
>>>>> I thought the whole point of external labels was that they needn't be
>>>>> within their parent's or grandparent's bounding box, i.e. that they
>>>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>>>> Taipan example) were put in their own layer?
>>>>>
>>>>>> You can create a bugzilla if you wish against the diagram
>>>>>> runtime component.
>>>>> I think I need to. Do you (or Dmitry) remember why the previous
>>>>> implementation was discarded for the current one? Perhaps I could
>>>>> reimplement something similar?
>>>>>
>>>>>> However, the issue can be solved using Dmitry's suggestion.
>>>>> The number of ports is dynamic, so I cannot declare the port's labels
>>>>> in gmfmap.
>>>>>
>>>>> Hallvard
>>>>>
>>>>>> - Cherie
>>>>>>
>>>>>> Dmitry Stadnik wrote:
>>>>>>> I guess that's the limitation of border items - they are clipped by
>>>>>>> their grandparent border. I think that in this case labels (ports)
>>>>>>> should be defined for the Process node and special layout of Process
>>>>>>> should place them close to compartments.
>>>>>>>
>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>
>>>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>>>
>>>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>>>> My hierarchy is as follows:
>>>>>>>> Diagram
>>>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>>>> middle
>>>>>>>> ---- left compartment
>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>> ---- middle compartment
>>>>>>>> ------ Computation with label as border item
>>>>>>>> ---- right compartment
>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>
>>>>>>>> Both label kinds are border items located and clipped by the
>>>>>>>> compartment that their owner is inside. However, since the left and
>>>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>>>> right of the ones in the right compartment.
>>>>>>>>
>>>>>>>> Hallvard
>>>>>>>>
>>>>>>>>> - Cherie
>>>>>>>>>
>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>>>> IParser).
>>>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>>>> external label outside the parents?
>>>>>>>>>>
>>>>>>>>>> Hallvard
>>>>>>>>>>
>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #101821 is a reply to message #101751] |
Wed, 07 February 2007 08:04 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Cherie,
On Tue, 06 Feb 2007 14:27:00 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>Given the way the border items work today, I would suggest you make your
>gates border items of the mailboxesView shape (is this what you are
>calling your process rectangle?). I'm not sure why you need three
>compartments.
I probably don't need three compartments, you're right about that. The
ones on the left and right (seldom used) edges are only there for the
layout. I wasn't aware of the BorderItemLocators when I designed it
this way.
>mailboxesView to hold the widget lists and inside triangles. Your gates
>can be children of the top-level mailboxesView shape, and you can
>control their location as you wish using a specialized locator.
How do I model this with gmfmap? The nice thing about compartments is
that they know which kind of elements can be in them, so I get the
popup creation bar for free. If I remove the (definition of the) left
and right compartments and keep the middle one (which is restricted to
hold only certain elements), will the remaining children automatically
(by default) be placed withing the top-level interactor (process)
shape?
>I think this would be the easiest way to accomplish what you want;
>however, I may be misunderstanding something about your diagram.
Thanks for this suggestion! Two questions
1) To make a gate into a border item, must my gate edit part and/or
figures subclass specific classes?
2) How will this affect the labels of the gates? Will they then be
able to float freely outside the gate and the parent interactor?
Hallvard
>
>- Cherie
>
>Hallvard Trætteberg wrote:
>> On Mon, 05 Feb 2007 11:51:59 -0500, Cherie Revells
>> <crevells@ca.ibm.com> wrote:
>>
>>> Hallvard,
>>>
>>> I'm having a hard time visualizing your process node? Could you send a
>>> screenshot or mockup?
>>
>> I screenshot is attached. On the left edge of the process rectangle
>> there are two triangles (what I called gates). You can see the clipped
>> labels to the left of the triangles ( '[' and ':-'). The top-level
>> process figure is a bit larger than the rectangle, to be able to
>> layout the compartment that the gates are within over the rectangle
>> edge. As mentioned, the structure is as follows:
>>
>> -- Process with compartments on each side and one in the middle
>> ---- left compartment on the rectangle edge
>> ------ Gate with label as border item
>>
>> Since the compartment containing the gates is so tight, it cannot
>> contain (and clip) the labels, hence the labels must be on the outside
>> (in the process figure's parent).
>>
>> If I'm allowed to somewhere decide how far up in the figure hierarchy
>> the label is placed, and be able to control it's life-cycle, I think I
>> could make it work. This requires a BorderItemLocator that correctly
>> handles the coordinates of labels that are far above the "owner".
>>
>> Hallvard
>>
>>> - Cherie
>>>
>>> Hallvard Trætteberg wrote:
>>>> Cherie,
>>>>
>>>> I have read the bugzilla discussion, and understand that the
>>>> implementation has changed from adding the labels to a separate layer
>>>> to inserting border items around the node. Visually this is very nice,
>>>> but the problem with the clipping remains: The labels don't float
>>>> freely, they are clipped by the node's parent. Hence, only parts of
>>>> the labels in the left and right compartments are visible, since the
>>>> compartments are sized based on the node shape without considering the
>>>> labels.
>>>>
>>>> A solution has to handle two issues: 1) the lifecycle of the label (it
>>>> should appear with the node shape and be removed with it) and 2) the
>>>> layout relative to the node shape. One possibility I've been
>>>> considering is as follows:
>>>> - The LabelEditPart has a method that determines how high up in the
>>>> figure hierarchy (above the node) the border item is located. This is
>>>> to ensure that the label is clipped high enough up to remain visible
>>>> (which depends on the particular diagram class).
>>>> - The LabelEditPart or the corresponding figure must make sure to also
>>>> remove the label, so the label's lifecycle corresponds to the node
>>>> shape's.
>>>> - the BorderItemLocator is changed to be able to place the label
>>>> relative to the node, even though the label may be further away from
>>>> the node in the hierarchy. The main issue here should be to correctly
>>>> translate the coordinates.
>>>>
>>>> Shouldn't this be feasible? The main problem I see is if this confuses
>>>> the figure that happens to host the border item. It must somehow have
>>>> a place for such BorderItems, similar to how the generated nodes
>>>> handle them (which is easier, since the node is aware of the label).
>>>>
>>>> Hallvard
>>>>
>>>> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
>>>> <crevells@ca.ibm.com> wrote:
>>>>
>>>>> Hallvard,
>>>>>
>>>>> Did you read the comments in bugzilla 127491? It discusses the issues
>>>>> with having the labels on another layer.
>>>>>
>>>>> The border items should appear exactly as they did as if they were on
>>>>> another layer. In the implementation they are contained in the parent
>>>>> figure's bounds, but on the diagram the user will not see this.
>>>>>
>>>>> - Cherie
>>>>>
>>>>> Hallvard Trætteberg wrote:
>>>>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>> I think it is probably valid to say that if a compartment has a border
>>>>>>> item, then the parent's border should extend to hold the compartment's
>>>>>>> border item.
>>>>>> I thought the whole point of external labels was that they needn't be
>>>>>> within their parent's or grandparent's bounding box, i.e. that they
>>>>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>>>>> Taipan example) were put in their own layer?
>>>>>>
>>>>>>> You can create a bugzilla if you wish against the diagram
>>>>>>> runtime component.
>>>>>> I think I need to. Do you (or Dmitry) remember why the previous
>>>>>> implementation was discarded for the current one? Perhaps I could
>>>>>> reimplement something similar?
>>>>>>
>>>>>>> However, the issue can be solved using Dmitry's suggestion.
>>>>>> The number of ports is dynamic, so I cannot declare the port's labels
>>>>>> in gmfmap.
>>>>>>
>>>>>> Hallvard
>>>>>>
>>>>>>> - Cherie
>>>>>>>
>>>>>>> Dmitry Stadnik wrote:
>>>>>>>> I guess that's the limitation of border items - they are clipped by
>>>>>>>> their grandparent border. I think that in this case labels (ports)
>>>>>>>> should be defined for the Process node and special layout of Process
>>>>>>>> should place them close to compartments.
>>>>>>>>
>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>>
>>>>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>>>>
>>>>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>>>>> My hierarchy is as follows:
>>>>>>>>> Diagram
>>>>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>>>>> middle
>>>>>>>>> ---- left compartment
>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>> ---- middle compartment
>>>>>>>>> ------ Computation with label as border item
>>>>>>>>> ---- right compartment
>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>
>>>>>>>>> Both label kinds are border items located and clipped by the
>>>>>>>>> compartment that their owner is inside. However, since the left and
>>>>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>>>>> right of the ones in the right compartment.
>>>>>>>>>
>>>>>>>>> Hallvard
>>>>>>>>>
>>>>>>>>>> - Cherie
>>>>>>>>>>
>>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>>>>> IParser).
>>>>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>>>>> external label outside the parents?
>>>>>>>>>>>
>>>>>>>>>>> Hallvard
>>>>>>>>>>>
>>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #102352 is a reply to message #101821] |
Thu, 08 February 2007 18:27 |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
> 1) To make a gate into a border item, must my gate edit part and/or
> figures subclass specific classes?
To work with the existing border item infrastructure in GMF, your border
item editpart should implement IBorderItemEditPart and your border item
container should implement IBorderedShapeEditPart. The
AbstractBorderItemEditPart and AbstractBorderedShapeEditPart can be
subclassed for ease of use or if this is not possible in your editpart
hierarachy you could essentially copy the code from these classes.
> 2) How will this affect the labels of the gates? Will they then be
> able to float freely outside the gate and the parent interactor?
Your label can be a border item of the gate. So your gate editpart
would be a IBorderItemEditPart and a IBorderedShapeEditPart. Yes, if
the gate is a child of the parent interactor, then the gate and its
label should be able to float outside the parent interactor.
Unfortunately, I don't know the generator enough to give you advice on
how you can generate what I am suggesting, but it is always possible to
modify the generated code if necessary. The labels around the gates
should be no different then the labels on nodes in the Taipan example.
I think they can move around too.
Regards,
Cherie
Hallvard Trætteberg wrote:
> Cherie,
>
> On Tue, 06 Feb 2007 14:27:00 -0500, Cherie Revells
> <crevells@ca.ibm.com> wrote:
>> Given the way the border items work today, I would suggest you make your
>> gates border items of the mailboxesView shape (is this what you are
>> calling your process rectangle?). I'm not sure why you need three
>> compartments.
>
> I probably don't need three compartments, you're right about that. The
> ones on the left and right (seldom used) edges are only there for the
> layout. I wasn't aware of the BorderItemLocators when I designed it
> this way.
>
>> mailboxesView to hold the widget lists and inside triangles. Your gates
>> can be children of the top-level mailboxesView shape, and you can
>> control their location as you wish using a specialized locator.
>
> How do I model this with gmfmap? The nice thing about compartments is
> that they know which kind of elements can be in them, so I get the
> popup creation bar for free. If I remove the (definition of the) left
> and right compartments and keep the middle one (which is restricted to
> hold only certain elements), will the remaining children automatically
> (by default) be placed withing the top-level interactor (process)
> shape?
>
>> I think this would be the easiest way to accomplish what you want;
>> however, I may be misunderstanding something about your diagram.
>
> Thanks for this suggestion! Two questions
> 1) To make a gate into a border item, must my gate edit part and/or
> figures subclass specific classes?
> 2) How will this affect the labels of the gates? Will they then be
> able to float freely outside the gate and the parent interactor?
>
> Hallvard
>
>> - Cherie
>>
>> Hallvard Trætteberg wrote:
>>> On Mon, 05 Feb 2007 11:51:59 -0500, Cherie Revells
>>> <crevells@ca.ibm.com> wrote:
>>>
>>>> Hallvard,
>>>>
>>>> I'm having a hard time visualizing your process node? Could you send a
>>>> screenshot or mockup?
>>> I screenshot is attached. On the left edge of the process rectangle
>>> there are two triangles (what I called gates). You can see the clipped
>>> labels to the left of the triangles ( '[' and ':-'). The top-level
>>> process figure is a bit larger than the rectangle, to be able to
>>> layout the compartment that the gates are within over the rectangle
>>> edge. As mentioned, the structure is as follows:
>>>
>>> -- Process with compartments on each side and one in the middle
>>> ---- left compartment on the rectangle edge
>>> ------ Gate with label as border item
>>>
>>> Since the compartment containing the gates is so tight, it cannot
>>> contain (and clip) the labels, hence the labels must be on the outside
>>> (in the process figure's parent).
>>>
>>> If I'm allowed to somewhere decide how far up in the figure hierarchy
>>> the label is placed, and be able to control it's life-cycle, I think I
>>> could make it work. This requires a BorderItemLocator that correctly
>>> handles the coordinates of labels that are far above the "owner".
>>>
>>> Hallvard
>>>
>>>> - Cherie
>>>>
>>>> Hallvard Trætteberg wrote:
>>>>> Cherie,
>>>>>
>>>>> I have read the bugzilla discussion, and understand that the
>>>>> implementation has changed from adding the labels to a separate layer
>>>>> to inserting border items around the node. Visually this is very nice,
>>>>> but the problem with the clipping remains: The labels don't float
>>>>> freely, they are clipped by the node's parent. Hence, only parts of
>>>>> the labels in the left and right compartments are visible, since the
>>>>> compartments are sized based on the node shape without considering the
>>>>> labels.
>>>>>
>>>>> A solution has to handle two issues: 1) the lifecycle of the label (it
>>>>> should appear with the node shape and be removed with it) and 2) the
>>>>> layout relative to the node shape. One possibility I've been
>>>>> considering is as follows:
>>>>> - The LabelEditPart has a method that determines how high up in the
>>>>> figure hierarchy (above the node) the border item is located. This is
>>>>> to ensure that the label is clipped high enough up to remain visible
>>>>> (which depends on the particular diagram class).
>>>>> - The LabelEditPart or the corresponding figure must make sure to also
>>>>> remove the label, so the label's lifecycle corresponds to the node
>>>>> shape's.
>>>>> - the BorderItemLocator is changed to be able to place the label
>>>>> relative to the node, even though the label may be further away from
>>>>> the node in the hierarchy. The main issue here should be to correctly
>>>>> translate the coordinates.
>>>>>
>>>>> Shouldn't this be feasible? The main problem I see is if this confuses
>>>>> the figure that happens to host the border item. It must somehow have
>>>>> a place for such BorderItems, similar to how the generated nodes
>>>>> handle them (which is easier, since the node is aware of the label).
>>>>>
>>>>> Hallvard
>>>>>
>>>>> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
>>>>> <crevells@ca.ibm.com> wrote:
>>>>>
>>>>>> Hallvard,
>>>>>>
>>>>>> Did you read the comments in bugzilla 127491? It discusses the issues
>>>>>> with having the labels on another layer.
>>>>>>
>>>>>> The border items should appear exactly as they did as if they were on
>>>>>> another layer. In the implementation they are contained in the parent
>>>>>> figure's bounds, but on the diagram the user will not see this.
>>>>>>
>>>>>> - Cherie
>>>>>>
>>>>>> Hallvard Trætteberg wrote:
>>>>>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>> I think it is probably valid to say that if a compartment has a border
>>>>>>>> item, then the parent's border should extend to hold the compartment's
>>>>>>>> border item.
>>>>>>> I thought the whole point of external labels was that they needn't be
>>>>>>> within their parent's or grandparent's bounding box, i.e. that they
>>>>>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>>>>>> Taipan example) were put in their own layer?
>>>>>>>
>>>>>>>> You can create a bugzilla if you wish against the diagram
>>>>>>>> runtime component.
>>>>>>> I think I need to. Do you (or Dmitry) remember why the previous
>>>>>>> implementation was discarded for the current one? Perhaps I could
>>>>>>> reimplement something similar?
>>>>>>>
>>>>>>>> However, the issue can be solved using Dmitry's suggestion.
>>>>>>> The number of ports is dynamic, so I cannot declare the port's labels
>>>>>>> in gmfmap.
>>>>>>>
>>>>>>> Hallvard
>>>>>>>
>>>>>>>> - Cherie
>>>>>>>>
>>>>>>>> Dmitry Stadnik wrote:
>>>>>>>>> I guess that's the limitation of border items - they are clipped by
>>>>>>>>> their grandparent border. I think that in this case labels (ports)
>>>>>>>>> should be defined for the Process node and special layout of Process
>>>>>>>>> should place them close to compartments.
>>>>>>>>>
>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>>>>>
>>>>>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>>>>>> My hierarchy is as follows:
>>>>>>>>>> Diagram
>>>>>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>>>>>> middle
>>>>>>>>>> ---- left compartment
>>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>> ---- middle compartment
>>>>>>>>>> ------ Computation with label as border item
>>>>>>>>>> ---- right compartment
>>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>>
>>>>>>>>>> Both label kinds are border items located and clipped by the
>>>>>>>>>> compartment that their owner is inside. However, since the left and
>>>>>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>>>>>> right of the ones in the right compartment.
>>>>>>>>>>
>>>>>>>>>> Hallvard
>>>>>>>>>>
>>>>>>>>>>> - Cherie
>>>>>>>>>>>
>>>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>>>>>> IParser).
>>>>>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>>>>>> external label outside the parents?
>>>>>>>>>>>>
>>>>>>>>>>>> Hallvard
>>>>>>>>>>>>
>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #102501 is a reply to message #102352] |
Fri, 09 February 2007 09:19 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Cherie,
Thanks for your patience and suggestions. I've now been able to remove
the complexity of extra compartments that were only introduced to
handle layout, and instead use BorderItems.
>To work with the existing border item infrastructure in GMF, your border
>item editpart should implement IBorderItemEditPart and your border item
>container should implement IBorderedShapeEditPart. The
>AbstractBorderItemEditPart and AbstractBorderedShapeEditPart can be
>subclassed for ease of use or if this is not possible in your editpart
>hierarachy you could essentially copy the code from these classes.
I used the generated GateEditPart and GateLabelEditPart classes as
examples, and managed to make it work. As you suggested, I could
extend the two abstract classes. And by looking at the code, I could
understand more about how it worked.
> > 2) How will this affect the labels of the gates? Will they then be
> > able to float freely outside the gate and the parent interactor?
>Your label can be a border item of the gate. So your gate editpart
>would be a IBorderItemEditPart and a IBorderedShapeEditPart. Yes, if
>the gate is a child of the parent interactor, then the gate and its
>label should be able to float outside the parent interactor.
They do! I can move them around and it seems to me that the
BorderItems try to avoid each other (I was somewhere that they
implemented a kind of collision avoidance).
>Unfortunately, I don't know the generator enough to give you advice on
>how you can generate what I am suggesting, but it is always possible to
>modify the generated code if necessary. The labels around the gates
>should be no different then the labels on nodes in the Taipan example.
>I think they can move around too.
I guess the generator introduces the IBorderItemEditPart and
IBorderedShapeEditPart stuff when it notices that labels are external.
It would be very nice to be able to say (in gmfgraph) that a Node
should be a border item, so other elements than labels can be
generated as BorderItemEditParts (and their containers as
BorderedShapesEditParts). And perhaps also specify a custom
IBorderItemLocator. I guess this deserves a feature request.
Hallvard
|
|
|
| Re: External labels and their position in the figure hierarchy [message #102639 is a reply to message #102501] |
Fri, 09 February 2007 15:07 |
Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Glad to hear you got it all working!
> I guess the generator introduces the IBorderItemEditPart and
> IBorderedShapeEditPart stuff when it notices that labels are external.
> It would be very nice to be able to say (in gmfgraph) that a Node
> should be a border item, so other elements than labels can be
> generated as BorderItemEditParts (and their containers as
> BorderedShapesEditParts). And perhaps also specify a custom
> IBorderItemLocator. I guess this deserves a feature request.
I think you can specify that a node is a border item by setting the
affixedParentSide attribute of the border item node in .gmfgraph model.
I was playing with the generator a month or so ago and I'm pretty
sure I had this working.
- Cherie
Hallvard Trætteberg wrote:
> Cherie,
>
> Thanks for your patience and suggestions. I've now been able to remove
> the complexity of extra compartments that were only introduced to
> handle layout, and instead use BorderItems.
>
>> To work with the existing border item infrastructure in GMF, your border
>> item editpart should implement IBorderItemEditPart and your border item
>> container should implement IBorderedShapeEditPart. The
>> AbstractBorderItemEditPart and AbstractBorderedShapeEditPart can be
>> subclassed for ease of use or if this is not possible in your editpart
>> hierarachy you could essentially copy the code from these classes.
>
> I used the generated GateEditPart and GateLabelEditPart classes as
> examples, and managed to make it work. As you suggested, I could
> extend the two abstract classes. And by looking at the code, I could
> understand more about how it worked.
>
>>> 2) How will this affect the labels of the gates? Will they then be
>>> able to float freely outside the gate and the parent interactor?
>> Your label can be a border item of the gate. So your gate editpart
>> would be a IBorderItemEditPart and a IBorderedShapeEditPart. Yes, if
>> the gate is a child of the parent interactor, then the gate and its
>> label should be able to float outside the parent interactor.
>
> They do! I can move them around and it seems to me that the
> BorderItems try to avoid each other (I was somewhere that they
> implemented a kind of collision avoidance).
>
>> Unfortunately, I don't know the generator enough to give you advice on
>> how you can generate what I am suggesting, but it is always possible to
>> modify the generated code if necessary. The labels around the gates
>> should be no different then the labels on nodes in the Taipan example.
>> I think they can move around too.
>
> I guess the generator introduces the IBorderItemEditPart and
> IBorderedShapeEditPart stuff when it notices that labels are external.
> It would be very nice to be able to say (in gmfgraph) that a Node
> should be a border item, so other elements than labels can be
> generated as BorderItemEditParts (and their containers as
> BorderedShapesEditParts). And perhaps also specify a custom
> IBorderItemLocator. I guess this deserves a feature request.
>
> Hallvard
|
|
|
| Re: External labels and their position in the figure hierarchy [message #102655 is a reply to message #102352] |
Fri, 09 February 2007 15:19 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Cherie,
As mentioned, your suggestion worked well, I now have a working
implementation were Gates are BorderItemsEditParts. There's one
problem however: When dragging the Gate around, the feedback is OK,
but if the gesture ends outside the parent (very easily done) it
results in a reparent command. In general this makes sense, since the
child is dragged outside its parent. But when the child is a
BorderItemEditPart it will usually be on or outside the parent's
border, so almost every drag will end up reparenting the child! (This
doesn't happen for labels that are BorderItemEditParts, since
reparenting them makes no sense.)
The question then is: How do I avoid this? When the command is built,
many EditPolicys get the possibility of contributing a command to the
resulting CompoundCommand. After inspecting the resulting command, it
seems that it is composed of a MoveElementsCommand and the normal
ChangeBoundsCommand. I guess that the ChangeBoundsCommand is provided
by the EditPolicy for BorderItemEditParts. A natural solution is to
make the EditPolicy for BorderItemEditParts block other EditPolicies,
but how may this be done? An alternative is to make the EditPolicy
that contributes the MoveElementsCommand avoid BorderItemEditParts,
but how (which they should, in a generic solution)? Is it possible to
add an EditHelper that replaces the MoveElementsCommand with an empty
one?
Hallvard
On Thu, 08 Feb 2007 13:27:07 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>Hallvard,
>
> > 1) To make a gate into a border item, must my gate edit part and/or
> > figures subclass specific classes?
>To work with the existing border item infrastructure in GMF, your border
>item editpart should implement IBorderItemEditPart and your border item ,
>container should implement IBorderedShapeEditPart. The
>AbstractBorderItemEditPart and AbstractBorderedShapeEditPart can be
>subclassed for ease of use or if this is not possible in your editpart
>hierarachy you could essentially copy the code from these classes.
>
> > 2) How will this affect the labels of the gates? Will they then be
> > able to float freely outside the gate and the parent interactor?
>Your label can be a border item of the gate. So your gate editpart
>would be a IBorderItemEditPart and a IBorderedShapeEditPart. Yes, if
>the gate is a child of the parent interactor, then the gate and its
>label should be able to float outside the parent interactor.
>
>Unfortunately, I don't know the generator enough to give you advice on
>how you can generate what I am suggesting, but it is always possible to
>modify the generated code if necessary. The labels around the gates
>should be no different then the labels on nodes in the Taipan example.
>I think they can move around too.
>
>Regards,
>Cherie
>
>Hallvard Trætteberg wrote:
>> Cherie,
>>
>> On Tue, 06 Feb 2007 14:27:00 -0500, Cherie Revells
>> <crevells@ca.ibm.com> wrote:
>>> Given the way the border items work today, I would suggest you make your
>>> gates border items of the mailboxesView shape (is this what you are
>>> calling your process rectangle?). I'm not sure why you need three
>>> compartments.
>>
>> I probably don't need three compartments, you're right about that. The
>> ones on the left and right (seldom used) edges are only there for the
>> layout. I wasn't aware of the BorderItemLocators when I designed it
>> this way.
>>
>>> mailboxesView to hold the widget lists and inside triangles. Your gates
>>> can be children of the top-level mailboxesView shape, and you can
>>> control their location as you wish using a specialized locator.
>>
>> How do I model this with gmfmap? The nice thing about compartments is
>> that they know which kind of elements can be in them, so I get the
>> popup creation bar for free. If I remove the (definition of the) left
>> and right compartments and keep the middle one (which is restricted to
>> hold only certain elements), will the remaining children automatically
>> (by default) be placed withing the top-level interactor (process)
>> shape?
>>
>>> I think this would be the easiest way to accomplish what you want;
>>> however, I may be misunderstanding something about your diagram.
>>
>> Thanks for this suggestion! Two questions
>> 1) To make a gate into a border item, must my gate edit part and/or
>> figures subclass specific classes?
>> 2) How will this affect the labels of the gates? Will they then be
>> able to float freely outside the gate and the parent interactor?
>>
>> Hallvard
>>
>>> - Cherie
>>>
>>> Hallvard Trætteberg wrote:
>>>> On Mon, 05 Feb 2007 11:51:59 -0500, Cherie Revells
>>>> <crevells@ca.ibm.com> wrote:
>>>>
>>>>> Hallvard,
>>>>>
>>>>> I'm having a hard time visualizing your process node? Could you send a
>>>>> screenshot or mockup?
>>>> I screenshot is attached. On the left edge of the process rectangle
>>>> there are two triangles (what I called gates). You can see the clipped
>>>> labels to the left of the triangles ( '[' and ':-'). The top-level
>>>> process figure is a bit larger than the rectangle, to be able to
>>>> layout the compartment that the gates are within over the rectangle
>>>> edge. As mentioned, the structure is as follows:
>>>>
>>>> -- Process with compartments on each side and one in the middle
>>>> ---- left compartment on the rectangle edge
>>>> ------ Gate with label as border item
>>>>
>>>> Since the compartment containing the gates is so tight, it cannot
>>>> contain (and clip) the labels, hence the labels must be on the outside
>>>> (in the process figure's parent).
>>>>
>>>> If I'm allowed to somewhere decide how far up in the figure hierarchy
>>>> the label is placed, and be able to control it's life-cycle, I think I
>>>> could make it work. This requires a BorderItemLocator that correctly
>>>> handles the coordinates of labels that are far above the "owner".
>>>>
>>>> Hallvard
>>>>
>>>>> - Cherie
>>>>>
>>>>> Hallvard Trætteberg wrote:
>>>>>> Cherie,
>>>>>>
>>>>>> I have read the bugzilla discussion, and understand that the
>>>>>> implementation has changed from adding the labels to a separate layer
>>>>>> to inserting border items around the node. Visually this is very nice,
>>>>>> but the problem with the clipping remains: The labels don't float
>>>>>> freely, they are clipped by the node's parent. Hence, only parts of
>>>>>> the labels in the left and right compartments are visible, since the
>>>>>> compartments are sized based on the node shape without considering the
>>>>>> labels.
>>>>>>
>>>>>> A solution has to handle two issues: 1) the lifecycle of the label (it
>>>>>> should appear with the node shape and be removed with it) and 2) the
>>>>>> layout relative to the node shape. One possibility I've been
>>>>>> considering is as follows:
>>>>>> - The LabelEditPart has a method that determines how high up in the
>>>>>> figure hierarchy (above the node) the border item is located. This is
>>>>>> to ensure that the label is clipped high enough up to remain visible
>>>>>> (which depends on the particular diagram class).
>>>>>> - The LabelEditPart or the corresponding figure must make sure to also
>>>>>> remove the label, so the label's lifecycle corresponds to the node
>>>>>> shape's.
>>>>>> - the BorderItemLocator is changed to be able to place the label
>>>>>> relative to the node, even though the label may be further away from
>>>>>> the node in the hierarchy. The main issue here should be to correctly
>>>>>> translate the coordinates.
>>>>>>
>>>>>> Shouldn't this be feasible? The main problem I see is if this confuses
>>>>>> the figure that happens to host the border item. It must somehow have
>>>>>> a place for such BorderItems, similar to how the generated nodes
>>>>>> handle them (which is easier, since the node is aware of the label).
>>>>>>
>>>>>> Hallvard
>>>>>>
>>>>>> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>
>>>>>>> Hallvard,
>>>>>>>
>>>>>>> Did you read the comments in bugzilla 127491? It discusses the issues
>>>>>>> with having the labels on another layer.
>>>>>>>
>>>>>>> The border items should appear exactly as they did as if they were on
>>>>>>> another layer. In the implementation they are contained in the parent
>>>>>>> figure's bounds, but on the diagram the user will not see this.
>>>>>>>
>>>>>>> - Cherie
>>>>>>>
>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>> I think it is probably valid to say that if a compartment has a border
>>>>>>>>> item, then the parent's border should extend to hold the compartment's
>>>>>>>>> border item.
>>>>>>>> I thought the whole point of external labels was that they needn't be
>>>>>>>> within their parent's or grandparent's bounding box, i.e. that they
>>>>>>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>>>>>>> Taipan example) were put in their own layer?
>>>>>>>>
>>>>>>>>> You can create a bugzilla if you wish against the diagram
>>>>>>>>> runtime component.
>>>>>>>> I think I need to. Do you (or Dmitry) remember why the previous
>>>>>>>> implementation was discarded for the current one? Perhaps I could
>>>>>>>> reimplement something similar?
>>>>>>>>
>>>>>>>>> However, the issue can be solved using Dmitry's suggestion.
>>>>>>>> The number of ports is dynamic, so I cannot declare the port's labels
>>>>>>>> in gmfmap.
>>>>>>>>
>>>>>>>> Hallvard
>>>>>>>>
>>>>>>>>> - Cherie
>>>>>>>>>
>>>>>>>>> Dmitry Stadnik wrote:
>>>>>>>>>> I guess that's the limitation of border items - they are clipped by
>>>>>>>>>> their grandparent border. I think that in this case labels (ports)
>>>>>>>>>> should be defined for the Process node and special layout of Process
>>>>>>>>>> should place them close to compartments.
>>>>>>>>>>
>>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>>>>>>
>>>>>>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>>>>>>> My hierarchy is as follows:
>>>>>>>>>>> Diagram
>>>>>>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>>>>>>> middle
>>>>>>>>>>> ---- left compartment
>>>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>>> ---- middle compartment
>>>>>>>>>>> ------ Computation with label as border item
>>>>>>>>>>> ---- right compartment
>>>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>>>
>>>>>>>>>>> Both label kinds are border items located and clipped by the
>>>>>>>>>>> compartment that their owner is inside. However, since the left and
>>>>>>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>>>>>>> right of the ones in the right compartment.
>>>>>>>>>>>
>>>>>>>>>>> Hallvard
>>>>>>>>>>>
>>>>>>>>>>>> - Cherie
>>>>>>>>>>>>
>>>>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>>>>>>> IParser).
>>>>>>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>>>>>>> external label outside the parents?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hallvard
>>>>>>>>>>>>>
>>
|
|
|
| Re: External labels and their position in the figure hierarchy [message #102684 is a reply to message #102655] |
Fri, 09 February 2007 15:49 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
I found the hook I needed. The EditHelpers are called for semantic
edits like reparenting. By overriding the default implementation with
a method that returns null for Gates, I blocked moving Gates. Here's
the implementation that avoids moving Gates into Interactors (an empty
InteractorEditHelper class is automatically generated).
public class InteractorEditHelper extends DiamodlBaseEditHelper {
protected ICommand getMoveCommand(MoveRequest req) {
for (Iterator elements =
req.getElementsToMove().keySet().iterator(); elements.hasNext();) {
EObject element = (EObject)elements.next();
if (element instanceof Gate) {
return null;
}
}
return new MoveElementsCommand(req);
}
}
Puh! There's so many places to insert behavior and it takes a lot of
tracing to understand were to modify generated code to get the desired
effect!
Hallvard
On Fri, 09 Feb 2007 16:19:23 +0100, Hallvard Trætteberg
<hal@idi.ntnu.no> wrote:
>Cherie,
>
>As mentioned, your suggestion worked well, I now have a working
>implementation were Gates are BorderItemsEditParts. There's one
>problem however: When dragging the Gate around, the feedback is OK,
>but if the gesture ends outside the parent (very easily done) it
>results in a reparent command. In general this makes sense, since the
>child is dragged outside its parent. But when the child is a
>BorderItemEditPart it will usually be on or outside the parent's
>border, so almost every drag will end up reparenting the child! (This
>doesn't happen for labels that are BorderItemEditParts, since
>reparenting them makes no sense.)
>
>The question then is: How do I avoid this? When the command is built,
>many EditPolicys get the possibility of contributing a command to the
>resulting CompoundCommand. After inspecting the resulting command, it
>seems that it is composed of a MoveElementsCommand and the normal
>ChangeBoundsCommand. I guess that the ChangeBoundsCommand is provided
>by the EditPolicy for BorderItemEditParts. A natural solution is to
>make the EditPolicy for BorderItemEditParts block other EditPolicies,
>but how may this be done? An alternative is to make the EditPolicy
>that contributes the MoveElementsCommand avoid BorderItemEditParts,
>but how (which they should, in a generic solution)? Is it possible to
>add an EditHelper that replaces the MoveElementsCommand with an empty
>one?
>
>Hallvard
>
>On Thu, 08 Feb 2007 13:27:07 -0500, Cherie Revells
><crevells@ca.ibm.com> wrote:
>
>>Hallvard,
>>
>> > 1) To make a gate into a border item, must my gate edit part and/or
>> > figures subclass specific classes?
>>To work with the existing border item infrastructure in GMF, your border
>>item editpart should implement IBorderItemEditPart and your border item ,
>>container should implement IBorderedShapeEditPart. The
>>AbstractBorderItemEditPart and AbstractBorderedShapeEditPart can be
>>subclassed for ease of use or if this is not possible in your editpart
>>hierarachy you could essentially copy the code from these classes.
>>
>> > 2) How will this affect the labels of the gates? Will they then be
>> > able to float freely outside the gate and the parent interactor?
>>Your label can be a border item of the gate. So your gate editpart
>>would be a IBorderItemEditPart and a IBorderedShapeEditPart. Yes, if
>>the gate is a child of the parent interactor, then the gate and its
>>label should be able to float outside the parent interactor.
>>
>>Unfortunately, I don't know the generator enough to give you advice on
>>how you can generate what I am suggesting, but it is always possible to
>>modify the generated code if necessary. The labels around the gates
>>should be no different then the labels on nodes in the Taipan example.
>>I think they can move around too.
>>
>>Regards,
>>Cherie
>>
>>Hallvard Trætteberg wrote:
>>> Cherie,
>>>
>>> On Tue, 06 Feb 2007 14:27:00 -0500, Cherie Revells
>>> <crevells@ca.ibm.com> wrote:
>>>> Given the way the border items work today, I would suggest you make your
>>>> gates border items of the mailboxesView shape (is this what you are
>>>> calling your process rectangle?). I'm not sure why you need three
>>>> compartments.
>>>
>>> I probably don't need three compartments, you're right about that. The
>>> ones on the left and right (seldom used) edges are only there for the
>>> layout. I wasn't aware of the BorderItemLocators when I designed it
>>> this way.
>>>
>>>> mailboxesView to hold the widget lists and inside triangles. Your gates
>>>> can be children of the top-level mailboxesView shape, and you can
>>>> control their location as you wish using a specialized locator.
>>>
>>> How do I model this with gmfmap? The nice thing about compartments is
>>> that they know which kind of elements can be in them, so I get the
>>> popup creation bar for free. If I remove the (definition of the) left
>>> and right compartments and keep the middle one (which is restricted to
>>> hold only certain elements), will the remaining children automatically
>>> (by default) be placed withing the top-level interactor (process)
>>> shape?
>>>
>>>> I think this would be the easiest way to accomplish what you want;
>>>> however, I may be misunderstanding something about your diagram.
>>>
>>> Thanks for this suggestion! Two questions
>>> 1) To make a gate into a border item, must my gate edit part and/or
>>> figures subclass specific classes?
>>> 2) How will this affect the labels of the gates? Will they then be
>>> able to float freely outside the gate and the parent interactor?
>>>
>>> Hallvard
>>>
>>>> - Cherie
>>>>
>>>> Hallvard Trætteberg wrote:
>>>>> On Mon, 05 Feb 2007 11:51:59 -0500, Cherie Revells
>>>>> <crevells@ca.ibm.com> wrote:
>>>>>
>>>>>> Hallvard,
>>>>>>
>>>>>> I'm having a hard time visualizing your process node? Could you send a
>>>>>> screenshot or mockup?
>>>>> I screenshot is attached. On the left edge of the process rectangle
>>>>> there are two triangles (what I called gates). You can see the clipped
>>>>> labels to the left of the triangles ( '[' and ':-'). The top-level
>>>>> process figure is a bit larger than the rectangle, to be able to
>>>>> layout the compartment that the gates are within over the rectangle
>>>>> edge. As mentioned, the structure is as follows:
>>>>>
>>>>> -- Process with compartments on each side and one in the middle
>>>>> ---- left compartment on the rectangle edge
>>>>> ------ Gate with label as border item
>>>>>
>>>>> Since the compartment containing the gates is so tight, it cannot
>>>>> contain (and clip) the labels, hence the labels must be on the outside
>>>>> (in the process figure's parent).
>>>>>
>>>>> If I'm allowed to somewhere decide how far up in the figure hierarchy
>>>>> the label is placed, and be able to control it's life-cycle, I think I
>>>>> could make it work. This requires a BorderItemLocator that correctly
>>>>> handles the coordinates of labels that are far above the "owner".
>>>>>
>>>>> Hallvard
>>>>>
>>>>>> - Cherie
>>>>>>
>>>>>> Hallvard Trætteberg wrote:
>>>>>>> Cherie,
>>>>>>>
>>>>>>> I have read the bugzilla discussion, and understand that the
>>>>>>> implementation has changed from adding the labels to a separate layer
>>>>>>> to inserting border items around the node. Visually this is very nice,
>>>>>>> but the problem with the clipping remains: The labels don't float
>>>>>>> freely, they are clipped by the node's parent. Hence, only parts of
>>>>>>> the labels in the left and right compartments are visible, since the
>>>>>>> compartments are sized based on the node shape without considering the
>>>>>>> labels.
>>>>>>>
>>>>>>> A solution has to handle two issues: 1) the lifecycle of the label (it
>>>>>>> should appear with the node shape and be removed with it) and 2) the
>>>>>>> layout relative to the node shape. One possibility I've been
>>>>>>> considering is as follows:
>>>>>>> - The LabelEditPart has a method that determines how high up in the
>>>>>>> figure hierarchy (above the node) the border item is located. This is
>>>>>>> to ensure that the label is clipped high enough up to remain visible
>>>>>>> (which depends on the particular diagram class).
>>>>>>> - The LabelEditPart or the corresponding figure must make sure to also
>>>>>>> remove the label, so the label's lifecycle corresponds to the node
>>>>>>> shape's.
>>>>>>> - the BorderItemLocator is changed to be able to place the label
>>>>>>> relative to the node, even though the label may be further away from
>>>>>>> the node in the hierarchy. The main issue here should be to correctly
>>>>>>> translate the coordinates.
>>>>>>>
>>>>>>> Shouldn't this be feasible? The main problem I see is if this confuses
>>>>>>> the figure that happens to host the border item. It must somehow have
>>>>>>> a place for such BorderItems, similar to how the generated nodes
>>>>>>> handle them (which is easier, since the node is aware of the label).
>>>>>>>
>>>>>>> Hallvard
>>>>>>>
>>>>>>> On Fri, 02 Feb 2007 10:47:50 -0500, Cherie Revells
>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>
>>>>>>>> Hallvard,
>>>>>>>>
>>>>>>>> Did you read the comments in bugzilla 127491? It discusses the issues
>>>>>>>> with having the labels on another layer.
>>>>>>>>
>>>>>>>> The border items should appear exactly as they did as if they were on
>>>>>>>> another layer. In the implementation they are contained in the parent
>>>>>>>> figure's bounds, but on the diagram the user will not see this.
>>>>>>>>
>>>>>>>> - Cherie
>>>>>>>>
>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>> On Thu, 01 Feb 2007 11:41:36 -0500, Cherie Revells
>>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>>> I think it is probably valid to say that if a compartment has a border
>>>>>>>>>> item, then the parent's border should extend to hold the compartment's
>>>>>>>>>> border item.
>>>>>>>>> I thought the whole point of external labels was that they needn't be
>>>>>>>>> within their parent's or grandparent's bounding box, i.e. that they
>>>>>>>>> were free-floating. Wasn't that the reason they originally (e.g. in
>>>>>>>>> Taipan example) were put in their own layer?
>>>>>>>>>
>>>>>>>>>> You can create a bugzilla if you wish against the diagram
>>>>>>>>>> runtime component.
>>>>>>>>> I think I need to. Do you (or Dmitry) remember why the previous
>>>>>>>>> implementation was discarded for the current one? Perhaps I could
>>>>>>>>> reimplement something similar?
>>>>>>>>>
>>>>>>>>>> However, the issue can be solved using Dmitry's suggestion.
>>>>>>>>> The number of ports is dynamic, so I cannot declare the port's labels
>>>>>>>>> in gmfmap.
>>>>>>>>>
>>>>>>>>> Hallvard
>>>>>>>>>
>>>>>>>>>> - Cherie
>>>>>>>>>>
>>>>>>>>>> Dmitry Stadnik wrote:
>>>>>>>>>>> I guess that's the limitation of border items - they are clipped by
>>>>>>>>>>> their grandparent border. I think that in this case labels (ports)
>>>>>>>>>>> should be defined for the Process node and special layout of Process
>>>>>>>>>>> should place them close to compartments.
>>>>>>>>>>>
>>>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>>>> On Wed, 31 Jan 2007 10:09:18 -0500, Cherie Revells
>>>>>>>>>>>> <crevells@ca.ibm.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Pre-M4, the labels were generated like they are in the Taipan Example
>>>>>>>>>>>>> -- on another layer. However, there were some issues with this
>>>>>>>>>>>>> approach, so now they are generated as border items. See bugzilla
>>>>>>>>>>>>> 127491 for a complete discussion if you are interested.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As to your problem, is the label a border item of the top level shape?
>>>>>>>>>>>> My hierarchy is as follows:
>>>>>>>>>>>> Diagram
>>>>>>>>>>>> -- Process with three compartments, one on each side and one in the
>>>>>>>>>>>> middle
>>>>>>>>>>>> ---- left compartment
>>>>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>>>> ---- middle compartment
>>>>>>>>>>>> ------ Computation with label as border item
>>>>>>>>>>>> ---- right compartment
>>>>>>>>>>>> ------ Gate (port) with label as border item
>>>>>>>>>>>>
>>>>>>>>>>>> Both label kinds are border items located and clipped by the
>>>>>>>>>>>> compartment that their owner is inside. However, since the left and
>>>>>>>>>>>> right compartments are very narrow (just wide enough to contain the
>>>>>>>>>>>> gates), the gate labels are almost invisible. I want the labels to be
>>>>>>>>>>>> hanging left (as a default) of the gates in the left compartment and
>>>>>>>>>>>> right of the ones in the right compartment.
>>>>>>>>>>>>
>>>>>>>>>>>> Hallvard
>>>>>>>>>>>>
>>>>>>>>>>>>> - Cherie
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hallvard Trætteberg wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm trying to define a label for an object that is located in a narrow
>>>>>>>>>>>>>> compartment along the side of its parent. Since the compartment is
>>>>>>>>>>>>>> narrow and anyway on the side of the parent, it seems reasonable that
>>>>>>>>>>>>>> the label is external, to ensure that it is not limited by the
>>>>>>>>>>>>>> compartment's or parent's bounding boxes. Thus, the label figure is
>>>>>>>>>>>>>> defined outside the object's figure. However, the label still is
>>>>>>>>>>>>>> placed inside the compartment and is clipped accordingly. I've looked
>>>>>>>>>>>>>> at the code generated for the Taipan example, and there the edit parts
>>>>>>>>>>>>>> for objects with external labels has code that is not generated in my
>>>>>>>>>>>>>> case, and that is clearly related to inserting external label figures
>>>>>>>>>>>>>> in a separate layer. There's also a reference to a layer that seems to
>>>>>>>>>>>>>> be for this purpose, that I don't find in the code that is generated
>>>>>>>>>>>>>> for my gmfgen model. The only difference compared to the Taipan
>>>>>>>>>>>>>> example is that my label is not a feature label (I provide my own
>>>>>>>>>>>>>> IParser).
>>>>>>>>>>>>>> If I look at the gmfgen model, my label is shown as an External Node
>>>>>>>>>>>>>> Label. So what remains to make GMF generate code that places the
>>>>>>>>>>>>>> external label outside the parents?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hallvard
>>>>>>>>>>>>>>
>>>
|
|
|
Goto Forum:
Current Time: Wed Feb 05 09:54:30 GMT 2025
Powered by FUDForum. Page generated in 0.06076 seconds |
] 
Search
Help
Register
Login
Home
