Am 16.12.2017 um 01:24 schrieb Maren Hachmann:
Am 15.12.2017 um 23:36 schrieb Eduard Braun:
Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
I always felt this Alt/Shift thing was a convention - Ctrl always *restricts* (direction, angle), Shift is for *large steps* (scale, move), and Alt is for *small steps*. This pattern repeats for inset, outset, moving objects, nodes, scaling various things, see https://inkscape.org/en/doc/keys092.html
So Alt for small steps is totally logical to me.
But that's exactly my point: It's not working like that (it's only - wrongly? - documented like that)! If I open Inkscape at the then default zoom level of (35%) the Alt key causes *larger* steps.
- It doesn't for me ... ? Opened Inkscape with new document, drew
rectangle, switched to select tool, used Alt+Arrow > small steps, used Shift+Arrow > big steps. Maybe we have discovered a new Windows-only bug? Or which functionality/shortcut did you try?
I compared Arrow (without modifier) and Alt + Arrow. The modifier-less variant resulted in smaller steps (0.529 mm) than the variant with Alt (0.756 mm). Holding Shift additionally will multiply by ten in both cases (i.e. 7.559 mm and 5.292 mm respectively).
The problem (or at least the behavior that always confused me) is that the variant with alt changes with the zoom level (i.e. at 70% zoom instead of 35% zoom I get 0.378 mm steps which is exactly half the step size from above). I'd have to look into the code to understand what is going on here, but Alt + Arrow certainly does not seem to move "by one px". If I had to guess it might mean "1 px on the monitor" but that seems like a pretty arbitrary value that will not likely relate to any lengths in the document...).
Personally I've actually given up using modifiers to move objects as I found it to be unpredictable and typically set numerical values manually when I need precise positioning and can't use snapping for some reason.
- I use Alt+arrows as well as Shift+arrows happily. But of course, for
me they work ;-)
All the color sliders (probably the most used ones?) do not allow any control at all. Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.
If we make this a convention (and try to follow it) I'm fine with it, but I hate inconsistent UI that is said to follow conventions that people only *think* exist (because they somehow got used to the quirks) but basically does whatever it wants in most cases leaving users who actually try with logic out in the rain.
- I understand (and feel similarly, consistency is great :) )
The "Ctrl restricts movement" is a valid argument and I would like if it could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32 steps in 256 value slider).
On Linux, to be able to use Alt+Click and many other shortcuts, you need to deactivate Alt as a Window management key anyway (admittedly, that's not nice, we have an extra FAQ item for it...), so I don't really see a new issue here. Alt+Click is even more important than small steps in some slider, and it's only available when you change your window management settings.
I'm not sure what you're saying here? As an ignorant Windows user I'm hearing "most Linux users are not able to use the Alt key anyway, so why bother? those who figure out how to make it usable can probably figure out what it does, too"... If it really is that hard to get it working - should we really rely on it for central functionality we want to add to a new widget?
- It's that I don't consider the slider extra tricks as important as
Alt+Click for normal use (there's no simple replacement for Alt+Click, but there's a number entry for the slider) - so, I mean, we are already making it hard for users to access important functionality, what's this in comparison?
It is already problematic now (it's not Linux directly, but some window management systems that use Alt+Click for moving windows, maybe Alt+Drag also doesn't work by default, but not sure), and those who need advanced functionality will have that setting changed already. It seems to be an issue with other graphics applications as well (e.g. Blender and Maya seem to be affected by this choice, too).
Those who haven't changed the setting (or don't know about it) will miss out on both functions (or even more), yes. Usually, people notice when they want to select an object that is below another one, after reading documentation. And yes, that's sad... But it's hard to change that shortcut after the fact...
I personally find the consistency more important here - but I understand if you don't agree.
Maren
Maren
Am 15.12.2017 um 20:00 schrieb Eduard Braun:
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
And where can I find a control in Inkscape that follows this "convention"? If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt). If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.
The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
* No modifier = default increment * Alt = move by 1 pixel instead of default increment according to keys and mouse reference However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier * Shift = increase amount by 10 (can be used in any combination)
Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...
If in the end we really have no convention it might be a good time to think about one!
Best Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel