openAndAddProject() shows BackupDialog as a stack object parented to the
editor and exec()s it; every QET::QetMessageBox does the same. exec() runs a
nested event loop, and closing the editor during it turns WA_DeleteOnClose
into a deleteLater() that the nested loop processes: ~QWidget() deletes the
editor's children, the stack-allocated dialog among them, and the process
aborts. Reported on macOS, where File > Quit lives in the application menu
and stays usable while the backup question is up.
The close is now refused while any modal widget is active, and the dialog is
raised so the refused quit is not silent. It is done in QETMainWindow::event()
rather than in closeEvent(), because QETDiagramEditor::closeEvent() starts
closing projects before it decides whether to accept. That covers the diagram
and title-block editors; QETElementEditor is a plain QMainWindow, so its
closeEvent() calls the same helper before canClose(), which itself opens a
modal. QETApp::quitQET() needs nothing: closeEveryEditor() goes through each
editor's close(), and quitQET() already only quits when every close succeeded.
Rejected alternatives, both suggested on the issue:
- Giving the dialog no parent stops the abort but not the deletion. One
caller of openAndAddProject() is the editor's own constructor, which goes
on to open the next file and call slot_updateActions() on this -- a loud
abort would become a silent use-after-free.
- Guarding only QETApp::closeEveryEditor(), which I first recommended on the
issue, misses the reported route entirely: File > Quit is connected to
QETDiagramEditor::close(), not to quitQET().
Verified on Linux, where there is nothing to click (the menu bar belongs to
the blocked window, and Qt ignores window-manager close requests for it), by
calling close() from gdb while the dialog's loop was running -- both
QETApp::quitQET() and QWidget::close() on the editor. Unfixed, both abort
with "free(): invalid size" in QObjectPrivate::deleteChildren() under
~QETDiagramEditor(), matching the report frame for frame; fixed, close()
returns false, the editor and the dialog stay up, and after answering the
dialog Ctrl+Q exits normally. The element-editor guard is the same helper
but was not exercised separately.
tests/modal-quit-regression/ turns that into a gate: it breaks on
QDialog::exec(), interrupts inside the nested loop, calls quitQET() and
checks the process survives. It matches no window titles (translated) and no
window ids, runs on the offscreen platform, and needs only gdb with Python.
Checked both ways: exit 1 with the backtrace above on a build without this
change, exit 0 with it.
ctest 8/8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two claims in the previous comment were wrong.
"Qt implements F10 on Windows but not on X11" was inference I cannot test
here. What is measured is narrower and enough: QMenuBar given Key_F10
directly leaves it unaccepted, and sent to the window the key never reaches
the menu bar at all, because a key press goes to the focused child widget.
"&Édition takes É, which is not on a UK or US keyboard" was wrong outright.
It came from running an uninstalled binary, which cannot find its .qm files
and falls back to the French source strings. With translations loaded the
menus read File, Edit, Project, Display, Settings, Windows, Help, and Alt+E
opens Edit.
The comment now also says plainly that this is convenience rather than
access: Alt tap focuses the bar and Alt with a letter opens a menu, both
verified working, so the menus were already reachable without a mouse. F10
is the key people reach for out of habit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb
F10 opens the menu bar in most applications and is the usual way to reach
the menus without a mouse. Qt provides this on Windows but not on X11, so on
Linux the key did nothing and the press fell through to whichever widget had
focus. It matters more here than it might elsewhere: "&Édition" takes É for
its own letter, which is not on a UK or US keyboard, so that menu has no
direct Alt route at all.
A window-context QShortcut rather than a key handler -- key presses go to
the focused child widget, so a keyPressEvent() on the window would never see
F10 while the canvas or a panel has focus.
tests/qttest/tst_menubarkeyboard.cpp covers three things: that Alt and a
letter opens a menu (the control), that plain F10 does nothing in Qt itself
(which is why the shortcut exists, and which will fail loudly if a future Qt
starts handling it), and that the shortcut mechanism opens the bar.
It uses QTest instead of driving a real X server for a specific reason.
xdotool on Xvfb delivers every function key with Alt held: a Qt key logger
shows Key_F10 arriving with modifiers == Qt::AltModifier. --clearmodifiers,
keydown/keyup pairs, --window targeting and flattening the keycode with
xmodmap all made no difference. Two rounds of GUI automation therefore gave
confident, wrong answers about F10 -- first that it was broken, then that
this very fix did not work. QTest posts the event straight to the widget, so
the key arrives as written.
What the test does not cover, since initCommonActions() calls
QETApp::instance() and constructing that pulls in the whole application: it
repeats the wiring rather than driving QETMainWindow. Confirming the real
window responds still needs someone to press F10 in a running QElectroTech.
Verified by breaking it: bound to F11 instead, the test fails. Qt 5 and Qt 6
both build clean, 6/6 tests on each.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stacked on the steps 1-3 branch (feature-diagnostic-logging, PR #646).
Kept as its own PR rather than folded into that one, matching the
discussion's own framing: step 4 is explicitly "the highest-risk piece
... lands last, behind its own switch."
## Step 4 -- crash-time ring flush (CrashHandler)
Installs a handler for SIGSEGV/SIGABRT/SIGBUS/SIGFPE/SIGILL (POSIX) /
SetUnhandledExceptionFilter (Windows) that flushes the in-memory ring to
a fixed crash_dump.log before the process dies.
This required reworking LogRing (step 3) to be genuinely lock-free, not
just mutex-protected: a signal handler that blocks on a lock the
crashing thread (or another thread) already holds turns a clean crash
into a hang -- no ring dump *and* no core dump, worse than doing
nothing. append() now claims a slot with a single atomic fetch-add;
dumpToFd() reads the preallocated entries directly and writes them with
write(2) only, looping on EINTR/short writes. Accepted tradeoff: at most
one entry can be read torn if a crash lands mid-append into that exact
slot -- documented in logring.h, and the alternative (a seqlock to
detect and retry) wasn't judged worth the complexity for that window.
Other invariants implemented per the discussion:
- sigaltstack with a static 64 KiB buffer, SA_ONSTACK -- a stack-
overflow SIGSEGV has no usable stack for a handler without one.
- Nothing under the actual handler touches Qt, QString or the
allocator: the dump path and a small header (version/git/OS/Qt) are
precomputed into fixed char buffers by install(), which runs once at
startup in normal context.
- Atomic test-and-set so only the first crash writes a dump; a second
concurrent/nested fault goes straight to restore-and-re-raise.
- After writing, the handler restores SIG_DFL and re-raises (POSIX) /
returns EXCEPTION_CONTINUE_SEARCH (Windows) so the OS's own crash
path -- core dump, Windows Error Reporting -- still runs. A handler
that "fixed" the crash by swallowing the signal would destroy exactly
the post-mortem evidence this whole design exists to preserve.
Tested in this environment: POSIX/Linux only, all five signals. Sent
each directly to a running process and confirmed (a) crash_dump.log is
written with the correct header and ring contents, mode 0600, and (b)
the process still terminates via the signal with the kernel's own
"core dumped" flag set (exit code 128+signal, confirmed for all five).
The Windows path is implemented per the discussion's guidance but is
untested -- no Windows build available in this sandbox.
## Step 5 -- getting the data back out
- QETApp::checkCrashDump(), called from checkBackupFiles() only when
there's no stale project file to recover this run (so the two
prompts never both show, per the discussion), offers an unretrieved
crash dump via DiagnosticsReportDialog and then deletes it regardless
of the user's choice -- offered exactly once.
- A new "Aide > Enregistrer un rapport de diagnostic..." action
(QETMainWindow) builds the same kind of report from the *current*
session (QetLogger::buildDiagnosticsReport(): header + this session's
log file) for a manual "attach this to a bug report" flow, not tied
to a crash.
- Both go through QetLogger::redact() before ever reaching the user:
the one redaction implemented is a literal replace of the home
directory with "~", since an absolute path under it leaks the
account name. The discussion's fancier "optionally redact project
filenames too" isn't attempted -- reliably telling a project path
apart from arbitrary log text is a much fuzzier problem than a
literal prefix match.
- DiagnosticsReportDialog shows the full (already-redacted) content
before saving, per the discussion: "the user is about to attach this
to a public tracker."
Verified in a real GUI session (Xvfb): triggered a SIGSEGV, relaunched,
confirmed the crash-report dialog appears with the right header/content,
confirmed it does not reappear on a second relaunch, and confirmed the
manual "Save report" action produces a correctly-formatted report and
saves it to a chosen path.
Built clean, no new warnings.
## Build systems
Registered in both: cmake/qet_compilation_vars.cmake, and
qelectrotech.pro. The .pro needed explicit globs for the new
sources/logging/ui/ subfolder -- sources/logging/*.{h,cpp} was already
globbed, but unlike the other ui/ subfolders that one had no entry of
its own, so diagnosticsreportdialog.{h,cpp} would not have been built
under qmake.
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).
If the version number of QElectroTech is requested in the forum in case of error messages or anomalies, the Qt version used is very often stated because the entry “About QElectroTech” does not appear very prominently in the help menu: The entry “About Qt” is used much more frequently because it appears eye-catchingly as the lowest entry. However, specifying the Qt version is often not helpful for troubleshooting: We need the QET version!
That's why I'm moving the “About QElectroTech” entry to the bottom, so that it is easier to see and find!
version download link (only for MS Windows and macOS)
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@4765 bfdf4180-ca20-0410-9c96-a3a8aa849046
Add a shortcut F1 for open manual online
Add a link for download latest devel build for Windows (only visible on
Win platform)
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@4710 bfdf4180-ca20-0410-9c96-a3a8aa849046
-Cette ligne, et les suivantes ci-dessous, seront ignorées--
M sources/aboutqet.cpp
M sources/bordertitleblock.cpp
M sources/conductorproperties.h
M sources/configdialog.cpp
M sources/configpages.cpp
M sources/configpages.h
M sources/createdxf.h
M sources/diagram.cpp
M sources/diagram.h
M sources/diagramcommands.cpp
M sources/diagramcommands.h
M sources/diagramprintdialog.cpp
M sources/diagramprintdialog.h
M sources/diagramschooser.cpp
M sources/diagramschooser.h
M sources/diagramview.cpp
M sources/diagramview.h
M sources/dvevent/dveventaddimage.cpp
M sources/dvevent/dveventaddshape.cpp
M sources/editor/arceditor.cpp
M sources/editor/arceditor.h
M sources/editor/editorcommands.cpp
M sources/editor/editorcommands.h
M sources/editor/elementitemeditor.h
M sources/editor/elementprimitivedecorator.cpp
M sources/editor/elementscene.cpp
M sources/editor/elementscene.h
M sources/editor/elementview.cpp
M sources/editor/ellipseeditor.cpp
M sources/editor/ellipseeditor.h
M sources/editor/esevent/eseventaddtext.cpp
M sources/editor/esevent/eseventaddtextfield.cpp
M sources/editor/esevent/eseventinterface.cpp
M sources/editor/graphicspart/customelementpart.h
M sources/editor/graphicspart/parttext.cpp
M sources/editor/graphicspart/parttext.h
M sources/editor/graphicspart/parttextfield.cpp
M sources/editor/graphicspart/parttextfield.h
M sources/editor/lineeditor.cpp
M sources/editor/lineeditor.h
M sources/editor/polygoneditor.cpp
M sources/editor/qetelementeditor.cpp
M sources/editor/qetelementeditor.h
M sources/editor/rectangleeditor.cpp
M sources/editor/rectangleeditor.h
M sources/editor/styleeditor.cpp
M sources/editor/styleeditor.h
M sources/editor/terminaleditor.cpp
M sources/editor/terminaleditor.h
M sources/editor/texteditor.cpp
M sources/editor/texteditor.h
M sources/editor/textfieldeditor.cpp
M sources/editor/textfieldeditor.h
M sources/editor/ui/elementpropertieseditorwidget.cpp
M sources/elementdefinition.cpp
M sources/elementdeleter.cpp
M sources/elementdeleter.h
M sources/elementdialog.cpp
M sources/elementscategorieslist.h
M sources/elementscategorieswidget.cpp
M sources/elementscategorieswidget.h
M sources/elementscategory.cpp
M sources/elementscategorydeleter.cpp
M sources/elementscategorydeleter.h
M sources/elementscategoryeditor.cpp
M sources/elementscategoryeditor.h
M sources/elementscollection.cpp
M sources/elementscollectioncache.cpp
M sources/elementspanel.cpp
M sources/elementspanel.h
M sources/elementspanelwidget.cpp
M sources/elementspanelwidget.h
M sources/elementtextsmover.h
M sources/exportdialog.cpp
M sources/exportdialog.h
M sources/exportproperties.cpp
M sources/exportpropertieswidget.cpp
M sources/exportpropertieswidget.h
M sources/genericpanel.cpp
M sources/integrationmoveelementshandler.cpp
M sources/integrationmoveelementshandler.h
M sources/interactivemoveelementshandler.cpp
M sources/nameslistwidget.cpp
M sources/nameslistwidget.h
M sources/newelementwizard.cpp
M sources/newelementwizard.h
M sources/nomenclature.cpp
M sources/nomenclature.h
M sources/projectconfigpages.cpp
M sources/projectview.cpp
M sources/projectview.h
M sources/qet.cpp
M sources/qetapp.cpp
M sources/qetapp.h
M sources/qetdiagrameditor.cpp
M sources/qetdiagrameditor.h
M sources/qetgraphicsitem/conductor.cpp
M sources/qetgraphicsitem/conductortextitem.cpp
M sources/qetgraphicsitem/customelement.cpp
M sources/qetgraphicsitem/diagramimageitem.cpp
M sources/qetgraphicsitem/diagramtextitem.cpp
M sources/qetgraphicsitem/diagramtextitem.h
M sources/qetgraphicsitem/element.cpp
M sources/qetgraphicsitem/ghostelement.cpp
M sources/qetgraphicsitem/qetshapeitem.cpp
M sources/qetgraphicsitem/terminal.cpp
M sources/qetgraphicsitem/terminal.h
M sources/qeticons.cpp
M sources/qeticons.h
M sources/qetmainwindow.cpp
M sources/qetmessagebox.cpp
M sources/qetmessagebox.h
M sources/qetprintpreviewdialog.cpp
M sources/qetprintpreviewdialog.h
M sources/qetproject.cpp
M sources/qetsingleapplication.cpp
M sources/qettabbar.h
M sources/qfilenameedit.cpp
M sources/qtextorientationspinboxwidget.cpp
M sources/qtextorientationspinboxwidget.h
M sources/qtextorientationwidget.cpp
M sources/qtextorientationwidget.h
M sources/richtext/richtexteditor.cpp
M sources/richtext/richtexteditor_p.h
M sources/richtext/ui_addlinkdialog.h
M sources/titleblock/dimensionwidget.h
M sources/titleblock/gridlayoutanimation.h
M sources/titleblock/helpercell.h
M sources/titleblock/integrationmovetemplateshandler.cpp
M sources/titleblock/integrationmovetemplateshandler.h
M sources/titleblock/qettemplateeditor.cpp
M sources/titleblock/qettemplateeditor.h
M sources/titleblock/templatecellsset.h
M sources/titleblock/templatecellwidget.cpp
M sources/titleblock/templatecellwidget.h
M sources/titleblock/templatecommands.cpp
M sources/titleblock/templatedeleter.cpp
M sources/titleblock/templatedeleter.h
M sources/titleblock/templatelocationchooser.cpp
M sources/titleblock/templatelocationchooser.h
M sources/titleblock/templatelocationsaver.cpp
M sources/titleblock/templatelocationsaver.h
M sources/titleblock/templatelogomanager.cpp
M sources/titleblock/templatelogomanager.h
M sources/titleblock/templateview.cpp
M sources/titleblock/templatevisualcell.h
M sources/titleblockcell.cpp
M sources/titleblocktemplate.cpp
M sources/treecoloranimation.h
M sources/ui/conductorpropertieswidget.cpp
M sources/ui/diagrampropertiesdialog.cpp
M sources/ui/diagramselection.cpp
M sources/ui/dialogautonum.cpp
M sources/ui/dialogwaiting.cpp
M sources/ui/elementpropertieswidget.cpp
M sources/ui/elementselectorwidget.cpp
M sources/ui/linksingleelementwidget.cpp
M sources/ui/masterpropertieswidget.cpp
M sources/ui/potentialtextsdialog.cpp
M sources/ui/projectpropertiesdialog.cpp
M sources/ui/selectautonumw.cpp
M sources/ui/titleblockpropertieswidget.cpp
M sources/ui/xrefpropertieswidget.cpp
M sources/undocommand/changeelementinformationcommand.cpp
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@3783 bfdf4180-ca20-0410-9c96-a3a8aa849046
ispyisail