Description: I tried to snap ends of a straight line to the nearest grid point, holding down the Ctrl key while drawing a straight line as described in the LibreOffice DrawGuide 25.2 on page 31 point 4) No line is drawn at all. Shift 5) and Alt 6) work as described, but Ctrl has no effect. Steps to Reproduce: 1. Klick on Insert Line Cursor changes to crosshair 2. Press and hold Ctrl Cursor changes back to default arrow 3. press and hold left mouse button drag mouse to draw a line: no effect release left mouse button 4. Release Ctrl Cursor changes to crosshair Actual Results: No line is drawn at all, neither snapped to grid nor not snapped to grid. Expected Results: line drawn with endpoints snapped to grid Reproducible: Always User Profile Reset: No Additional Info: see https://ask.libreoffice.org/t/holding-down-ctrl-key-while-drawing-a-line-has-no-effect/125118/6?u=computerdoktor Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Thank you for reporting the bug. I can not reproduce the bug in Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: fi-FI (fi_FI); UI: en-GB Calc: CL threaded Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 04bd455e36b054001e08a0a3256d508a009ffef3 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: fi-FI (fi_FI); UI: en-GB Calc: CL threaded
(In reply to joehtg from comment #0) Is the Standard toolbar's 'Snap to Grid' button selected enabled, or not? If it is selected enabled, then the <Ctrl> is supposed to "toggle" the snap behavior disabled. Not clear it is supposed to enable snap when the tb button is unchecked, but the DG documentation suggests so. Either way the <Ctrl> does not seem to toggle the snap to grid. Unlike the <Alt> and <Shift> behaviors during line draw that expands line centered on origin or line draw at fixed 45° orthogonal increments--both of which honor the tb "snap to grid" toggle setting. And, to grid is notable as choppy progress as either line is extended--though resolution of the grid does not match the "visible" grid value (Tools -> Options -> Draw -> Grid). I agree with Mike K. from the Ask article there is a long present bug here, not really the DG documentation. That is, the Toolbar button works to enable/disable snap to grid, while the <Ctrl>+<mouse> does not perform its toggle.
As mentioned in the Ask question, this changed in commit d8cba2db6ae4a6a073621215515aec6f0c4fc606. The rationale was explained in https://wiki.openoffice.org/wiki/BetterDefaults_GridHandling_workout : > 8. Snap to Grid shortcut: new 'Snap to Grid' shortcut (if 'StG' is off and you > move an object it snapes if you press the ctrl button simultaneous): change > shortcut from 'ctrl' to 'alt' key > -> ctrl belongs to 'copy when moving' I.e., the use of Ctrl for both drag-copy and toggle-snap functions conflicted, hence the change. Unfortunately, this didn't consider the existing use of Alt in another mode, which is not "drag existing object", but "draw new object". It would be better, if back then, they changed drag-copy shortcut to Alt; then, the (ideal) situation would be: 1A. Draw new object: Ctrl = toggle snap; Alt = draw from center; 2A. Drag existing object: Ctrl = toggle snap; Alt = copy. At this point, the (current) situation is: 1B. Draw new object: Ctrl = nothing; Alt = draw from center AND toggle snap; 2B. Drag existing object: Ctrl = copy; Alt = toggle snap. We can also consider the following (suboptimal IMO) change: take the mode into account, and use different keys for toggle snap: 1C. Draw new object: Ctrl = toggle snap; Alt = draw from center; 2C. Drag existing object: Ctrl = copy; Alt = toggle snap. The last option, while inconsistent (one would have to use different buttons for one task, depending on mode), has the advantage of taking current more used key into account: admittedly, the lack of toggle snap wasn't noticed for long; while drag-copy using Ctrl was used all this time. My personal preference would be bite the bullet, and do A; but I think that UX must decide.
Somehow I omitted another solution: 1D. Draw new object: Ctrl = draw from center; Alt = toggle snap; 2D. Drag existing object: Ctrl = copy; Alt = toggle snap. I.e., change "draw from center" from Alt to Ctrl, which would likely be the best - it would keep Ctrl for copy, which, I feel, would be least disruptive.
And last bit. The shape of cursor when pressing Ctrl, when not yet pressed the mouse, is just a cosmetic issue. It is a legitimate thing, but needs to be tracked separately.