Files
qelectrotech-source-mirror/sources/shortcutmanager.h
T
ispyisail 83b9f32bd0 Add device-button-to-action bindings, for any 3D mouse backend
Discussion #599's own scope explicitly deferred this ("Related, not
proposed here... a natural follow-up once basic pan/zoom motion works").
Basic pan/zoom now works (previous commits on this branch), so this adds
it -- generically, for whichever SpaceMouseBackend is in use, not tied to
libspnav specifically, matching the seam the previous commit built.

## Reuses ShortcutManager instead of inventing a second action registry

ShortcutManager is already an app-wide registry of every named, rebindable
action -- undo, redo, rotate selection, cut/copy/paste, autonum configure,
and dozens more -- each carried by a live QAction or QAbstractButton. A
device button binding to one of *those* ids, rather than to a bespoke
QET-3D-mouse-only action list, means the discussion's own examples
(rotate/mirror/undo) are available for free, and any action added to the
app in the future is automatically bindable too.

Added ShortcutManager::trigger(id): find the first still-alive target for
an id and call QAction::trigger() or QAbstractButton::click(), whichever
it is. Deliberately not disambiguated by which window is currently active,
unlike SpaceMouseListener's own pan/zoom dispatch -- a target's owning
top-level window isn't reliably discoverable from a bare QAction. Correct
in the overwhelming common case of one open editor window; documented in
the header as a known simplification, not silently assumed correct.

## The binding itself: SpaceMouseButtonMap

A thin QSettings-backed button-number -> action-id map, unbound by default
for every button on every device -- nothing happens on any button press
until the user opens Configuration > Souris 3D and binds something,
matching this whole feature's "silent until asked for" default.

## Backend side: SpaceMouseBackend::buttonPressed(int)

Added to the platform interface alongside the existing motion() signal.
SpnavBackend now handles SPNAV_EVENT_BUTTON (previously explicitly
ignored) and emits on press only -- release is not reported, since nothing
downstream has a use for it. A future non-spnav backend implements the
same signal and gets button support for free through
SpaceMouseListener::applyButton(), without that logic being duplicated or
re-verified per backend -- the same reasoning the previous commit's seam
was built around.

## Configuration UI: SpaceMouseConfigPage

Modelled directly on the existing ShortcutsConfigPage -- same QTableWidget
shape, same "persist on applyConf(), not live" contract -- one row per
binding: button number (spin box, unbounded, since button count and
numbering genuinely vary from 2 to 30+ across real devices and this could
not be checked against hardware) and action (combo box populated from
ShortcutManager::instance().allShortcuts(), the exact same live registry
the Shortcuts page itself lists). Only added to the Configuration dialog
when QET_SPACEMOUSE_SUPPORT is compiled in.

## Verified, including the one thing that doesn't need hardware to prove

Rebuilt from scratch both ways: option off adds zero new object code
(confirmed via a forced rebuild of the one unconditionally-changed file,
shortcutmanager.cpp, which alone picked up new warning-free code); option
on compiles all four new/changed files warning-free and links clean.

The backend's button *detection* (SPNAV_EVENT_BUTTON -> buttonPressed
signal) still cannot be verified without a real device or daemon -- same
limitation as the motion path from the previous commits, stated plainly
rather than glossed over.

What *is* fully verified, because none of it needs hardware:
 - SpaceMouseButtonMap: unbound by default, set/read-back, clearing via an
   empty id, enumeration -- all confirmed via a standalone harness linked
   against the real compiled objects.
 - ShortcutManager::trigger(): registered a real QAction, confirmed
   trigger() fires it exactly once and returns true; confirmed it returns
   false (not a crash) for an unknown id.
 - SpnavBackend: constructs safely with no daemon present (isAvailable()
   false, as it must be), and both its motion and buttonPressed signals
   are correctly wired per Qt's own metaobject data (QSignalSpy).
 - The configuration page end-to-end, via a real Xvfb session: opened
   Configuration > Souris 3D, confirmed the action combo box lists the
   live, real ShortcutManager registry (undo, rotate, cut/copy/paste,
   dozens more -- not a mock), added rows, edited the button number,
   removed rows, selected "Éditeur de schémas — Pivoter" (Rotate -- the
   discussion's own example) for button 3, clicked OK, and confirmed via
   the actual settings file that it persisted exactly as
   "buttons\3=diagrameditor.rotate_selection". Reopened the dialog and
   confirmed it read back correctly. This is a full, real round trip
   through the UI, not a claim.
2026-08-02 22:11:30 +12:00

107 lines
3.8 KiB
C++

/*
Copyright 2006-2026 The QElectroTech Team
This file is part of QElectroTech.
QElectroTech is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.
QElectroTech is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with QElectroTech. If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef SHORTCUTMANAGER_H
#define SHORTCUTMANAGER_H
#include <QHash>
#include <QKeySequence>
#include <QList>
#include <QPointer>
#include <QString>
#include <QStringList>
class QObject;
/**
@brief The ShortcutManager class
App-wide registry of every rebindable shortcut, carried by either a
QAction or a QAbstractButton -- both declare an identical "shortcut"
Q_PROPERTY of type QKeySequence, which this class targets generically via
QObject so it doesn't need a separate code path for the handful of
QAbstractButton-based shortcuts (e.g. a QPushButton acting as a shortcut-
only trigger).
Every place in the code that used to call setShortcut() directly now
calls registerAction() instead, giving each shortcut a stable string id, a
category (for grouping in the UI) and a hardcoded default sequence.
registerAction() applies the user's saved override for that id (if any),
falling back to the default, and remembers the target so the Shortcuts
configuration page can list, edit and persist it.
Several targets can share the same id at once, since QET allows several
windows of the same kind (diagram editor, element editor...) to be open
simultaneously, each with its own QAction. setSequence() updates every
live target for a given id in one call.
*/
class ShortcutManager
{
public:
static ShortcutManager &instance();
struct ShortcutInfo {
QString id;
QString category;
QString description;
QKeySequence default_sequence;
QKeySequence current_sequence;
};
void registerAction(QObject *target, const QString &id,
const QString &category,
const QKeySequence &default_sequence);
QList<ShortcutInfo> allShortcuts() const;
QKeySequence currentSequence(const QString &id) const;
void setSequence(const QString &id, const QKeySequence &sequence);
void resetToDefault(const QString &id);
void resetAllToDefaults();
/// Activate the first still-alive target registered under \a id
/// -- QAction::trigger() or QAbstractButton::click(), whichever
/// it turns out to be -- for an input source other than the
/// keyboard (e.g. a 3D mouse button) that wants to invoke a
/// named action without knowing or caring which of the two it
/// is. Deliberately not disambiguated by the currently active
/// window when an id has several live targets: a target's
/// owning top-level window isn't reliably discoverable from a
/// bare QAction. Correct in the overwhelming common case of one
/// open editor window; a known simplification in the rarer
/// multi-window case, not a guaranteed-correct dispatch.
/// @return whether a live target was found and triggered.
bool trigger(const QString &id) const;
private:
ShortcutManager() = default;
ShortcutManager(const ShortcutManager &) = delete;
void operator=(const ShortcutManager &) = delete;
struct Entry {
QString category;
QString description;
QKeySequence default_sequence;
QList<QPointer<QObject>> targets;
};
QKeySequence savedSequence(const QString &id, const QKeySequence &default_sequence) const;
QHash<QString, Entry> m_entries;
QStringList m_order;
};
#endif // SHORTCUTMANAGER_H