Project > Nettoyer le projet and Project > Liste de câblage (base de
données) were the only two entries in the Project menu with no wiki
coverage at all. Both are small, so they go into the pages people would
already be reading rather than into two thin stubs.
Cleaning, in collection_browser: three checkboxes all ticked by default,
what "unused" is decided from, and the part that matters -- it does not
go through the undo stack, so Ctrl+Z will not bring the definitions back
and closing without saving is the only way out. Also which collection it
touches: the one embedded in the project, never your own library, which
is the reverse of what people fear and has its own consequence for a
project carried to another machine.
The wiring list window, in conductors, beside the exports it mirrors:
its six columns, the sort (numeric wire numbers before text, so 9 comes
before 10), that it refreshes the database before querying so a number
edited this session is already there, and that it counts the conductors
it excluded -- an endpoint attached to no element cannot appear in a
from-to list, and a non-zero count means something is not connected.
Being database-backed it carries the same missing columns as
--export-wiring, which the page already explains.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
Add a Templates page, and correct how templates are placed
The wiki had no page on the Modèles tab, and the one sentence that
described it said a template is "dropped back in as a group at a click".
A click is exactly what does not work: clicking and double-clicking a
template are explicit no-ops in the code, and its context menu has no
insert entry. Drag-and-drop is the only route.
That sentence has a cost. An electrician reported the feature as broken
on the forum this month (viewtopic.php?pid=23296, item 5): "dans la liste
des modèles quand j'en sélectionne un que j'ai créé, il ne se dépose pas
sur le folio". He did what the wiki said and filed a bug.
The new page covers creating a template from a selection, placing one,
where the files live and how to relocate the folder, what a .qetmak
contains, how templates compare with elements and with copy/paste, the
limitations, and the four questions people actually arrive with.
Checked against the source and against a running build rather than
written from memory: the context-menu entry and save dialog were driven
by hand, the resulting .qetmak inspected, and the "double-click does
nothing" claim measured (two elements on the folio before, two after).
The placement gestures, the storage path and the file format come from
reading the code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CaKympWT3owLotCpEN2CFj
Add a real answer for 'how do I find my elements faster'
Fixes a real inaccuracy while here: the page claimed drag-and-drop
'moves' elements, with common-collection drags being copies only
because you can't remove the source. Checked ElementCollectionHandler
directly -- there is no move() at all, only copy(), called
unconditionally regardless of source or destination. Every drag
copies. Also corrected what happens on a name collision: an
Erase/Rename prompt (RenameDialog), not a silent overwrite as I'd
first assumed before checking ECHSFileToFile::copy().
New §4: the concrete, verified workflow for building a personal
shortlist of frequently-used devices with the tools that already
exist -- a custom-collection folder, drag-to-copy, and the existing
'Show only this folder' solo filter -- since there is no dedicated
favourites feature to point to instead. States the one real
limitation (a copied element is a snapshot, not a live link to the
common-collection original) rather than leaving it to be discovered.
Cross-linked with keyboard_control.md, since 'select elements' is
ambiguous between finding one to place and selecting one already
placed -- this page is the former.
Document managing collections: folders, writability, the two-tab panel
sources/ElementsCollection/ is the largest undocumented chunk found this
session -- separate from elements_XML (the file format) and
element_editor (drawing one element), nothing covered day-to-day
collection management.
The finding worth having written down: the common collection's read-only
status is not a filesystem permissions check. ElementsLocation::isWritable()
refuses anything under commonElementsDirN() unconditionally, by path --
that's why New folder/New element/rename/delete are greyed out there even
running as an administrator, and why dragging an element out of the
common collection copies it (there is no source to remove) while nothing
can be rearranged inside it. Custom and company are genuinely writable;
an embedded (project-internal) element follows the project's own
read-only state.
Also documents the panel's second tab -- Templates/macros, a reusable
diagram-fragment mechanism distinct from single elements, drag-dropped
onto a folio as a group -- and the full context-menu action set (new
folder/element, edit, delete with a real not-undoable warning, reveal in
file manager, reload from disk, the solo-folder filter, folder
properties).
Updates the Element Collections & Libraries stub in user_manual (EN/FR/DE)
to link here instead of the placeholder bullets from the correction pass.
EN/FR/DE.
ispyisail