Community
Participate
Working Groups
I've provided external node labels in models and on diagram as it was stated in #122054 but a number of open issues remain: 1. I have to insert one more layer for the external node labels; maybe it should be done by runtime? 2. It's possible to select and remove external node label; that differs from the link label 3. When node is removed external label remains, should not 4. External node labels are not gray as link labels 5. Labels jumps on layout without animation
Some questions: - Is the label a child node of the parent? - Is the editpart provided for the label of type LabelEditPart? (1.): what do you mean insert layer? Adding a figure to the content pane? (2.): this is by design to allow users to remove clutter. Labels can be made revisible by using the "Show / Hide Labels" action in the toolbar. To override this behavior - change the EditPolicy.COMPONENT_ROLE on the LabelEditPart to not respond to the delete view request. (3.): can't explain this behavior without knowing more about your implementation. (4.) They will inherit the font style attributes of the parent... (5.) Sounds like a general defect for labels. I think just adding a LayoutAnimator listener to the parent layout manager of the label will fix this.
Created attachment 35090 [details] modified taipan with external port label Here is a modified TaiPan example; Port node has external label.
moved to M6
Descoped from M6. May be still be considered if time permits...
Now there is a 'live' example in TaiPan - port name.
Created attachment 45102 [details] Simple patch for "stuck" external labels This is a simple patch for #3 problem (external labels not removed with the parent node). This is not a runtime problem.
Created attachment 45107 [details] FIXED patch for external labels Sorry, overlooked an extra return statement. This patch works quite well for me and doesn't introduce new bugs. This still doesn't mean that it is 100% correct, of course. I may have well missed some intricate details.
I've submitted the patch; thanks!
I recently hit a problem with the TaiPan example, namely that Print and Print Preview don't work, as described here: http://www.eclipse.org/newsportal/article.php?id=4054&group=eclipse.technology.gmf#4054 I hit this problem after changing the Printing Enabled setting to true in taipan.gmfgen. After I posted a question about the resulting NullPointerException, Artem Tikhomirov suggested a possible root cause of this issue is the use of the External Label feature in the Taipan example. So I'm appending to this bug, hope that was the right thing to do.
The reason for NPE mentioned in #9 is absense of layer for external labels, issue #1 from the list above.
Hi Dmitry. The Runtime Team's solution to having external labels on nodes is to use the border item infrastructure. That is, the label would be a border item around the node. This would require modifications to your port node editpart and obviously the label editparts. Are you against these types of changes? Did you put the labels on a separate layer for a reason other than just to get it working? This might be a better solution as the Runtime Team is supporting cases where external labels are border items so any fixes we make in this area would benefit generated GMF diagrams as well. If this is something you would consider pursuing, I can look into modifying the Taipan Example to see if I could get it working using the border item infrastructure.
The idea was to provide labels for nodes similar to labels for links; so user may drag the label around the host node and place it at the desired distance from it. Border items can be moved along node border but not a pixel away from it, isn't it? This limitation comes from the fact that border items reside in a special container figure for node figure and border items provided by node edit part; to overcome this I add dedicated layer for external labels. I think that concept of floating labels is applicable for nodes too and thus have submitted this request. I know that it's possible to use border items and tooling should be able to generate code that allows external label to be a border item but this is just another option not implemented yet.
It is possible to have border items floating around nodes just like your external labels. I have seen this done in a client application. Basically, the LabelEditPart's figure would be added to the BorderItemContainerFigure of the owner node (just like border items), but the locator would place the label anywhere around the shape. We could probably add more support in the GMF runtime to make this easier to use in the generator. For example, we could have a FloatingLabelLocator in the GMF runtime that could be used. The known issues (that I am aware of) with having the labels on another layer are: - Labels jumps on layout without animation -- Does not occur with label figures within the BorderItemContainerFigure probably because of this code in BorderedNodeFigure: borderItemContainer.addLayoutListener(LayoutAnimator.getDefault()). Could probably be fixed by adding a LayoutAnimator as Steve suggested to the labels layer (?) similar to this. - Print and Print Preview doesn't show the external labels -- This is most likely because the external labels layer is installed in the generated DiagramEditor.configureGraphicalViewer() method and an editor is not created when printing the diagram. Instead, the OffscreenEditPartFactory is used to create the contents of the GraphicalViewer. In order to fix this, you would need to move the installation of the external labels layer to a DiagramRootEditPart that the generated code provides instead of in the generated diagram editor. - Save as Image doesn't show the external labels -- This seems to be because GMF's DiagramGenerator contains code to specifically add figures from other layers (see findDecorations() and findConnectionsToPaint()) so there most likely needs to be code in here to handle the external labels layer. Connections and decorations are on separate layers like the generated external node labels. There are still some issues with these that we have not solved, and the generated external labels will most likely have the same issues: - If you have one node on top of another node, the top shape covers the bottom shape. Labels on the bottom shape will always be on top. This is similar to: Bug111956 Ability to have connections respect z-order and having shape overlap Bug164124 Decorations show through an overlapping shape - I have not tried putting a node with a label inside a shape compartment. Have you tried this yet? I am guessing this will lead to some problems if you have not addressed them already. You will need to handle hiding the label when the compartment is collapsed. You will need to hide the label if its node is outside of the visible area of the compartment. We have handled some of these issues with our decorations (see Decoration.isVisible() and our connections (see ShapeCompartmentEditPart.ConnectionRefreshMgr). You will probably need to do something similar for the external labels layer. In other words, there is not a generic solution for these figures on separate layers. One of our GMF clients is using the border item infrastructure for external node labels and we have been making fixes to support any issues that have come up with this. Printing, copy to image, scrolling all works now. Mohammed has recently fixed a number of issues relating to this (although the code hasn't been submitted yet): 161215 Scrollpanes do not consider space occupied by border items 161466 Bordered figures do not updated page breaks Some of the border item code may still be a little 'clunky' and perhaps could be implemented a bit better, but we are committed to supporting these so we will make fixes in the future as required. So have I convinced you yet to implement these node labels in a different way? :-) I will try to get a small example working for you.
The solution with layer was rather a 'prototype' influenced by connection labels since I thought that border items are locked to the parent border. At least javadoc in BorderItemLocator clearly states that ))) I have no objections to use border items and will rewrite templates accordingly. https://bugs.eclipse.org/bugs/show_bug.cgi?id=164935
I just tried this out in the mindmap example to make sure that I wasn't lying. I tried modifying a generated external node label to add it's figure to the BorderItemContainerFigure instead of the external nodel label layer. I also modified the XLabelEditPart so that it extends LabelEditPart and not MindmapExtNodeLabelEditPart. Everything seems to work fine with this simple change. The LabelLocator installed in LabelEditPart is used to locate the label. I'm not quite sure that you want to treat the LabelEditParts as IBorderItemEditParts, or just add the label figures to the BorderItemContainerFigure. I did not make the XLabelEditPart an IBorderItemEditPart and it does not have an IBorderItemLocator. I think this makes sense, but I'm not 100% sure. This means that these labels will not be treated as real border items: they will not have BorderItemSelectionEditPolicy installed (this makes sense), they will not be selected in a Select All (not sure if this makes sense). Anyways, let me know if you have any issues that need to be addressed in the runtime.
I am closing this bugzilla since the behavior will be changed in the generator. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=164935.
[target cleanup] 2.0 M4 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
