Holding down Ctrl key while drawing a line has no effect

English
#1

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.
I plan to report this behaviour as a bug via bugzilla, but maybe a workaround or special setting exists?

Klick on Insert Line
Cursor changes to crosshair
Press and hold Ctrl
Cursor changes back to default arrow
press and hold left mouse button
drag mouse to draw a line: no effect
release left mouse button
Release Ctrl
Cursor changes to crosshair

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

#2

worked OK for me as you described (same version but on Debian 12). The only difference I think is that I was pressing the left mouse button rather than just “drag the mouse” with the endpoint for me coming when releasing the left mouse button… unless of course I misunderstood your description of what you were doing.
I also looked at this resoource for guidance.

#3
  • Instead of reporting a bug, it may be more successful to put a post in the documentation forum.
    It may be that the bug is not in the program, but in the guide.

In page 32 there are also some notes about this behavior

Notes:
If the option View > Snap Guides > Snap to Grid on the Menu bar has been
selected, holding down the Ctrl (macOS ) key while drawing a straight line⌘
temporarily deactivates the Snap to Grid option.

If the option When creating or moving objects in the Constrain Objects section of
Tools > Options > LibreOffice Draw > Grid (macOS LibreOffice > Preferences >
LibreOffice Draw > Grid) has been selected, holding down the Shift key
temporarily deactivates this restriction.

Draw classifies both lines and arrows as lines and are created in the same way as
straight lines. Hovering the cursor over each tool in the Lines and Arrows subtoolbar
(Figure 22 on page 34), or the Line and Arrows panel in the Shapes deck on the
Sidebar, indicates what type of line or arrow each tool draws. The information field on
the Status Bar shows them only as lines.

#4

It worked as described in the guide, up to LO 3.3 / OOo 3.3. But in LO 3.4 / AOO 3.4, it changed to what you see now. It co-incided with a change in the default grid subdivisions (1 vs. 10); I actually very much suspect, that it’s an unintended side effect (regression), that got unnoticed for so long.

And well, it’s good to file bugs without much thinking; and definitely it’s better to file a bug for something that turned out a documentation issue, than to file a documentation issue for what actually was a bug (imagine, that documentation people see that yes, the documentation is not correct wrt current situation; they correct the documentation - and that cancels the hope that the problem gets fixed).

#5

Your observations are not clear if

  • It really is a program bug and documentation has been modified to adapt to that bug
  • Or if it is not a bug and the problem is that the documentation is not clear.

In any case, I think that notifying the documentation forum is a necessary option.
Maybe who writes the documentation knows or investigates where the problem is

#6

It is a bug. And as I wrote, it doesn’t matter. Documentation team should only be notified, if it is confirmed not a bug, but a documentation issue.
And no, “who writes the documentation” does not (have to) know and investigate; otherwise, why would we have a bug tracker? We would report everything to “who writes documentation”. I don’t think @ohallot would disagree.

(And that was actually a regression from commit d8cba2db6ae4a6a073621215515aec6f0c4fc606, where it was done for a purpose, with the goal to use Alt; but it didn’t work out.)

1 Like
#7

Correct.
We don’t document failures (bugs) nor experimental features.

#8

Alt currently restricts the drawing angle of a line as described in DrawGuide page 31 5)
Changing Ctrl to Alt would be in conflict with 5)?

#9

Hmm, as far as I see, Alt doesn’t - it makes it symmetrical relative to starting point (i.e., makes the starting point the center of newly drawn object); Shift limits angles. But anyway, the conflict is what I referred to, when wrote “it didn’t work out”.

The problem that the commit attempted to solve was the conflict between Ctrl as “toggle snap” and Ctrl as “copy object” (when you are dragging an existing object, as opposed to drawing new one). IMO, it would better re-assign Alt to “copy object” modifier - because it isn’t used there, as far as I see. But well; we can currently try to fix it e.g. by using either Alt or Ctrl to toggle snap, depending on if we are dragging an existing object, or drawing a new one.

However, this is getting too long. All I wrote, needed to get into a bug report, as a discussion of the possible solution. Writing it here is wasting time. If there is no bug report, I’m done here.

#10

Thank you for explaining me the conflict which led to the commit from 2010.
Bug 167810 has been successfully created

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.