Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Eclipse Layout Kernel » Changing node order (bring to front)
Changing node order (bring to front) [message #1746635] Wed, 02 November 2016 10:52 Go to next message
Olaf Donk is currently offline Olaf DonkFriend
Messages: 7
Registered: June 2016
Junior Member
Hi,

as part of a the logic of a custom layout algorithm I'd like to change the order of some nodes. More precisely, some nodes should overlap partially and the right ones should be brought 'to front'. Instead of having the user right click every node, can this be done programmatically in the layout algorithm?

Thanks! Olaf
Re: Changing node order (bring to front) [message #1746638 is a reply to message #1746635] Wed, 02 November 2016 11:43 Go to previous messageGo to next message
Christoph Daniel Schulze is currently offline Christoph Daniel SchulzeFriend
Messages: 68
Registered: September 2015
Member
Hi Olaf!

The layout algorithm has no control over how your graph is going to be displayed, so it cannot change the Z order all by itself. What you can do is this:


  1. Have the layout algorithm compute a Z order.
  2. Declare a new layout option for your algorithm. It should be an output option, since your algorithm will use it to output additional data. The data type will probably be int, which is a natural way to represent the Z order. This page has more details on how to do that.
  3. Write a custom layout connector for your editor / viewer that knows how to apply the Z order layout property back to your view model in its applyLayout(...) method. See this page for details.


Hope this helps.

Cheers,
Christoph Daniel
Re: Changing node order (bring to front) [message #1746642 is a reply to message #1746638] Wed, 02 November 2016 12:32 Go to previous messageGo to next message
Olaf Donk is currently offline Olaf DonkFriend
Messages: 7
Registered: June 2016
Junior Member
Okay, makes sense, thanks! I'm not sure yet how to implement/hookup that custom layout connector, but I'll do my homework first Wink

Cheers, Olaf
Re: Changing node order (bring to front) [message #1746760 is a reply to message #1746638] Fri, 04 November 2016 10:11 Go to previous messageGo to next message
Olaf Donk is currently offline Olaf DonkFriend
Messages: 7
Registered: June 2016
Junior Member
Okay, I've been doing my homework and I'm a bit puzzled at this point Confused

After reading the documentation (a second... and a third time) and giving the proposed solution some thought I realized that I could use properties as well for another question I have: how to access some diagram related info inside my algorithm to tune the algorithm's behavior based on different types of nodes.

So as first step I added one property to begin with and that works fine: I declared it's existence and a default value in the .elkm file and I have it available in my algorithm. I plan to add the output property for the Z order in a next step.

Then I implemented a very basic connector, using the empty auto-generated stubs. Of course the algorithm doesn't work anymore using empty stubs, but the breakpoints in both buildLayoutGraph and applyLayout get hit, so I assumed (maybe wrongly, see below) I injected this connector correctly.

Now as I just want to add one or two properties in buildLayoutGraph and process this one Z order property in applyLayout, I rather reuse an existing implementation than writing both methods from scratch. So as a next step I've made my empty stubs extend GmfDiagramLayoutConnector and call the respective supers in the two methods. I based my choice of the GmfDiagramLayoutConnector on values I got while debugging the flow while executing my algorithm without having a custom connector injected.

And now much to my surprise the layout is not using my algorithm anymore. Breakpoints in the connector still work, but in the algorithm they're not hit , so it's not that the algorithm itself is not working correctly, but it doesn't get executed at all.

I guess I'm doing something wrong with the dependency injection. To begin with I assumed the injection of the custom algorithm was totally independent of the injection of the connector, but maybe this is not correct? A bit of help at this point would be much appreciated Smile

Best, Olaf
Re: Changing node order (bring to front) [message #1751107 is a reply to message #1746760] Wed, 04 January 2017 14:16 Go to previous messageGo to next message
Christoph Daniel Schulze is currently offline Christoph Daniel SchulzeFriend
Messages: 68
Registered: September 2015
Member
I'm sorry, Olaf, I didn't see your message here. I kind of expect the newsgroup to notify me of changes, which it obviously was not set up to do automatically... :/

Olaf Donk wrote on Fri, 04 November 2016 10:11

After reading the documentation (a second... and a third time) and giving the proposed solution some thought I realized that I could use properties as well for another question I have: how to access some diagram related info inside my algorithm to tune the algorithm's behavior based on different types of nodes.


Yes, that's pretty much what properties are for. By the way, if you have any suggestions on how the documentation can be made clearer, I'd be more than happy to listen! Smile

Olaf Donk wrote on Fri, 04 November 2016 10:11

Now as I just want to add one or two properties in buildLayoutGraph and process this one Z order property in applyLayout, I rather reuse an existing implementation than writing both methods from scratch. So as a next step I've made my empty stubs extend GmfDiagramLayoutConnector and call the respective supers in the two methods. I based my choice of the GmfDiagramLayoutConnector on values I got while debugging the flow while executing my algorithm without having a custom connector injected.


If you want to customize how the layout graph is generated for a GMF-based editor, this is what you would do, yes.

Olaf Donk wrote on Fri, 04 November 2016 10:11

And now much to my surprise the layout is not using my algorithm anymore. Breakpoints in the connector still work, but in the algorithm they're not hit , so it's not that the algorithm itself is not working correctly, but it doesn't get executed at all.

I guess I'm doing something wrong with the dependency injection. To begin with I assumed the injection of the custom algorithm was totally independent of the injection of the connector, but maybe this is not correct? A bit of help at this point would be much appreciated Smile


The layout algorithm should not be injected in any way. Once your diagram layout connector is called, the layout process has already begun. What ELK wants your connector to do is to give ELK a configured graph structure it can work with. Once that is supplied, your layout connector is out of the picture for a while. Then ELK takes over again and checks which layout algorithm needs to be executed. It determines that by looking at the graph's top node's CoreOptions.ALGORITHM property. Thus, make sure that your layout connector sets that option to the ID of your layout algorithm. Then everything should work fine. If no algorithm is set, ELK will by default call the ELK Layered algorithm.

Does that make sense?
Re: Changing node order (bring to front) [message #1751453 is a reply to message #1751107] Tue, 10 January 2017 13:54 Go to previous messageGo to next message
Olaf Donk is currently offline Olaf DonkFriend
Messages: 7
Registered: June 2016
Junior Member
No worries, Christoph, and thanks for your reply. In the end I got things working and we have a prototype algorithm working. Which already saves us tons of time and is by the way as far as we would like to get at this point. I must admit that I don't recall the exact step needed to solve the issue anymore. But I'm planning to distill some notes (and test them...) based on our prototype in the coming weeks so I'll probably encounter the magical details pretty soon Wink If relevant I'll let you know so you can check if you feel something can be added to the documentation.
Re: Changing node order (bring to front) [message #1751459 is a reply to message #1751453] Tue, 10 January 2017 14:29 Go to previous messageGo to next message
Christoph Daniel Schulze is currently offline Christoph Daniel SchulzeFriend
Messages: 68
Registered: September 2015
Member
Olaf, it's good to hear that things are working out. Smile Yes, I would be very interested in that, thank you!
Re: Changing node order (bring to front) [message #1751677 is a reply to message #1751459] Thu, 12 January 2017 12:16 Go to previous messageGo to next message
Olaf Donk is currently offline Olaf DonkFriend
Messages: 7
Registered: June 2016
Junior Member
Allright, I got my notes collected. Christoph, is there a way I can send you some information? I'd rather not put these notes on a publicly available link just yet Wink
Re: Changing node order (bring to front) [message #1751685 is a reply to message #1751677] Thu, 12 January 2017 13:41 Go to previous message
Christoph Daniel Schulze is currently offline Christoph Daniel SchulzeFriend
Messages: 68
Registered: September 2015
Member
Sure, feel free to send me an e-mail: cds at informatik.uni-kiel.de
Previous Topic:Overlapping "Edge Label" with "Edge Labels"/Nodes
Next Topic:Best practice for resizing nodes with very much in/outgoing edges
Goto Forum:
  


Current Time: Sat Aug 18 01:17:10 GMT 2018

Powered by FUDForum. Page generated in 0.01929 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top