-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify boundingBox #9
Comments
That would be really nice for re-layouting of compound nodes children. |
When the following is resolved, this can be implemented using that feature (a virtual compound including everything): #6 |
Would this also allow configure my layout to take better advantage of a rectangular container (desktop screen)? |
Yes, you could define this "virtual" compound containing everything in the dimensions that you desire. However, notice that you would have to specify dimensions not aspect ratio, and you would need to make sure the dimensions are big enough to accommodate the entire content. |
It's usually best to let a layout, like CoSE, just run and figure out how much space it needs. It fits to the screen with scaling (zoom) anyway. A bounding box is really only useful for particular usecases (usually subgraphs). |
@maxkfranz Ah, you're right. I hitched my bandwagon to an issue that I thought was related to the cola layout. I'm currently using the cose-bilkent layout, which does indeed fit the space, but was hoping to discover whether the cola layout might be capable of achieving a similar result. Speaking from my own personal use case, I find myself wishing that I could constrain the "aspect ratio" of the final positions of the nodes so that there is an efficient usage of visual space for non-square canvases, such as is the case for most desktop (landscape shape) and mobile (portrait shape) devices. I've achieved some semblance of this idea with the cose-bilkent layout, but I would love to use cola instead, as it appears to be superior in many ways. |
It is actually perfectly reasonable to input aspect ratio of the screen in which the graph is to be displayed to the layout algorithm and get the layout respecting that aspect ratio. An aspect ratio respected by the layout algorithm means the graph objects being analyzed can be displayed larger and become more visible. As I said current cose-bilkent doesn't support this though. I do have ideas on how this could be achieved with cose-bilkent but we just don't have the resources to try it out at the moment. |
I just wanted to check if you have plans to implement bounding box for cose-bilkent? We have a very specific use case where we have to be able to draw even completely random graphs for 4-20 nodes. Most of the time cose-bilkent works fine, but sometimes it creates graphs that are impossible or very hard to read on a small screen: Adding bounding box functionality would be great as it would ensure the nodes are always big enough and nodes use the screen estate more evenly. -- From your comment @ugurdogrusoz I got the impression that this might be a viable option? |
@pkovanen I didn't mean cola can take an aspect ratio and address your concern. What I meant was perhaps with some constraints you can achieve what you need. I am talking about constraints like such and such nodes must be horizontally aligned, etc. |
Ok, already had a look at the latest fcose - however since the data we have present is random I'm having hard time using the provided constraints to achieve what I am looking for. My only need is utilizing more of the screen size for the graph. |
Layouts usually have a
boundingBox
option so that the area in which the layout is run can be specified/constrained. This is useful when running layouts on subsets of the graph, e.g.eles.layout()
.It would be nice to have this feature in CoSE Bilkent.
Avoiding overlap with nodes can contradict the bounding box (i.e. the bounding box may not have enough room to prevent node overlap). In that case, it's OK to overflow the bounding box. However, there is usually an option so the dev can decide (i.e.
avoidOverlap
: ontrue
avoids node overlap and might overflow the bounding box, onfalse
respects the bounding box but nodes might overlap).The text was updated successfully, but these errors were encountered: