Skip to content
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

Add nodeEdit mode #46

Merged
merged 12 commits into from Aug 31, 2019
Merged

Add nodeEdit mode #46

merged 12 commits into from Aug 31, 2019

Conversation

Sedictious
Copy link
Contributor

This adds most of the features of node edit mode:

  • Right click on a node to remove it
  • Left click to add a node (left clicking on a node still opens up the respective inspector)
  • Drag any node to move it
  • If a selected node is dragged, then every selected node will move along with it

@@ -100,7 +100,7 @@ void GridView::paintFrame(QPainter& painter) const
}
}

Node GridView::findNode(const QPointF& pos) const
Node GridView::findNode(const QPointF& pos)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why removing the const?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we may want to move the node by changing it's coordinates, so const would throw a compilation error. selectNode wouldn't work, since we may want to move the node without adding it to our current selection. Maybe it would make more sense to rename findNode to getNode?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, any "find" or "get" function should be const
it seems that you are mixing two different concepts here: 1) const function, 2) const return

any getter/finder function should be const because it should never ever change a member variable

could you revert this change please? (i.e., make this function const)

@@ -97,6 +98,7 @@ void BaseGraphGL::setup(AbstractGraph* abstractGraph, AttributesScope nodeAttrsS
m_nodeAttrsScope = nodeAttrsScope;
setupInspector();
updateCache();
m_attrs = m_abstractGraph->node(0).attrs();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should consider the case in which m_abstractGraph has no nodes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is called only after the graph model is initialized so it shouldn't be a problem since we already check whether the number of nodes is not zero. But this must change if we allow to add nodes before generating a graph model

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, this function can also be called with a null abstractGraph; in this scenario, this call would cause a crash. For instance, see BaseGraphGL::slotRestarted():

setup(nullptr, AttributesScope());

could you fix this line please? (i.e., only assign the attrs() if m_abstractGraph is not null and if !m_abstractGraph->nodes().empty())

updateCache();
}

void BaseGraphGL::createNode(QPointF pos)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const QPointF& pos

updateCache();
}

void BaseGraphGL::deleteNode(QPointF pos)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const QPointF& pos

updateCache();
}

void BaseGraphGL::moveNode(Node& node, QPointF pos) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const QPointF& pos

@@ -101,7 +101,7 @@ CacheStatus GraphView::refreshCache()
return CacheStatus::Ready;
}

Node GraphView::findNode(const QPointF& pos) const
Node GraphView::findNode(const QPointF& pos)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

selectedStar.edges.push_back({ep.second, line});
}
}
selectedStar.edges.shrink_to_fit();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not an efficient approach; we should not be computing things in a "draw" function
actually, we should compute the coordinates only when the object is selected (or when something changes in the view)
(note that m_selectedStars is not being used after your change --- why?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still looking into this (and that's why I didn't remove m_selectedStars)

While m_selectedNodes is automatically updated when moving a node, m_selectedStars is not, since it doesn't hold a pointer to the node that we're changing. That would mean that when moving a group of selected nodes, the viewport wouldn't respond to them moving. Maybe a signal could be emitted whenever there was a need to re-calculate the node coordinates which would call something like updateSelectedStars

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cardinot
I updated it to utilize signals but I was wondering whether this is memory-safe or I need to explicitly delete the replaced star (or change its attributes in-place)

@@ -147,32 +149,34 @@ void BaseGraphGL::slotDeleteSelectedNodes()
updateCache();
}

void BaseGraphGL::createNode(QPointF pos)
void BaseGraphGL::createNode(const QPointF pos)
Copy link
Member

@cardinot cardinot Aug 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pos should be passed as a const reference, i.e., const QPointF&
(the same for all other calls)

selectedStar.edges.push_back({ ep.second, line });
}
}
selectedStar.edges.shrink_to_fit();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this approach isn't very efficient either
because you'll always end up looping through all nodes twice

actually, this code is mostly a copy&paste from createStar(). Could we just call the createStart() function straight away when it's needed? (i.e., instead of emitting the nodesMoved() signals)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we just call the createStart() function straight away when it's needed? (i.e., instead of emitting the nodesMoved() signals)

Hm not sure I quite get that. Do you mean to refactor this without using signals?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, there's no gain in using the signal&slot in this case

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My main point here is that your "slotUpdateSelection" is just a copy&paste from "createStar"; we don't need to duplicate this code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reformatted a bit as to directly call createStar, but I still can't see a more efficient way to call the UpdateSelection. This can't be called directly from the painting methods and neither can it not be called each time a node is moved. What am I missing?

@cardinot cardinot merged commit 6e2f064 into evoplex:socis19 Aug 31, 2019
@cardinot cardinot added this to In Progress in graph designer via automation Sep 7, 2019
@cardinot cardinot moved this from In Progress to Done in graph designer Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants