New nodes are added very far away from existing ones

[yurivict]

After I ran qsynth the graph looks like this:

I had to zoom out to find the new node. Now it has to be moved manually.

qjackctl places nodes very far from existing ones.
It should choose a more reasonable position.

Eben if the item of the same kind has been previously added - the previous position should be ignored when it is far from currently displayed nodes. (I am not sure if that's what the problem is.)

I remember reporting this a while ago, but somehow the problem is still there.

qjackctl-0.9.10
FreeBSD 13.1

[rncbc]

please, for once and every time an old node comes into that far, probably because its position was saved on previous runs, bring all the nodes closer together and quit--their last positions will be saved and the whole scene will be shorter/narrower, placing new nodes under closer limits the next time you run qjackctl.

a radical suggestion would be to start on a brand new conf file (~/.config/rncbc.org/QjackCtl.conf); or, on a less radical one, edit the conf file and remove the whole [GraphNodePos] section only. (IMPORTANT: do any of this only when qjackctl is NOT running)

[yurivict]

[...] an old node comes into that far, probably because its position was saved on previous runs [...]

But this isn't a desirable behavior. This node may have been a part of a 300-node graph before and therefore it may have been far away. And now it is a part of a 3-node graph. Its previous position should be ignored in such case.

[rncbc]

it can't (be ignored), unless you remove its old position (prolly from old previous qjackctl:graph versions which were, say virtually boundless...)

[yurivict]

it can't (be ignored) [...]

Why? You can just ignore it in the code.

[rncbc]

that's not the point: it was saved before (don't know when in time) with some position--doesn't matter how far or close it was--and [qjackctl:graph] has no other option than honor that position. sorry.

go with the radical or the not so radical suggestions.

[yurivict]

[...] has no other option than honor that position. sorry.

What prevents it from having another option?

[rncbc]

the other option has already been posed: erasing its memory in the conf file.

[yurivict]

the other option has already been posed: erasing its memory in the conf file.

But the point is that erasing config file isn't a user-friendly way. Simple users would be terrified and challenged by this.