QgsPanelWidget: deprecate widgetChanged signal and use changed instead

[ptitjano]

Description

See discussion

I've always dislike the naming of the "widgetChanged" signal -- to me this sounds more like a "emitted when the widget shown in the panel has been changed to another widget" signal, as opposed to a "the settings described by the current widget have been changed" signal. We also use just changed() for many other widget subclasses, so the added consistency would be nice...

AI tool usage

No AI Tool used

[github-actions]

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
To execute locally, unzip the downloaded zip file and run bin\qgis-bin.exe in the extracted directory.
You might be prompted by Windows Defender click "Run anyway"
(Built from commit 220f50d)

🍎 MacOS Qt6 builds

Download MacOS Qt6 builds of this PR for testing.
This app is not notarized, run sudo xattr -d com.apple.quarantine /Applications/QGIS*.app to avoid the warning
(Built from commit 220f50d)

🪟 x64-windows — ⚠️ vcpkg failed before producing per-port logs

vcpkg returned a non-zero exit code but no port left a parseable buildtree. This usually means a portfile-execute abort (e.g. find_library REQUIRED, vcpkg_extract_source_archive download failure), or a vcpkg-internal error such as a missing tool or registry/baseline mismatch.

Look at the artifacts and the workflow log:

📑 Download full build-logs-x64-windows artifact · 🔧 Workflow run · 📌 Commit e2b3348

[nyalldawson]

@ptitjano would you consider adding a "changed" signal to QgsPanelWidget, and deprecating the widgetChanged signal (adding a connection from changed->widgetChanged to maintain api)?

I've always dislike the naming of the "widgetChanged" signal -- to me this sounds more like a "emitted when the widget shown in the panel has been changed to another widget" signal, as opposed to a "the settings described by the current widget have been changed" signal. We also use just changed() for many other widget subclasses, so the added consistency would be nice...

[ptitjano]

@ptitjano would you consider adding a "changed" signal to QgsPanelWidget, and deprecating the widgetChanged signal (adding a connection from changed->widgetChanged to maintain api)?

I've always dislike the naming of the "widgetChanged" signal -- to me this sounds more like a "emitted when the widget shown in the panel has been changed to another widget" signal, as opposed to a "the settings described by the current widget have been changed" signal. We also use just changed() for many other widget subclasses, so the added consistency would be nice...

No strong opinion regarding the naming. My only concern is that a widget which inherits from QgsPanelWidget should not introduce a new signal instead of using the base signal from QgsPanelWidget`.

I have updated the PR. QgsPanelWidget now has a changed signal and widgetChanged is deprecated.