Grid size and element size
Elements from different sub-collections — or different authors — can look very different in size next to each other on the same folio, even though they all snap correctly to the same grid. New users sometimes read this the way model railway modellers read gauges: N, HO, and O scale are all "the same kind of thing" (a train) drawn at deliberately different, named miniaturization ratios. QET has no equivalent. There is no small set of named element scales, and no dialog anywhere that lets you pick one. What exists instead is one grid unit (a spacing convention, not a physical size) and a shipped collection where every author picked their own multiple of it. This page explains both halves: the grid itself, and why symbol size still varies as much as it does.
Source: sources/diagram.cpp, sources/diagram.h, sources/editor/elementscene.cpp,
sources/ui/configpage/generalconfigurationpage.cpp.
1. The diagram grid
The folio grid is a set of dots at regular intervals, purely for visual
alignment and mouse-snap — it carries no unit of measurement (not mm, not
inches). Six settings control it, all under QSettings key prefix
diagrameditor/:
| Setting | QSettings key | Default | Controls |
|---|---|---|---|
| X grid spacing | Xgrid |
10 | horizontal dot spacing / snap step |
| Y grid spacing | Ygrid |
10 | vertical dot spacing / snap step |
| X keyboard-nudge step | key_Xgrid |
10 | how far → and ← move a selection |
| Y keyboard-nudge step | key_Ygrid |
10 | how far ↑ and ↓ move a selection |
| X fine-nudge step | key_fine_Xgrid |
1 | → / ← step while the fine-movement modifier is held |
| Y fine-nudge step | key_fine_Ygrid |
1 | ↑ / ↓ step while the fine-movement modifier is held |
All six are exposed on the General page of Edit → Preferences (see Preferences reference §1, "Grid and keyboard movement"). The in-app spin boxes cap X/Y grid spacing at 1–30; there is no upper cap in the underlying setting itself, only in that dialog.
Two more settings — grid_pointsize_min and grid_pointsize_max, both
defaulting to 1 — control how thick the grid dots are drawn, ramped between
the two values as you zoom in from 100% up to 500% (Diagram::drawGrid()).
This is purely cosmetic: it does not change spacing or snap behaviour, only
how visible the dots are at a given zoom level.
Mouse-drag movement always snaps to Xgrid/Ygrid, independent of the
keyboard-nudge settings above; Ctrl while dragging bypasses the snap. See
Mouse modifiers for the full modifier table. One
exception is tracked as a bug: dragging a dynamic element text (the text
attached to an element, under the cursor) does not snap at all, unlike every
other draggable text or item — reported upstream as
issue #923.
If a device label refuses to land on the grid after a drag, this is why.
2. Element size: how the element editor enforces the grid
The element editor (Edit element / drawing your own symbol — see
Using the element editor) works on its own 1×1 fine
grid by default (ElementScene::setGrid(1, 1)), letting you place a line
or terminal at any integer coordinate while you draw. That fine positioning
does not carry over to the saved element, though:
On save, ElementScene rounds the element's bounding box up to the next
multiple of 10 in both width and height (with an extra +10 if the
remainder already exceeds 6, so it rounds to the nearer multiple of 10,
not always up):
int upwidth = ((qRound(size.width())/10)*10)+10;
if ((qRound(size.width())%10) > 6)
upwidth += 10;
and the same for height. The padding needed to reach that size is split out
as a margin, and the whole element is written to .elmt with width and
height attributes that are always multiples of 10 — the same 10 that is
the diagram grid's default spacing. That is why an element's hotspot and its
terminals always land on a diagram grid intersection once it's placed on a
folio, regardless of how finely you drew it: the file format itself only
ever stores multiples of the diagram's grid unit.
If you've changed Xgrid/Ygrid away from 10, note that the element
editor's own rounding is still hard-coded to 10 — an element built on a
folio with a 12-unit grid, say, will not necessarily land back on that
grid's intersections.
3. Why element size still varies so much
Rounding to a multiple of 10 says nothing about which multiple. A survey
of the shipped elements/ collection (8,838 .elmt files) shows every
<definition> width/height is indeed a multiple of 10 — but the multiple
chosen ranges enormously:
| Element | File | Size (grid units) |
|---|---|---|
| Mechanical lock (auxiliary symbol) | 10_electric/98_graphics/01_auxiliary_symbols/verrouillage-meca.elmt |
20 × 20 |
| WAGO 750-1606 I/O module | 10_electric/20_manufacturers_articles/wago/.../wago_0750-1606-0040-0000.elmt |
740 × 110 |
That's a 35× difference in linear footprint between two ordinary elements,
both perfectly grid-aligned. It isn't an outlier: dimension pairs like
30×30, 40×20, 60×60, and 140×310 are all common across the
collection in the hundreds, because each contributor drew their symbol at
whatever size looked right to them, at whatever level of physical detail
they were rendering (a single auxiliary-contact glyph vs. a full
manufacturer footprint traced from a datasheet). There's no schema field,
naming convention, or qet-lint rule (checked in tools/qet-lint/) that
enforces or even flags a consistent size within a symbol family — the
mechanical-lock-sized problem is a purely visual one you only notice once
two mismatched elements sit on the same folio.
Practical takeaway: don't expect elements from different sub-collections
— or the same sub-collection at different manufacturer generations — to
read at a consistent visual scale just because they're both grid-aligned.
If a diagram's symbols look inconsistently sized after adding a new part
from a different collection, that's expected behavior, not a bug: check the
element's width/height in its .elmt file (or via Edit element)
against neighbouring symbols and resize by hand if it needs to match.
See also
- Preferences reference — where the grid settings live in the UI
- Using the element editor — drawing tools, saving, checks
- Mouse modifiers — Shift/Ctrl/Alt while dragging
- Elements XML — the
<definition>width/height/hotspotattributes
Getting Started
🌐 Languages — English · Français · Deutsch
Guides
Conductors — wire properties, what feeds which export, and cables
Wire & cable catalogue — cable types, IEC 60757 core colours, assigning a core to a conductor
Printing and exporting — paper, PDF, images, and what each path does differently
Linking elements — master, slave, terminal
PLC modules — I/O tables and linking a wire to a specific point
Using the element editor — drawing tools, saving, checks
Grid size and element size — why symbols aren't all the same scale
Preferences reference — what each settings page does
Keyboard-only control — mouseless QET, and the one real gap
Mouse modifiers — what Shift, Ctrl and Alt change while you drag
Managing collections — folders, writability, building your own shortlist
Templates — reusable multi-element blocks, and why clicking one does nothing
Search & Replace — bulk property changes
Building a nomenclature query — the BOM/summary table builder
Linking wires across pages — folio reports
Variables & formulas — %f, %{label}, sequences
Auto-numbering — schemes, sequences, freezing
Terminal strips — strips, levels, bridges
Title block templates — the .titleblock format
Importing EPLAN parts (.edz) — EPLAN Data Portal
DXF import & export — two unrelated features, one format
The project database — the in-memory SQLite cache
Development
Automating QET — CLI, XML formats, external tools
CLI Reference — command line usage
JavaScript Scripting — --run, geometry editing, undo
MCP server — let an AI assistant read, verify and edit projects
Vision — proposal, under discussion
