5 is still a release candidate. I think there’s still time for some minor tweaks to get in there before 6.
Even if it’s totally rewritten from scratch, I assume that they’ll be trying to maintain a lot of the same behaviours as is in 5 at the time they get there while fixing some places where they might have painted themselves into corners in the past.
I think there’s some value to users letting the devs know our perspectives on things regardless. It’s easy to get too close to your project and internalize workarounds and behaviours, at which point you can miss a lot of simple things that could be big improvements in usability.
Whether anyone will be focused on those kind of small fixes/tweaks is a different question, but I’d rather not assume there isn’t.
bobc:
Yes, I would assume (and hope) that they don’t plan on scrapping the UI entirely for a completely different model. Generally those kinds of things result in trading one set of problems for another.
I think “intuitive” is not entirely useless, though you’re probably right that a lot of people read it the same as “easy to use”, so maybe it doesn’t get the point across.
The main issue is “internal consistency”. A UI should work in ways that you would expect, based on the way other things in the UI work.
In this specific case (wires snapping to labels) they don’t.
All three of the left resistors were “g” moved down .1". The first is what happens if there’s a label on the line.
The 3rd is what happens if there’s any part on the line.
The middle one is what I think should happen. given how things behave elsewhere.
A harder example to screenshot is is you G a horizontal trace with a label on it, in which case the label does stick.
I think that this would be a relatively simple way of getting a consistent (intuitive) behaviour with no negative effects I can see.
Maybe someone can point one out that I’m missing?
IMO, longer term we should have some kind of 90 degree dog legging where instead of diagonal lines, you would get steps like near pin 5 on my example, but obviously this would require a lot more effort (dealing with intersecting corners, overlaps, etc).
But looking forward to the eventuality of that happening, I think we would still want that corner to happen such that it doglegs at “bar”, instead of at a random location which may or may not leave “foo” behind.
paulvdh: You’re entirely missing the point. I understand how to do all these things with blocks, g moves, etc. It’s exactly what I’ve been doing, while seeing a lot of places where things could be improved.
It shouldn’t require “tricks” to do things efficiently.
That would be a time saver, but it’s a little ugly.
An improvement on the idea would be if those junctions weren’t junctions, but simply nodes (without the dot which implies an intersection), and they be placed .050" horizontal from the pins on each component. Then they could still shoot a similar diagonal, but you would have a pair of points for your “step 4” without the dots. In implementation this would likely be better, since it could be implemented without a special case for diagonal vs horizontal. Horizontal “g” moves could still generate the nodes exactly the same way, and they would automatically vanish just like any other time you straighten out a trace.
I do fear that we’re drifting off of the topic again, though, which is specifically the behaviour regarding labels.
I don’t think that treating them like other symbols/pins messes with any of the other functionality discussed, and it should actually make some other improvements easier.
Any thoughts on that?