138 lines
4.8 KiB
Markdown
138 lines
4.8 KiB
Markdown
# Synthèse — Mettre en place une roue chromatique (HSV) dans GNOME Shell 48
|
||
|
||
## Contexte
|
||
- GNOME Shell 48 (GJS) utilise **St/Clutter** (pas GTK dans le Shell).
|
||
- Il n’existe **pas** de composant natif « roue chromatique » (type `GtkColorChooser`) directement exploitable dans une extension GNOME Shell.
|
||
- Objectif : offrir une **roue HSV** pour choisir une couleur (H, S) + un contrôle d’**intensité** (V), puis produire un RGB (0–255) utilisable pour piloter un matériel (ex. clavier RGB).
|
||
|
||
---
|
||
|
||
## Options possibles (du plus recommandé au plus “hybride”)
|
||
|
||
### Option A — Roue HSV native GNOME Shell (recommandée)
|
||
**Principe**
|
||
- Créer un widget custom basé sur `Clutter.Canvas`.
|
||
- Dessiner une roue HSV (visualisation en V=1 pour lisibilité).
|
||
- Capturer les interactions souris :
|
||
- angle → **Hue (H)**
|
||
- rayon → **Saturation (S)**
|
||
- Ajouter un slider pour **Value (V)** (intensité).
|
||
- Convertir HSV → RGB (0–255) et déclencher un callback.
|
||
|
||
**Avantages**
|
||
- 100% intégré au Shell (look & feel cohérent extension).
|
||
- Dépendances minimales (GJS uniquement).
|
||
- Utilisable dans un menu top-bar, Quick Settings, ou popup.
|
||
- Contrôle immédiat (idéal pour piloter des LED).
|
||
|
||
**Inconvénients**
|
||
- Code à maintenir (rendu + interaction).
|
||
- Optimisation possible nécessaire pour performance (cache image).
|
||
|
||
**Recommandation**
|
||
- C’est la meilleure solution pour une extension GNOME 48, surtout si l’usage cible est le pilotage hardware RGB.
|
||
|
||
---
|
||
|
||
### Option B — Sliders RGB (solution la plus robuste)
|
||
**Principe**
|
||
- Ne pas faire de roue.
|
||
- 3 sliders `St.Slider` ou `PopupSliderMenuItem` :
|
||
- R (0–255)
|
||
- G (0–255)
|
||
- B (0–255)
|
||
- Afficher un carré d’aperçu (preview) `St.Widget` dont la couleur suit les sliders.
|
||
|
||
**Avantages**
|
||
- Très simple, très stable, très maintenable.
|
||
- Exact pour piloter des LED (RGB natif).
|
||
- Peu de code, faible coût performance.
|
||
|
||
**Inconvénients**
|
||
- Moins intuitif qu’une roue HSV.
|
||
- Expérience utilisateur moins “graphique”.
|
||
|
||
**Recommandation**
|
||
- Excellent si priorité = fiabilité et précision LED.
|
||
- Peut être combiné avec la roue (Option A) pour affiner.
|
||
|
||
---
|
||
|
||
### Option C — Hybride : application GTK externe (GtkColorChooser) + DBus
|
||
**Principe**
|
||
- Créer une petite app GTK (hors Shell) utilisant `GtkColorChooser` (roue native GNOME).
|
||
- L’extension GNOME Shell lance l’app ou communique via DBus.
|
||
- L’app renvoie la couleur choisie (RGB/HSV) à l’extension.
|
||
|
||
**Avantages**
|
||
- UI GNOME native parfaite (roue GTK).
|
||
- Moins de code côté Shell pour le rendu.
|
||
|
||
**Inconvénients**
|
||
- Architecture plus lourde (extension + service/app).
|
||
- Gestion DBus, packaging, cycle de vie de l’app.
|
||
- Moins fluide pour un usage “réglage instantané”.
|
||
|
||
**Recommandation**
|
||
- À considérer si tu veux absolument la roue GTK standard et acceptes la complexité.
|
||
|
||
---
|
||
|
||
### Option D — Réutiliser du code existant (extensions / libs)
|
||
**Principe**
|
||
- S’inspirer d’une extension existante (Color Picker, etc.) ou porter un widget JS déjà implémenté.
|
||
- Intégrer le code (Canvas, HSV->RGB, interactions) dans ton extension.
|
||
|
||
**Avantages**
|
||
- Gain de temps si un code de roue HSV est déjà éprouvé.
|
||
- Possibilité de reprendre des patterns Shell (PopupMenu, Quick Settings, etc.).
|
||
|
||
**Inconvénients**
|
||
- Variabilité de qualité et compatibilité GNOME 48.
|
||
- Nécessite vérification licence / maintenance.
|
||
|
||
**Recommandation**
|
||
- Très efficace si tu trouves un code déjà aligné GJS/Clutter moderne.
|
||
|
||
---
|
||
|
||
## Rendu “fidèle” vs LED (point important)
|
||
- Une roue à l’écran (sRGB) ne correspond pas parfaitement au rendu des LED de clavier.
|
||
- Recommandé :
|
||
- afficher RGB 0–255 et/ou HEX
|
||
- prévoir un slider d’intensité (V) + luminosité matériel
|
||
- optionnel : appliquer une correction empirique (ex. réduire le bleu) pour coller au rendu réel.
|
||
|
||
---
|
||
|
||
## UX conseillée (pragmatique)
|
||
### MVP (simple et efficace)
|
||
- Roue HSV (H,S) + slider V
|
||
- Aperçu (carré couleur)
|
||
- Affichage RGB (0–255) + HEX
|
||
- Bouton “Appliquer” (ou appliquer en live)
|
||
|
||
### Version “confort”
|
||
- Roue HSV + sliders RGB (affinage)
|
||
- Presets (palette)
|
||
- Historique des dernières couleurs
|
||
- “Appliquer au démarrage” (persist)
|
||
|
||
---
|
||
|
||
## Recommandation finale
|
||
Pour GNOME Shell 48, le meilleur choix est :
|
||
1. **Option A** (roue HSV custom via `Clutter.Canvas`) + slider V
|
||
2. compléter par **Option B** (sliders RGB) si tu veux une précision LED maximale
|
||
|
||
Option C (GTK externe) est valable mais plus lourde et moins adaptée à un réglage rapide dans le Shell.
|
||
|
||
---
|
||
|
||
## Livrables possibles (si on passe à l’implémentation)
|
||
- Widget `HsvWheel` réutilisable (Canvas + interaction)
|
||
- Intégration top-bar (PopupMenu) ou Quick Settings
|
||
- Callback standard `onColor({r,g,b,h,s,v})`
|
||
- Module utilitaire HSV<->RGB
|
||
- (Option) pipeline d’application : sysfs / asusctl / DBus service
|
||
s |