feat(amd-gpu-monitor): add AMD GPU monitoring plugin

[dvaxert]

Summary

Adds amd-gpu-monitor, a Noctalia Shell plugin for real-time AMD GPU monitoring with comprehensive metrics and customizable graphs using rocm-smi.

The plugin provides:

• Bar Widget: Compact GPU status display with threshold-based coloring (green → yellow at 75% → red at 90%)
• Panel Widget: Full GPU monitoring interface with real-time mini-graphs for all metrics
• Multi-sensor Temperature: Monitor Junction, Edge, and Memory temperatures simultaneously on a multi-line graph
• Clock Speeds: Track SCLK, MCLK, FCLK, SOCCLK, and DCEFCLK on a single graph
• VRAM Monitoring: Track VRAM usage and activity
• Customizable Metrics: Show/hide any metric via settings
• Localization: Includes i18n folder for multi-language support
• Theme Integration: Uses Noctalia Shell theme colors for graphs and icons

Why

AMD GPU users need real-time monitoring of GPU metrics (temperature, clock speeds, VRAM, power) directly from their desktop shell. This plugin provides comprehensive monitoring with visual graphs without requiring external applications.

Testing

• Validated amd-gpu-monitor/manifest.json with python -m json.tool
• Verified amd-gpu-monitor/preview.png is a 960x540 PNG (16:9 aspect ratio)
• Ran local grep checks matching this repository's code-quality workflow patterns for:
  • hardcoded user-facing text, label, and description strings (all use i18n)
  • hardcoded numeric border.width, spacing, pointSize, radius, and margin style fields
  • console.log statements
• Smoke-tested the plugin in Noctalia Shell before packaging, including panel, bar widget, and settings

Notes

• The standalone source repository is available at https://github.com/dvaxert/amd-gpu-monitor
• Requires rocm-smi (ROCm System Management Interface) to be installed and available in PATH
• Requires a discrete AMD GPU

Features

• Real-time graphs for all metrics with customizable colors
• Priority thresholds with automatic color changes (75% warning, 90% critical)
• Multiple temperature sensors (Junction, Edge, Memory)
• Five clock speed tracking options (SCLK, MCLK, FCLK, SOCCLK, DCEFCLK)
• Configurable device index for multi-GPU systems
• Compact and detailed display modes
• Monospace font option for aligned values

[github-actions]

Automatic Manifest Check

---

File: amd-gpu-monitor/manifest.json

• (H) Missing required property repository. For example:

"repository": "https://github.com/noctalia-dev/noctalia-plugins"

[github-actions]

Plugin "amd-gpu-monitor" is missing some required files:

• README.md

[github-actions]

Automatic Code Quality Review

---

File: amd-gpu-monitor/BarWidget.qml

• (L) Line 209: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+    const tr = key => pluginApi?.tr(key) ?? key;

• (L) Line 406: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+        "label": pluginApi?.tr("actions.widget_settings") || "Settings",

• (H) Line 565: Do not use hardcoded values, always prefer to use the Style singleton instead

+        spacing: 3

---

File: amd-gpu-monitor/Panel.qml

• (H) Line 181: Do not use hardcoded values, always prefer to use the Style singleton instead

+          pointSize: 24 * Style.uiScaleRatio

• (L) Line 186: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          text: pluginApi?.tr("panel.title") ?? "AMD GPU Monitor"

• (H) Line 207: Do not use hardcoded values, always prefer to use the Style singleton instead

+        border.width: 1

• (L) Line 219: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+            text: pluginApi?.tr("panel.unavailable") ?? "GPU data unavailable"

• (L) Line 227: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+            text: mon?.lastError || pluginApi?.tr("panel.check_rocm") || ""

• (L) Line 246: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.gpu_use") ?? "GPU Use"

• (L) Line 263: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.temperature") ?? "Temperature"

• (L) Line 275: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("temp.junction") ?? "Junction"

• (L) Line 282: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("temp.edge") ?? "Edge"

• (L) Line 289: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("temp.memory") ?? "Memory"

• (L) Line 302: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.vram") ?? "VRAM"

• (L) Line 314: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("vram.usage") ?? "Usage"

• (L) Line 321: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("vram.activity") ?? "Activity"

• (L) Line 334: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.fan_speed") ?? "Fan Speed"

• (L) Line 351: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.power") ?? "Power"

• (L) Line 368: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.clock_speeds") ?? "Clock speeds"

• (L) Line 387: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("clocks.sclk") ?? "SCLK"

• (L) Line 394: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("clocks.mclk") ?? "MCLK"

• (L) Line 401: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("clocks.fclk") ?? "FCLK"

• (L) Line 408: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("clocks.socclk") ?? "SOCCLK"

• (L) Line 415: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+              label: pluginApi?.tr("clocks.dcefclk") ?? "DCEFCLK"

• (L) Line 428: When it comes to translations there is no need for fallback values. From: pluginApi?.tr("example") || "value". To: pluginApi?.tr("example")

+          cardTitle: pluginApi?.tr("metrics.vram_activity") ?? "VRAM Activity"