QGIS » QGIS Application

Hi Patrick,
thanks for raising your issues, 3.0 is a major release and some changes are radical, I agree with that, and since release schedule for 3.0 as been moved a lot, we now have a higher step than before. Polishing 3.0 won't be an easy task but changes pushed in here have been discussed via QEP, lists, issues before, or even with prototypes and most of them are worth fixing it.

But now someone has decided to be clever and put the Move function into Node editing so if you aren't sure where the node is and you don't click on it (and believe it or not the nodes are not very easy to see all of the time) then you end up dragging the line instead of the node then you have to drag the line back and that still hasn't helped you move the node you were trying to move.

With the same build number, I can't confirm that, I still have a move line and a node tool. I don't see any more recente commit related to that neither. Can you share some screencast to help use reproduce that and narrow it down? It might be a bug.

Attached what a node looks like, hard to see, in the old version you could just click on the line and all the nodes would turn into squares, easier to see, now it will only highlight them if you hover the mouse, so you click the Pan button and drag the map then to get the nodes highlighted you have to then click the node edit button and hover the mouse over the line, then to pan you have to click the pan button again and then repeat, so a whole lot more steps are needed.

In settings, nodes can be tuned for all or only selected features. You can make it a cross, a square or or circle, change its size and color. This hasn't changed a all
When hovering with the new node tool, colors and symbols but that's not what you seem to point out with your screenshot.

While I think you've worded your issue poorly and very insensitively, you've done the right thing in flagging these issues and bringing them to the attention of the team. We need feedback like this before release to ensure that the new tool implementation is rock solid and ready for release.

Prior to introducing this tool a long process was conducted:
- first a proposal was submitted for comment (see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/69)
- a python based plugin for 2.x mimicing the proposed behavior was created (https://github.com/wonder-sk/CadNodeTool) so that interested users could test and give feedback

Based on feedback obtained from both these steps the UX of the new tool was heavily refined. And it's still being refined prior to release.

So it's definitely not "someone playing around", but instead a highly involved process with extensive community feedback. (Incidentally: I suggest you should subscribe to the qgis user/developer mailing lists and the proposals github repo so that you can give your feedback on changes like this early).

This thing is supposed to be freezing for release in a month and it has new bugs in it? Where do you stop introducing new bugs and focus on fixing old ones?

After freeze - that's the whole purpose of setting this "freeze" period in place. Freeze is not the release - freeze is a pre-release period in which we concentrate only on bug fixes. Until then it's open for any changes, new features, etc, (and developers jumping in and playing around with whatever they feel like just to make things hard for users ;)... oh wait... I mean "developers and daily users making changes based on user requirements and community feedback to refine QGIS behavior".)

Anyway, freeze is still a long time off, and the issues will be addressed in the post freeze period. Can you refine your issue to indicate what you feel the corrections need to be?

Patrick Dunford wrote:

This thing is supposed to be freezing for release in a month and it has new bugs in it? Where do you stop introducing new bugs and focus on fixing old ones?

See roadmap

Hey, I'd love to spend some time looking at this, the problem is at the moment, my computer keeps running out of memory due to issue #17119.

So at the moment I have to keep editing on older masters that don't implement this change.

I am looking at it now but it will take some time to evaluate all the differences. But, this is not just some kneejerk reaction to a new user feature. I have tried it a few times, and each time it's a big step, or learning curve, from the previous interface (2.18 for example, since there have been a number of different changes in this development project. I end up wanting to do one thing and end up making changes I never intended to because it tries to reduce the number of clicks to do each step.

I can see it does some things like extending a line a lot easier (a much desired feature) compared to previous editions, but this has to be compared with whether it also makes it easier to make a mess by accidentally dragging things that you never intended to drag.

Patrick Dunford wrote:

I am looking at it now but it will take some time to evaluate all the differences. But, this is not just some kneejerk reaction to a new user feature. I have tried it a few times, and each time it's a big step, or learning curve, from the previous interface (2.18 for example, since there have been a number of different changes in this development project. I end up wanting to do one thing and end up making changes I never intended to because it tries to reduce the number of clicks to do each step.

I can see it does some things like extending a line a lot easier (a much desired feature) compared to previous editions, but this has to be compared with whether it also makes it easier to make a mess by accidentally dragging things that you never intended to drag.

I understand your point, but this is by design, not a bug per se. And discussing choices made on purpose by devs is best done on the users and developers mailing lists, not in the bug tracker. Please raise your concerns there. Thanks!