The socket name and token now go in the "live" part of the one file the
qet MCP server reads about this QElectroTech, rather than in a
live-session.json of their own, and are cleared when the channel closes.
The file also says whether the live setting is on.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
QElectroTech now writes qet-assistant.json in the standard data folder
when an editor opens, and again whenever the stored scripts or the
scripting setting change: its version and program, every folder (data,
settings, scripts, the element and title block collections), which
features are on, every call a script can make (QetScriptApi::signatures(),
apiSignatures() without a running script), and the stored scripts with
their ids, files, icons and shortcuts, plus those refused and why. On
quit it says nothing is running any more.
The qet MCP server reads it rather than guessing each folder per
platform, which is wrong as soon as QElectroTech runs with --data-dir:
the file stays where the server can find it and names the folders
actually in use. Readable by the user only.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
While the user types to the assistant, QElectroTech is not the active
application, and QMdiArea then reports no active sub-window: status said
no project was open and every run was refused. Make the sub-window it
remembers active again before handling a request; the focus stays where
the user put it. Found with the Windows package under Wine; reproduced on
Linux with another window focused.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The qet MCP server connects once per request. On Windows a named pipe's
disconnection reaches QLocalSocket late, so the second of two quick calls
was turned away as "another assistant is already connected". Found
testing the Windows package under Wine with a Windows-side client.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A script the assistant writes on the spot is shown to the user before it
runs: Exécuter, Refuser, or Toujours pour cette session. Stored scripts
run as a click would. The choice is per session and never saved.
An "Assistant" dock lists every action with the time, ✓ or ✗, and its
undo step; the script, its log or its error show on hover and on a
double-click. It opens with live mode and holds the ask-first box.
The assistant may also:
- trigger an editor command from an allow-list of ones that open no
dialog and that undo can take back (selection, zoom, rotate, snap,
group, reset wires); saving, deleting, exporting and the rest are
refused;
- show another folio;
- undo the newest step only if it made it ("Assistant : …");
- take a picture of the folio on screen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A new setting, Configurer QElectroTech > Général > "Autoriser un assistant
IA à agir sur le projet ouvert", off by default. Off, nothing changes:
no channel is opened. On, every start shows a warning first -- Continuer,
Pas pour cette session, or Désactiver -- and nothing can connect until
the user answers Continuer. It waits for any other start-up question to
be answered, so the two never stack.
Accepted, LiveServer opens a local socket only the user's account can
use, with a random name and token written to live-session.json in the
data folder for the qet MCP server, and removed when the channel closes.
One JSON request per line: status (project, folio on screen, selection,
last undo step, stored scripts), run_script and run_stored. Requests are
queued out of the socket handler before they run (the lesson of PR #861).
Each run is one undo step named "Assistant : <name>". The status bar
shows the mode and the assistant's last action with a ✓ or ✗ and the
time, and an Arrêter button that closes the channel for the session.
Unticking the setting closes it at once.
QetScripting::runSource() runs script text and, for a live run, returns
what qet.log() wrote, the error with its line and the undo step instead
of showing boxes; qet.showMessage() is logged rather than opening a box
nobody asked for.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fixes#1210. The "Renvoi de folio" submenu offered the common coming and
going arrows only while the project had no folio report element yet.
Placing one copies it into the embedded collection, so from then on the
menu listed just that one and the other arrow could not be inserted until
the project was closed without saving.
The two common arrows are now always listed, after the project's own
report elements, each name once.
Checked in the GUI on a blank one-folio project: on master the submenu
drops from two entries to one after a coming arrow is placed and the
second pick places another coming arrow; with this change it keeps two
entries and the second pick places a going arrow (both in the saved file).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Projet > Scripts > Gérer les scripts… lists the stored scripts with their
icons, and the files that get no button with the reason. For each one it
edits the name, icon (a file copied next to the script, a theme icon, or
the initials), tooltip, shortcut, when it is enabled, and the script
itself; "Tester" saves it and runs it on the current project, one Ctrl+Z
to undo; "Supprimer" deletes it with its icon if no other script uses it.
It only reads and writes the files in the scripts folder, so a script
written here, by hand or by an assistant over the qet MCP server is the
same thing, and the folder's watcher turns each into a button.
ScriptHeader gains compose(), bodyOf() and idFor(), header-only and
tested: what the manager writes reads back as what was typed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Read from the meta-object, so the list is the one the running build has:
for someone writing a script, and for an assistant that has to write one
without the source at hand.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every .js file in the "scripts" folder of the user's data folder that
starts with a // ==QETScript== header becomes a command: in Projet >
Scripts, as a button on a new Scripts toolbar, and, because it is
registered with ShortcutManager as diagrameditor.script.<file name>, in
the shortcut settings, the shortcut bar (S) and command search. The
header gives its name, icon (a file next to the script or a theme icon;
a tile with its initials otherwise), tooltip, default shortcut and when
it is enabled (always, with a selection, with a conductor selected).
The folder is watched, so a script added, edited or deleted while QET is
open appears, changes or goes without a restart. A file with a header
that cannot be used gets no button; the Scripts menu lists it with the
reason. The menu also opens the folder, and holds "Exécuter un script…".
A click runs the script on the current project as one undo step named
after it, and asks to switch scripting on first, like "Exécuter un
script…" does: scripting stays off by default.
ShortcutManager::unregisterAction() takes a command out of the lists
when its script is deleted, and lets it come back under a new name.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A script started from the editor had no way to know which folio is on
screen, and each qet.* call was its own undo step, so a script that adds
twenty items needed twenty Ctrl+Z to take back.
qet.currentFolio() returns the folio shown in the editor; through --run,
which has no view, the first folio, or -1 when there is none.
A run from the editor is now one undo macro, named after the script. A
run that changed nothing leaves no empty entry behind. qet.undo() and
qet.redo() inside a grouped run say why they cannot work (QUndoStack
ignores them inside a macro) instead of failing silently. --run is
unchanged: one step per call, so scripts that call qet.undo() keep
working.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The "one text per potential" switch (onetextperfolio) lives in a folio's
conductor defaults, which no scripting call or qet_edit op could reach, so
callers patched the saved .qet afterwards (#1178).
qet.setConductorDefault(folio, property, value) sets onetextperfolio or any
setConductorProperty name on a folio's defaults, or with folio -1 on the
project's defaults that new folios copy. A change to onetextperfolio
re-shows or hides the conductor texts at once, as the Folio properties
dialog does. Not on the undo stack, like both dialogs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The middle handle of a half arc sits exactly on the middle of the top
or bottom edge of the ellipse -- a resize handle in Size mode, a skew
handle in RotateSkew mode -- and, drawn last, it covered that handle
(arummler, discussion #1203). It is now shown in Size mode only, where
the resize handle under it is hidden instead: the middle handle already
changes that height, with the ends kept in place. RotateSkew mode shows
its skew handle again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The search field gets a light green or light red background to show
whether the text matches, but only QPalette::Base was set. With a dark
theme the text colour is light too, so the typed text was light on
light and could not be read.
Set QPalette::Text to black together with the light background.
Fixes#1209
Ctrl+V moves the pasted group under the pointer as before. The new
Ctrl+Shift+V ("Coller au point d'origine", diagrameditor.paste_origin)
leaves the group exactly where it was copied from and warps the OS
cursor to the group's grid-snapped origin, so the paste baseline and
the physical cursor agree and the group starts following the mouse from
its original place instead of jumping to the pointer.
The cursor warp is only trusted as the baseline when it verifiably
lands (QCursor::pos() agrees with the target): QCursor::setPos() needs
pointer focus and is a silent no-op on compositors without
wp_pointer_warp_v1. Otherwise m_baseline_captured stays false and
moveTo() re-baselines on the first real mouse move, so a refused warp
costs at most the first movement rather than flinging the group across
the folio. An origin outside the viewport is scrolled into view first,
since the compositor rejects warp targets outside the window.
With "Show the properties of a selected conductor in the Selection
properties panel" switched on, editing a wire there could change things
the user never touched:
- Enter in a field (Function, Section...) is not used by the line edit,
so it reaches the checkable "Multifilaire" group box around it, which
takes it as a click. The wire was switched to single-line, gaining
ground, neutral and phase symbols. The modal dialog never shows this
because its OK button takes Enter first.
- Every edit wrote back the whole set of properties as the widget holds
them, so a value the widget cannot show exactly was rewritten: a dash
size of 1 became 2.
The panel now swallows Enter at its checkable group boxes, and writes
only the fields that differ from what it showed, through the new
ConductorProperties::applyChanges(). "Apply to all conductors of this
potential" uses the same rule, so the rest of the potential keeps its
own values too.
tst_conductorapplychanges checks each field on its own: change that one
field, and a wire whose every field differs takes it and keeps the rest.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
ispyisail