The diagram toolbar gets an "Ajouter un arc" button next to the
ellipse. Click one end, then click the other end at the height the arc
should reach: the result is a half arc bulging up or down from the line
between the two clicks (Shift: a true half circle). It is not filled,
since a fill would close it into a half disc.
A selected half arc shows one more handle, in the middle of the curve.
Dragging it makes the arc deeper or flatter while both ends stay put;
dragging it across the line between the ends turns the arc over. The
handle is hidden whenever the arc is not a half arc on a horizontal or
vertical diameter, because only then is "keep the ends, move the
middle" one well-defined change.
Nothing new is stored: an arc stays an Ellipse with a start and end
angle, exactly as the existing arc handles of an ellipse save it, so
files read by older versions are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Where two wires cross without being connected, a project can now draw a
small arc (a hop) on one of them, instead of the user inserting a jump
symbol and splitting the wire. It is a project setting, off by default:
Project properties > Général > "Croisements de conducteurs", with no
hops, hops on horizontal wires, or hops on vertical wires. Choosing the
orientation rather than following drawing order keeps a project
consistent.
Only the drawing changes: no element is added and no wire is split. A
wire that ends or bends on another one is a junction and never hops,
and a crossing too close to the end of a segment for the arc to fit is
drawn plainly. PDF, SVG and image export and printing show the hops,
since they paint through Conductor::paint(); DXF export, which writes
the segments itself, does not.
The setting is saved as <wire_crossings hop="..."/> under the project
root, next to <usage>, and only when hops are on, so a project that
never used them saves exactly as before.
The geometry is in wirehops.cpp, free of any graphics item, and tested
on its own. Conductor::paintedPath() feeds it the conductors of the
folio from a snapshot of their scene points, rebuilt only when a
conductor changes shape, moves, or enters or leaves a folio; each hop
path is cached the same way. Asking the scene for the conductors in a
rect instead strokes every candidate's shape, which made a 366-wire
folio render 0.6 s slower; with the snapshot the difference is within
measurement noise.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In the terminal strip manager, free terminals could only be moved into a
strip with the "move to" list and its button. Dragging one onto a strip,
which is what users try first (#409), did nothing.
Free terminals can now be dragged onto a strip in the tree on the left,
from either place they are listed:
- the free terminal table: every selected row is moved;
- the tree itself: the dragged free terminal is moved.
Dropping on a strip, or on a terminal already in that strip, moves them
with the same undo command as the button, so one undo puts them back.
The strip is then selected, showing the terminals just added. A drop
anywhere else is refused.
A drop is also refused while the free terminal table has edits that are
not applied yet: moving reloads that table and would lose them. The
button is disabled in the same case.
The drag carries the uuids of the terminal elements under its own mime
type, and the tree only moves terminals that are still free in the
project when the drop happens.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The button that moves free terminals into a strip is disabled when there
is nothing it can do, but its tooltip always gave the same reason: apply
or cancel the pending edits. With no row selected, which is what the
screenshot on #409 shows, that sends the user looking for edits they
never made.
It also stayed enabled when the project had no terminal strip at all.
The "move to" list is then empty and a click did nothing.
The button is now disabled in all three cases and the tooltip names the
one that applies, the most basic first: no strip yet (create one with
the + button), edits pending, or nothing selected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each wire already carries a cable name (Conductor properties -> Cable),
saved in the project, but no export showed it. The wiring list CSV
(Project menu, and --export-cables) now writes it as a last column, so
the list can be sorted or filtered by cable in a spreadsheet.
It goes last so existing columns keep their positions for anyone reading
the file by column number. When the two halves of a wire drawn through a
folio report are joined into one row, their cable names are merged the
same way as colour and section: written once if equal, both if not.
Asked for in issue #405.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A symbol with a "nan" or "inf" coordinate (bugtracker #266 had a line
with x1="nan" x2="nan") opened with that shape invisible and the view
off-centre. Moving the selection then snapped NaN through qRound() to
INT_MIN, and saving wrote width="-2147483630", breaking the symbol.
The folio already leaves such a shape out (ElementPictureFactory reads it
with QET::attributeIsAReal()). Do the same in the element editor, and
have --check-elements warn about it. Only geometry attributes are read,
so a text whose content is "inf" is not affected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resizing a selection in the element editor down to zero width or height
could not be undone: ScalePartsCommand scales back from the new rect, and
a flat rect cannot be scaled from, so undo silently left the shapes
collapsed and the flattening was saved. The same flat rect made
deltaForRoundScaling() divide 0 by 0 and fill the resize rect with NaN.
Never commit a resize rect with no width or height, and do not resize a
selection that is already flat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ticking or unticking "Afficher un texte de potentiel par folio" in
Folio > Properties only assigned Diagram::defaultConductorProperties.
Nothing recalculated the conductor texts, so texts hidden by the option
stayed hidden after it was turned off (and duplicates stayed visible after
it was turned on) until each wire was edited or the project was reopened.
That made the option look broken, which is part of what #344 reports.
When the option changes, reset each conductor's text visibility from its
own properties, then run calculateTextItemPosition() on every conductor of
the folio so the option is applied again from scratch.
Checked in the GUI on examples/industrial.qet folio 4 (26 wires with text,
19 potentials), master vs this commit: unticking now shows the hidden
texts immediately, ticking hides the duplicates immediately; master's
drawing does not change in either direction.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- fill all three Russian plural forms for the PDF page count and the two
font-recovery messages (lrelease dropped them, so French showed)
- restore the trailing and embedded newlines 12 translations had lost
- translate the remaining French AutoNumberingDockWidget tooltip
- wording: Повернуть %1, Сочетание клавиш / Горячие клавиши,
Перетаскивание: наклон, горизонтали, Вспомогательное текстовое
описание 1, со значением, ни при какой ширине
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Scrolls the folio so the point under the mouse becomes the centre of the
view, keeping the current zoom. Requested on the forum (topic 3199) for
moving around a zoomed-in folio the way KiCad and EasyEDA allow;
"Zoom sur le contenu" (Ctrl+8) was the closest existing command, but it
also refits the zoom.
The command is in the Affichage menu and in the shortcut editor. It has
no default key: F4 and the single letters are already taken or would
clash with typing. It does nothing when the cursor is not over the view,
so choosing it from the menu is harmless. Near the folio border the view
cannot scroll past the edge, so the point ends up as close to the centre
as the scroll bars allow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
wanderson_rds posted a corrected qet_pt_BR.qm on the forum
(https://qelectrotech.org/forum/viewtopic.php?id=3205). The .qm was
decompiled with lconvert and merged into the current qet_pt_BR.ts,
changing only the <translation> of each message, so line locations and
the lupdate layout are untouched.
- 266 strings that had no translation now have one (all plurals too).
- 29 existing translations replaced: "forme" was translated as "form"
(formulário) instead of "shape" (forma); zero-width spaces removed
from several "variáveis"; smaller wording and grammar fixes.
- "TextLabel" kept as master had it; vanished entries not touched.
lrelease: 2949 translations and 266 untranslated before,
3215 and 0 after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A slave pasted with its master is relinked to the master's copy by
initLink() (#997), so the slave data wipe that follows is only needed
for a slave that comes out of it unlinked. Linked, it wiped the
contact's label text while the link stayed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In the symbol editor, Space is the shortcut of the Rotate action, which
rotates the selected parts. The action is enabled whenever something is
selected, and a window shortcut is handled before the key reaches the
scene, so while a terminal or arc was being placed with something already
selected, Space rotated the selection and never reached ESEventAddTerminal /
ESEventAddArc. With nothing selected the action was disabled and the key
fell through, which is why it only happened with a selection.
The scene now emits behaviorChanged() when it enters or leaves AddPart,
and updateAction() keeps the selection actions (rotate, fine rotate, flip,
mirror, cut, delete, depth) disabled while a part is being added. They come
back when the tool ends. The selection itself is left alone.
ESEventInterface::init() also gives the view keyboard focus: a selection
made in the parts list left the focus there, so Space still never reached
the tool.
~ElementScene blocks its signals before deleting the event interface,
whose destructor resets the behavior while the editor is being destroyed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The MCP server gives each QElectroTech run a private HOME and writes the
element collection path for it (elements_dir) into
~/.config/QElectroTech/QElectroTech.conf there. Only Linux reads that
file: Qt keeps settings in the registry on Windows and in the system
preferences on macOS. So on those systems elements_dir did nothing, and
every run read the user's own settings (#1178).
When QET_SETTINGS_DIR names a folder, QElectroTech now keeps its
settings in <folder>/QElectroTech/QElectroTech.ini on every system. It is
set in main() before the first setting is read. Without the variable
nothing changes.
The server sets it for each run and writes the collection path to the
.ini as well as the .conf, so an older QElectroTech keeps working on
Linux. The path is written with forward slashes: Qt reads a backslash in
these files as an escape. The README notes that elements_dir needs this
on Windows and macOS, and that long arguments go on stdin with "-"
(Windows refuses a command line over 32,767 characters).
tst_settingsdir: a script places a symbol that only the folder's settings
can resolve, while the usual settings file points at an empty collection.
It fails on master and passes here.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Windows crash report held the header and the log and nothing else: no
exception, no address, no stack (issue #1179, two reports that could not
be traced). It now also has:
- the exception, with its name ("access violation", "stack overflow"...)
- where it happened, as module+offset, and for an access violation the
address that was read or written
- a backtrace, one module+offset per frame, walked with the unwind
tables every x64 image carries (RtlLookupFunctionEntry and
RtlVirtualUnwind): no dbghelp, no symbols, no allocation. addr2line
on the same build turns each offset into a function and line.
The dump is written by a reporter thread started at install(), not on
the crashing thread, which may have no stack left or hold the loader
lock. The crashing thread waits for it for at most ten seconds.
Two kinds of crash wrote no report at all before and now do:
- abort() (std::terminate(), a failed assert): no SEH exception, so
SIGABRT is handled as well.
- qFatal(): Qt ends it with TerminateProcess() on Windows, so the
message handler now asks for the dump once the message is logged.
Elsewhere reportFatal() does nothing; SIGABRT follows there.
Tested with a cross-built RelWithDebInfo build under Wine 11, crashing
on purpose from inside the event loop: a null pointer, a call through a
null pointer, a stack overflow, abort() and qFatal(). Each report
resolved to the line that crashed. Linux reports are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Moving the PLC table in the element editor was lost on save: the table
came back at (0, 0) when the element was reopened, and it was drawn at
(0, 0) in the diagram editor as well.
PartPlcTable::toXml() wrote m_rect.x()/y(), which are the coordinates
inside the item, and the move of a part never touches m_rect - it lives
in pos() (CustomElementGraphicPart::mouseMoveEvent, or the decorator for
a multi-selection). m_rect starts at the item origin, so x="0" y="0"
was written whatever the user did, while fromXml() reads those two
attributes as scene coordinates and hands them to setPos(). Every other
part translates first, see PartRectangle::toXml() with sceneTopLeft().
The top-left corner is now mapped to scene coordinates before being
written, which also covers a group transformation, since that one moves
m_rect while pos() stays put.
Both readers of the attribute need no change: ElementScene::fromXml()
for the editor and Element() for the runtime drawing of the table
(Element::drawPlcTable) already expect scene coordinates. Elements that
still carry x="0" y="0" keep loading as before.
Full build clean. Test suite: the same three failures as before the
change (tst_menubarkeyboard, tst_databasefromdocument,
tst_terminaluuids), each of them also failing on a build without this
patch, so they are unrelated.
A wire drawn to a folio report waited, keyed by its report, for the wire on
the linked report, in a QMap whose insert() replaces: a second wire on the
same report pushed the first out of the list, and a pair with several wires
on a side was joined by whichever came first. On the shipped examples,
re-saved as the export reads them, 130 of 3,189 wires were missing from the
list (industrial 86, m_000 41, affuteuse_250h 3).
All the report halves are now collected first, and two are joined only
when each report of a linked pair has exactly one wire. With several on a
side the diagram does not say which terminal is wired to which, so each
wire gets its own row ending at the report, as an unmatched half already
did. The result no longer depends on the order the folios are saved in.
The Page column printed each folio's number template ("%id/%total") and
the rows were sorted by it. It now prints the number the folio shows, and
the rows are sorted by the folio's position in the project.
tst_wiringlistexport checks a fixture with one report pair of each kind,
and the page column on every example.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Only one conflict: the include block of
sources/ui/configpage/generalconfigurationpage.cpp, where upstream adds
editor/terminalnamecheck.h next to the two includes of the prefix
editor. All three are kept. The file list in
cmake/qet_compilation_vars.cmake merged itself this time.
Review findings on the prefix editor:
- OK without touching anything changed the file: every row was written
back, so an explicit <prefix/>, which reads as an empty field and
cancels the inheritance, was dropped and that folder started
inheriting its parent's prefix again. A row is now written only when
it was edited or no longer holds what the file has, and the two kinds
of empty field look different: hasPrefix() tells an explicit
<prefix/> from a missing one, which is what the field hint shows.
- load() copied a broken file aside before the user had chosen
anything, so every "Corriger le fichier" left a .bak behind while the
message said nothing had been modified. The copy is now made by
save(), right before the file is replaced: repairing or cancelling
leaves nothing behind, and a copy that cannot be made stops the write
rather than destroying the only copy.
- The button followed the combo box only for "Parcourir...": put back
on "Par defaut" it fell back to the previously saved path instead of
the default one. The directory of the entry being displayed is now
used, "Par defaut" being dataDir()/elements/.
The text properties showed and edited the top-left corner of a text,
whatever its alignment, and changing the alignment did not move the
text. A right-aligned label next to a symbol therefore needed a
different X for every text length to keep the same gap (#1155).
Position X/Y is now the anchor point: the point of the text chosen by
the alignment (right edge for "right", middle for "centre"...). Typing a
position puts that point there, and changing the alignment moves the
text so that the new anchor point is on the same X/Y. It is the same
point that already stays fixed when the text changes.
Applies to the element text properties on a folio and to the text
field properties in the symbol editor. The saved x/y is still the
top-left corner, so projects and symbols load and save unchanged and
look the same; only the numbers shown for texts that are not top-left
aligned change.
The geometry is in textanchor.h, shared by DiagramTextItem and
PartDynamicTextField, and tested in tst_textanchor.
Not changed: static texts of the symbol editor (PartText), whose
position is tied to the font baseline; texts inside a text group, which
have no position or alignment of their own; rotation still pivots on
the top-left corner (or the centre), not on the anchor.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A template (.qetmak) was previewed and placed offset from the cursor by
the position its items had on the folio it was saved from: the preview
pixmap kept that offset, and addMacro() added it back before handing the
position to fromXml(). A template saved from the middle or the lower
right of a folio therefore landed far below and to the right of the
click, often off the folio, which reads as "the template does not drop"
(forum topic 3190). Anchor both the preview and the placement on the
template's own top-left corner instead.
fromXml() skips translating for a null position, so a click on the folio
origin is nudged by a fraction of a pixel that the grid snap removes.
Also:
- a template saved with "Create a template" only appeared in the
templates tab after reloading the collections or restarting; it is
now added to the tab of every open editor when it is saved;
- the placement status bar message ended in an untranslated
"(Makro-Anker)"; it now reads "x : y" like element placement.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In the F2 conductor colour dialog and the toolbar's "Other colour..."
dialog, a double-click on a basic or custom colour swatch now chooses it
and closes the dialog, as OK does (forum topic 3190). Qt's dialog only
selects the swatch on a double-click.
ColorDialogDoubleClick filters the dialog's QWellArray swatch grids,
found by class name once the dialog is shown, because Qt builds them
only then when a native dialog was offered but not shown. Where the
platform's native colour dialog is used instead (macOS, some Linux
desktops) there are no swatches to watch and nothing changes. The
toolbar dialog is now an instance rather than QColorDialog::getColor(),
so the filter can be installed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ispyisail