Holding Shift, Ctrl or Alt while dragging changes what the drag does, in
about twenty different ways, and almost none of it is discoverable. Two
appear in the status bar once a drag is already under way; the rest are
written down nowhere. keyboard_control covers the opposite problem --
working without a mouse -- so none of this was on the wiki.
Compiled by reading every Shift/Ctrl/Alt site in the source, 66 of them,
rather than from the ones I happened to know:
- Ctrl means "ignore the grid" everywhere, because the check lives inside
Diagram::snapToGrid() itself rather than at each call site, and it
rounds to the nearest pixel rather than freeing the position entirely.
- Shift on an element's own text moves the label instead of the element.
- Shift/Ctrl/Ctrl+Shift while drawing a rectangle or ellipse give square,
from-centre, and centred-square; centre-anchoring is decided at the
first click and deliberately not re-checked mid-drag.
- Alt on a shape's corner handle converts it to a polygon; Alt on a path
node or curve handle changes the node kind.
- Shift snaps rotation, skew and arc angles to 15 degrees.
- Alt+arrows nudge by the fine grid, Ctrl+arrows realign a text group.
- Ctrl+Shift is reserved by DiagramView for its own mode switch, so it is
not available as a modifier combination.
Two behaviours are called out as changing, with the open PR named rather
than described as working: element text not snapping (#927) and the text
tool having no cancel (#928).
Linked from _Sidebar.md and cross-linked with keyboard_control both ways.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
Document F10, keyboard Ajouter menu, real context menu, paste-follows-cursor
Four recently-merged PRs (#875-878, all 2026-09-15/16) directly extend
this page's topic and weren't reflected:
- F10 opens the menu bar (#877), alongside the existing Alt route.
- Edition -> Ajouter puts every drawing tool in a menu (#875) -- narrows
but doesn't close the 'drawing needs a mouse' gap: reaching the tool
is now keyboard-driven, placing its points still isn't.
- The keyboard-raised context menu now builds the real per-selection
menu instead of falling back to a generic, mostly-disabled one (#876).
- Ctrl+V paste now follows the cursor with Enter/left-click to commit,
Escape/right-click to cancel (#878) -- a genuine full keyboard path
to duplicate an element already in the project, narrowing the
headline gap to specifically an element's first appearance.
Verified each claim against current source before writing:
qetmainwindow.cpp (F10 QShortcut), qetdiagrameditor.cpp (Ajouter
submenu contents), diagramview.cpp (contextMenuEvent keyboard-reason
branch), diagrameventaddpaste.cpp (Return/Enter/Escape/right-click
handling).
Checked directly against ShortcutManager's registry, the menu
mnemonics, and the diagram/element editor keyPressEvent() handlers --
not assumed from the UI. States the one real gap plainly: placing a
new element from the Collections panel still requires a mouse drag,
verified by checking what double-click actually does there (opens
the Element Editor, not placement).
Linked from _Sidebar.md under Guides and cross-linked with
tips_and_tricks.md's existing shortcut list.
ispyisail