aaron@...749... wrote:
bulia byak wrote:
On 1/5/06, aaron@...749... <aaron@...749...> wrote:
No, I too insist on it. And to make matters worse your Con is my Pro. :) You say "screen based snapping units stop the snapping from jumping across the screen at high zoom." I say "Document based snapping units allow me to enforce alignment to a grid even at high zoom."
As jiho has just explained, getting this enforcement is just a matter of a very high sensitivity, no matter what units. Will you be satisfied by a 2000 screen pixel sensitivity, which enforces snapping at ANY zoom?
I will be satisfied by the functionality, until the resolution of my monitor increases beyond that. :) I had thought that document units made more sense because it doesn't require one to switch domains, first thinking about the size of the grid in document units and then thinking about screen pixels. But given that, it actually would require less thought if the interface was cluttered with an "Enforce snapping to grid" checkbox, which I believe had been suggested before.
And the switching domains is part what my argument had been about (things remaining in the same unit, the other part would be it remaining relative to scale). Bulia, please also recognize that A) only a small fraction of our users participate on the lists and B) that you can be VERY intimidating to people that don't know you... So, making an argument based on how many people speak up is far from an accurate method to gage things. In addition to that, it almost seems like when you ask these questions on the list, you do it as a formality only with no intention of it potentially making a difference in what you have planned. Your argument is always "you still haven't convinced me", and the reality is, you're about as easy to convince as talking to a devout religious person of a different faith about why your religion/beliefs is/are just as valid as theirs is. So, pardon me if this message has any emotion tied to it (specifically the end).
In the last message I wrote, I had mentioned a few friends of mine (that don't even do email, much less participate on the lists) that desire keeping absolute units as well. Two of them specifically work with metal and wood (note the "blue collar" nature of their work). They are far from what you would consider tech savvy. And truthfully, they don't know and have no need to know what a pixel is... they just need Inkscape to keep working like it has. In the real world, they most commonly work in inches or millimeters (or whatever measurement their clients request), and therefore in the "virtual" realm when they're making templates in Inkscape they're using those same units. One issue other the "pixel" unit being useless and meaningless to them is that when they're working with angles or curves, the grid (which you keep bringing up in this discussion) is of little or no use to them. For note, over the past few weeks they've really grown fond of the new object and node snapping stuff (as opposed to bbox that they used before).
When it comes to working with Inkscape, the absolute units make sense. Snapping with absolute units (other than pixel) also makes sense to them. You had mentioned that having snap change with zoom makes as much sense as the cursor changing being scaled with zoom, which is an inaccurate comparison. I'd liken it more to working with a map and the Scale "meter" not magnifying with the rest of the map. According the map, a km is a km is a km, and it stays relevant to the level of magnification. Let's use military troops as an example for this. If any of my troops are within .3 km of either point A, B, or C, I want them to go to that point. If they're not within that .3 km, they can stay where they are. If my map is just a world map, .3 km is impossible to see... however if it's scalable to the point where I can differentiate by .01km, it becomes more workable. And if I'm zoomed in to see that .01km, .3km will be nice and gigantic, and [drum roll please] it will make sense (since it's what I set).
As one of my friends had pointed out, if he moves his face closer or further away from a piece of wood (in the physical world of course), it doesn't change what size the measurement is. If he marks the start and end of an inch on a board and moves his face really close to it, the inch looks bigger (as our rulers and canvas work). Therefore he would expect that if he sets .0625 (1/16th) inches for snapping, that it scales with the zoom level and rulers (moving the face closer/further in relation to the virtual board). He also said that if he stands at arms length away from the board and tries to do something useful in that small of an increment, it's just not possible and it shouldn't be, some things require getting in close to do detail. Absolute units (with regard to snapping) in Inkscape give him the same "feel" for the scale of things as if he were working in the physical world.
It does feel like this last ditch attempt at trying to make the point that different users use inkscape differently and they also don't all think the same, will fall on deaf ears. From what a few other users (those friends) have communicated to me, it's not just myself that thinks in units other than screen pixels with regard to snapping. Whatever, this was probably a waste of my time and energy... so fine, I concede... forget absolute units with snapping... I'll retrain myself and teach those friends all about pixels. If you guys have no use for them, obviously no one else should and anyone that does is just dumb or otherwise not "clued in" to your superior understanding of what /should/ make sense to them.
I guess part of my frustration stems from the fact that this feature already existed and is useful to some users (even if it is a niche). In reality, (just like the real world where minorities don't matter... unless you're one of them) perhaps the best solution would be a key combo or whatever to toggle object snapping only as Bulia had briefly mentioned before. This way they won't worry about snapping at far distances, and when they need to use it, it will be easy enough to toggle on and off.
Note: I didn't have a chance to proof read before sending, sorry for any incomplete thoughts.
-Josh