Managing collections
This page covers the Elements panel itself — organizing folders, moving and deleting elements, what "writable" actually means day to day, and how to build yourself a shortcut to the devices you actually reach for instead of hunting through the shared collection every time (§4). Separate pages cover the file format (Elements XML) and drawing one element (Using the element editor).
Source: sources/ElementsCollection/ — elementscollectionwidget.cpp (the
panel), elementstreeview.cpp / elementscollectionmodel.cpp (the tree),
elementslocation.cpp (identity and writability).
1. Two tabs, one panel
The Elements panel has two tabs:
| Tab | Shows |
|---|---|
| Collections | the element tree — common, custom, company, and anything embedded in the current project |
| Templates | reusable diagram fragments ("macros") you drag onto a folio, separate from single elements — see Templates |
A macro is a saved chunk of diagram content — elements, conductors, whatever was selected — dropped back in as a group. It is placed by dragging it onto the folio: clicking or double-clicking its name does nothing, which catches people out. It is a distinct mechanism from an element and is covered on its own page, Templates; the browsing and folder-management rules on this page apply equally to both tabs.
The search box at the top filters the current tab as you type.
2. The three collections, and which ones you can actually edit
| Collection | Location | Writable? |
|---|---|---|
| Common | ships with QET | No — always read-only, regardless of file permissions on disk |
| Custom | yours | yes |
| Company | shared within an organisation | yes |
| Embedded | inside the open project | follows the project — read-only if the project itself is read-only |
The common collection's read-only status is not a permissions check —
ElementsLocation::isWritable() refuses it unconditionally, by path. That's
why New folder, New element, rename and delete are always greyed out there,
even running as an administrator.
All three top-level paths (plus the two title-block-template paths and the macros path) can be relocated from Preferences → General.
3. Organizing elements
Right-click in the tree for:
| Action | Does |
|---|---|
| New folder | creates a sub-folder — only where the collection is writable |
| New element | starts the new-element wizard in that folder |
| Edit the element | opens it in the element editor |
| Edit the folder | rename it |
| Delete the element | asks for confirmation, then removes the file — not undoable |
| Delete the folder | asks for confirmation, then removes the folder and everything in it — not undoable |
| Open the corresponding folder | reveals the location in your OS file manager |
| Reload collections | re-reads the collection tree from disk — useful after editing files outside QET |
| Show only this folder / Show all folders | a "solo" filter, to focus the tree on one branch |
| Folder properties | filesystem path, plus a count of elements and sub-folders it holds |
Drag and drop always copies, never moves. Checked directly:
ElementCollectionHandler has a copy() method and no move() at all, and
the model's dropMimeData() ignores the drop action it's given and calls
copy() unconditionally. Drag an element from the common collection, your
own custom folder, or anywhere else onto a writable folder, and the
original stays exactly where it was — you get a second copy, not a
relocation. You can't drop onto the common collection at all (it refuses
any write, per §2). If the destination already has a file or folder with
the same name, you're asked — erase the existing one, or give the new copy
a different name — rather than either side losing data silently.
Deletion is real deletion, not a QET-level undo/trash. If a folder or element might still be needed, keep a copy elsewhere rather than delete it — there's no "move" to rely on for that, only copy-then-manually-delete.
4. Building a personal shortlist of the elements you actually use
The shipped common collection is organized by device category across the whole trade — thousands of elements, deep folders, and no way to mark one as a favourite. If you keep reaching for the same twenty or thirty devices across every project, the tools above already combine into a real solution, without waiting on a "favourites" feature that doesn't exist yet:
- Right-click "Collection utilisateur" (your custom collection) → New folder. Build whatever structure actually matches how you think about your own work — by project type, by panel, alphabetically by name, flat with no subfolders at all. It's yours; the common collection's structure has no say in it.
- Find each device once, however you normally would — browsing, or the search box (§1; it matches display names, not filenames).
- Drag it onto your new folder. This copies it in, per §3 above — the original in the common collection is untouched, so you're never at risk of breaking the shared library while building your own shortcut to it.
- Repeat for every device you reach for often. From then on, they're one level deep under Collection utilisateur, in an order you chose.
"Show only this folder" (§3) is the other half of this: once your shortlist folder exists, right-click it and solo it to hide the entire common collection tree while you work, then "Show all folders" when you need to find something new. That combination — a small hand-picked folder, solo-filtered — is the closest thing QET currently has to a favourites list, built entirely from the copy-and-organize primitives above rather than a dedicated feature.
This is a snapshot, not a live link. A copied element doesn't track its common-collection original — if the shipped version of a device is later fixed or improved, your copy doesn't pick that up automatically. Redo the copy if you want the update. That trade-off is the same one embedded elements make (§5), just deliberate here instead of automatic.
5. Elements embedded in a project
A project can carry its own copy of elements it uses, independent of any
collection on disk — that's the Embedded row above. This is what makes a
.qet file self-contained: send someone the file, and elements you pulled
from your custom collection travel with it, correctly rendered, even though
the recipient has no such collection.
See also: Elements XML · Using the element editor · Preferences reference · Importing EPLAN parts (.edz)
Looking for how to select items already placed on a diagram (Tab-cycling, select all, invert selection) rather than finding one to place? That's Keyboard-only control, a different meaning of "select" from everything on this page.
6. Cleaning a project's embedded collection
A project accumulates embedded copies: every element you place is stored inside
the .qet file, and deleting the element from a folio does not remove the
stored definition. Over a long project that adds up.
Project → Nettoyer le projet offers three checkboxes, all ticked by default:
| Option | Removes |
|---|---|
| Unused title block templates | embedded title block templates no folio uses |
| Unused elements | embedded element definitions that no folio places |
| Empty categories | embedded folders left with nothing in them |
"Unused" is decided by looking at what the folios actually place, so an element you deleted from the drawing yesterday counts as unused today.
This cannot be undone. Cleaning does not go through the undo stack — there is no undo command to reverse, and Ctrl+Z will not bring the definitions back. The only way out is to close the project without saving. Save first if you are not certain.
It only touches the collection embedded in the project. Your own element library on disk is not affected, and neither is the common collection. The practical consequence is the reverse of what people fear: cleaning does not lose you an element you still have installed — but it does mean a project carried to a machine that lacks that element in its library no longer brings its own copy.
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
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
Vision — proposal, under discussion
