| Problems with figure order [message #1755807] |
Wed, 08 March 2017 10:55  |
 Thomas Thonhofer
Messages: 25
Registered: July 2013 |
Junior Member |
|
|
Hi everyone
I have a project where I implement an editor with the Graphiti framework, which uses GEF 3. I encountered a problem with changing the drawing order of my graphical elements. I already posted it on the Graphiti forum but it might be more of a GEF issue.
I want to change the order in which the figures in my editor are drawn, in order to bring certain figures to the front, so they are completly visible. To achieve this I change the order of the model elements. After doing that, the next time the root editpart is refreshed, the order of the editpart children is updated to the new order in the method refreshChildren() in the class AbstractEditPart. For all editparts which need to be reordered it calls the method reorderChild(EditPart editpart, int index). This method then removes the draw2d figure and adds it at the index of the moved editpart. This works fine if there is an editpart for each figure and vice versa, but Graphiti adds figures which do not belong to an editpart. This means that there are more figures than editparts as children of the root elment, which means that inserting a new figure at the index of the last editpart, does not insert it at the last position, causing it not to be drawn on top.
Is it ok to add figures which are not connected to an editpart? If not, this is a bug in Graphiti. If it is ok, I would say it is a flaw in GEF. Would it be possible to fix this in GEF 3? Is the behaviour still the same in the current version of GEF? Any ideas for a fix or workaround would be very appreciated.
Thanks,
Thomas
|
|
|
| Re: Problems with figure order [message #1755869 is a reply to message #1755807] |
Wed, 08 March 2017 18:23  |
|
Hi Thomas,
GEF-Legacy (3.x) and GEF (5.x) only provide support for the visualizations that are controlled by the parts (edit parts / visual parts). All other visualizations are controlled by the users themselves. For the purpose of managing the visualizations, GEF-Legacy provides the template methods AbstractEditPart#addChildVisual(childPart, index) and #removeChildVisual(childPart) that can be implemented to respect additional constraints related to the visualization. This mechanism is also available in GEF, where the methods AbstractVisualPart#doAddChildVisual(...) and #doRemoveChildVisual(...) serve the same purpose.
So, if I understand correctly, it should be possible to circumvent the issue by respecting the uncontrolled visuals in the implementation of #addChildVisual(...). Generally, GEF cannot decide if the custom visuals should be at the first or last position (or somewhere in-between). Therefore, you need to implement that logic yourself. After all, the visuals of the last edit part will be atop the visuals of the previous edit parts, i.e. the controlled visuals behave as expected.
Best regards,
Matthias
|
|
|
Powered by
FUDForum. Page generated in 0.02772 seconds
] 
Search
Help
Register
Login
Home
