* Replace per-module Methods screen with an Interface screen (methods + events)
A module exposes two halves of its API — methods you call and events you
subscribe to. The per-module screen now shows both. The 'View Methods'
button becomes 'Interface', and PluginMethodsView is renamed to
PluginInterfaceView with a Methods section (unchanged, with Call) and a
new Events section below it (event name in amber, signature, and the
event's description; no Call button).
- CoreModuleManager: getEvents(name) -> invokeRemoteMethod(name,
"getPluginEvents"), mirroring getMethods.
- MainUIBackend: getCoreModuleEvents(name) delegates to it.
- CoreModulesView: 'Interface' button; openInterface()/showingInterface.
- PluginInterfaceView (renamed): loads methods + events, renders both.
- docs: project.md view description.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Harden PluginInterfaceView: stable width + clear stale state
Address review feedback (#210):
- PluginInterfaceView: bind the inner ColumnLayout to the ScrollView's
availableWidth (via an id) instead of parent.width. Inside a Qt 6
ScrollView parent.width resolves against the internal Flickable
contentItem and can transiently collapse to 0 during Repeater reflow —
the same fix already applied in CoreModulesView/UiModulesTab.
- loadMethods()/loadEvents(): clear methods/events (and resultText) when
pluginName becomes empty, so a reset view can't show a previous
plugin's interface.
- CoreModuleManager.h: correct the stale 'Both return' comment now that
there are three JSON introspection methods (getMethods/getEvents/
callMethod).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ui: distinct cascade dialog for upgrade/downgrade/reinstall
Before: upgrading, downgrading, or reinstalling a package showed the
"Uninstall and Unload Dependents?" dialog because PackageCoordinator
reused uninstallCascadeConfirmationRequested for the beforeUpgrade
event. Confusing on downgrades — the dialog read like a pure removal,
giving no indication a new version was about to land.
After: PackageCoordinator emits a new upgradeCascadeConfirmationRequested
signal carrying the target releaseTag + UpgradeMode (already arriving
on the beforeUpgrade payload). OverlayDialogs hosts a dedicated
ConfirmationDialog instance in the new "upgradeCascade" mode that
leads with "Upgrade to vX.Y.Z" / "Downgrade to vX.Y.Z" /
"Reinstall vX.Y.Z" and an amber confirm button. Dependent-impact
lists render identically to the uninstall variant (the package_manager
still does an uninstall step first, with the same cascade semantics).
Confirm/Cancel route through the same backend slots
(confirmUninstallCascade / cancelPendingAction); PackageCoordinator
disambiguates from m_pendingAction.op (UpgradeCascade vs
UninstallCascade), so no protocol or .rep changes needed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix: forward upgradeCascadeConfirmationRequested through MainUIBackend
Missing piece from the previous commit: PackageCoordinator emitted the
new signal but MainUIBackend (the QML-exposed backend) didn't re-emit
it, so the Connections { target: backend } block in OverlayDialogs.qml
never fired and the dialog stayed hidden. Symptom: clicking Reinstall
or Downgrade did nothing — the package_manager fired beforeUpgrade,
PackageCoordinator ack'd and emitted the signal, but it died inside
the C++ layer.
Add the signal to MainUIBackend.h and connect PackageCoordinator's
upgradeCascadeConfirmationRequested to it in the constructor, mirroring
how uninstallCascadeConfirmationRequested is forwarded.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* ui: reword upgradeCascade dialog so it stops scaring users
Two corrections to the upgrade/downgrade/reinstall dialog copy.
1. Drop the "Will stop working (installed but not running)" section.
That heading is true for an uninstall — the module is gone, the
dependents fail to load next time — but lying for an upgrade: the
new version lands before they ever try to load again, so they're
not affected in any user-visible way. Listing them implied breakage
that wouldn't actually happen.
2. Rename the loaded-dependents heading from "Will be unloaded now:"
to "Currently running (will be temporarily unloaded):" and rewrite
the body sentence to spell out that they resume against the new
version: "The modules below are running on top of it and will be
unloaded for the swap — they keep working with the new version
once it lands."
The uninstall dialog's copy is untouched (its "Will stop working"
heading is correct for an actual removal).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* bump dependencies
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* properly handle portable modules
* preinstall modules on startup instead of bundling them at build time
* get icons from manifest
* consistent user dir
* revert to main branch of dependencies
* add release derivations
* add appimage release job
* fix app icon on Linux
Khushboo Mehta