Resetting an active numbering counter back to a starting value, or
marking it as needing manual numbering, currently requires the full
round trip through the project properties dialog: open it from the
dock's Configure button, locate the right numbering context, select
the specific part row, clear and retype the value, confirm.
Add two small buttons next to each of the three combo boxes
(Conductor/Element/Folio) on AutoNumberingDockWidget itself:
- Reset to start: calls NumerotationContext::replaceValue() on every
part that represents a progressing counter, using a sensible
per-type value -- the part's own stored initialvalue for
folio-anchored types (unitfolio/tenfolio/hundredfolio), "1" for
plain numeric types and wrap, "a" for alpha. Non-incrementing types
(string, plant, locmach, idfolio, folio, elementline,
elementcolumn, elementprefix) are left untouched, since there's no
meaningful "start" distinct from whatever the user configured for a
fixed/contextual value.
- Reset to "?": sets every part's value to the literal placeholder
"?" unconditionally, for marking a context as needing manual
numbering.
Both write the updated context back via the same
addConductorAutoNum/addElementAutoNum/addFolioAutoNum calls the
project properties dialog itself already uses, so the dock's existing
refresh signals fire exactly as they do today.
Verified with a full build (Qt6) after the change -- clean compile
and link, including the .ui-generated Ui class correctly picking up
the six new button object names. Wasn't able to get a reliable live
GUI run in this environment to click-test the buttons themselves (ran
into unrelated session/display instability before any interaction
with the new buttons occurred), so this is verified by code review
and successful build rather than a runtime screenshot.
Implements https://github.com/qelectrotech/qelectrotech-source-mirror/discussions/597
Implements the first pillar of #574: a "Shortcuts" preferences page letting
users rebind, search and reset every keyboard shortcut in the app.
What it does
- New ShortcutManager singleton: every one of the ~95 setShortcut()/
setShortcuts() call sites across qet.cpp, qetmainwindow.cpp,
elementspanelwidget.cpp, autonumberingdockwidget.cpp, richtexteditor.cpp,
qetdiagrameditor.cpp, qettemplateeditor.cpp and qetelementeditor.cpp now
calls registerAction(target, id, category, default_sequence) instead,
which applies the user's saved override (or the default) and remembers
the target for later editing.
- New ShortcutsConfigPage, added to the existing "Configurer QElectroTech"
dialog: a filterable table of every registered shortcut, grouped by
category, each with a QKeySequenceEdit and a per-row reset button, plus a
"reset all" button. Bindings are only persisted (via
ShortcutManager::setSequence()) when the dialog is accepted.
- Conflict detection: rows whose currently-edited sequence collides with
another row are highlighted with a tooltip naming the conflicting action.
- Overrides are stored under a "shortcuts/" QSettings group, one key per
id, keyed to match the id (not persisted at all when equal to the
hardcoded default), so a future QET version can safely raise a default
for anyone who never customized it.
Design notes
- Targets are handled generically via QObject rather than QAction, since one
call site (autonumberingdockwidget's "Configurer" button) is a
QPushButton, not a QAction. Both declare an identical "shortcut"
QKeySequence Q_PROPERTY, so registerAction() reads/writes it through the
property system instead of needing a separate code path.
- Several live targets can share one id at once -- QET allows multiple
windows of the same kind (diagram editor, element editor...) open
simultaneously, each constructing its own QAction with the same id.
setSequence() updates every live target for that id in one call, so a
rebind takes effect in all open windows immediately, without restart.
- A shortcut's description is captured from its target's text() the first
time that id is registered, then cached -- so the config page stays
correct even after the owning window is closed. One consequence: a
shortcut belonging to an on-demand window (element editor, title block
editor, rich text editor) only appears in the list once that window has
been opened at least once in the current session, since nothing has
registered its id yet otherwise.
Testing
Full CMake build (qmake CONFIG+=no_kf5, Qt 5.15) compiles clean with zero
errors and zero new warnings. Verified end-to-end in a real running session
(Xvfb + xdotool):
- The Shortcuts page appears in Configure QElectroTech with the right icon,
lists every always-registered shortcut with correct category/action name/
current binding.
- The filter box correctly narrows the list, and correctly returns nothing
for an action whose owning window hasn't been constructed yet this
session (confirming the on-demand-registration behavior above is working
as designed, not silently broken).
- Conflict detection correctly flagged a real pre-existing same-key overlap
between "Supprimer" (delete selection, Del) and "Supprimer ce folio"
(delete diagram from panel, Del) -- both highlighted with explanatory
tooltips.
- Rebound "Manuel en ligne" to Ctrl+Shift+M, clicked OK: persisted under
[shortcuts] in QElectroTech.conf, and the Aide menu's entry showed the new
binding immediately, no restart needed.
- Reopened the dialog: the rebind was still shown. Clicked its per-row
reset button, then OK: the settings key was removed entirely (not stored
as "F1"), correctly falling back to the hardcoded default.
Retrofitting the Tab/Shift+Tab, select-all (#585) and Ctrl+G jump-to-element
(#586) shortcuts through this registry is left for a follow-up once those
PRs land, to avoid re-merging still-open branches into this one.
Developed with assistance from Claude (Anthropic).
ispyisail