Contesto
pyqtgraph è stato inizialmente adottato nei primi stadi di sviluppo di quantum-core e FIRE per la sua facilità d’uso e le capacità di rendering rapido per dati scientifici. Tuttavia, con l’evoluzione del progetto e l’aumento della complessità delle interfacce utente e dei requisiti di visualizzazione (es. rendering di overlay complessi, interazioni avanzate, theming dinamico), pyqtgraph ha iniziato a mostrare limitazioni significative:
- Performance su Dati Voluminosi: Sebbene rapido per grafici semplici,
pyqtgraphfatica a mantenere framerate elevati con migliaia di candele e numerosi overlay personalizzati, specialmente con interazioni utente intense (zoom, pan). - Stabilità e Manutenibilità: Sono stati riscontrati bug sporadici relativi al rendering e all’interazione, difficili da debuggare e spesso legati a problematiche interne alla libreria, con un supporto e una frequenza di aggiornamenti non sempre allineati alle nostre esigenze.
- Limitazioni di Theming e Personalizzazione: Integrare
pyqtgraphnel sistema di theming centralizzato diquantum-core(tramiteThemeManager) si è rivelato macchinoso, richiedendo spesso workaround o comprometendo la coerenza visiva. - Difficoltà con Rendering Ibrido: L’integrazione di componenti di UI moderni e web-based (come
QWebEngineViewperLightweightCharts.js) è complessa, portando a soluzioni “a doppia tecnologia” non ottimali.
Il report architetturale ha evidenziato ulteriormente questi punti, con la presenza di bar_line_chart_widget.py che ancora si basa su matplotlib (spesso usato come fallback per pyqtgraph o per visualizzazioni specializzate), indicando una mancanza di standardizzazione nel charting.
Decisione
Deprecare formalmente l’uso di pyqtgraph in tutti i nuovi sviluppi e pianificare la sua progressiva sostituzione nei componenti esistenti di FIRE.
La strategia di sostituzione si concentrerà su:
LightweightCharts.js(tramiteQWebEngineView): Diventerà lo standard primario per i grafici finanziari interattivi (candele, barre, linee) grazie alle sue eccellenti performance, reattività, e capacità di theming e personalizzazione via CSS/JavaScript, facilmente integrabile con il nostroThemeManager.Plotly: Sarà l’alternativa preferenziale per le visualizzazioni statistiche e i grafici analitici più complessi (es. heatmap, boxplot, Kagi, Point & Figure) che non richiedono interazioni in tempo reale estreme, ma beneficiano della sua ricchezza di tipi di grafico e della capacità di generare output statici o interattivi in HTML/JSON.
Conseguenze
Positive
- Standardizzazione del Charting:
LightweightCharts.jsdiventerà la tecnologia di riferimento per il charting in tempo reale, eliminando la frammentazione tecnologica e semplificando lo sviluppo di overlay (come già avviene conlwc_overlay_manager.py). - Miglioramento delle Performance: Le soluzioni web-based come
LightweightCharts.jssono ottimizzate per il rendering grafico e gestiscono grandi dataset con maggiore fluidità. - Coerenza Visiva e Theming Semplificato: L’integrazione con il
ThemeManagersarà più diretta, garantendo un’applicazione visivamente uniforme e facilmente personalizzabile dall’utente. - Riduzione del Debito Tecnico: Eliminando una dipendenza problematica, si riduce la superficie di attacco per bug e si facilita la manutenzione.
- Interazioni Utente più Ricche:
LightweightCharts.jsoffre un’esperienza utente moderna e API robuste per interazioni avanzate (tooltip, highlight, gestione eventi).
Negative
- Sforzo di Refactoring: Richiederà un significativo sforzo per riscrivere i componenti che attualmente utilizzano
pyqtgraph. Questo sarà un processo graduale. - Nuove Dipendenze (minime): L’uso estensivo di
QWebEngineViewePlotlypuò introdurre nuove considerazioni sul lato delle dipendenze (es. dimensione dell’eseguibile, requisiti di sistema perQWebEngineView). Tuttavia, queste sono già presenti nel progetto. - Curva di Apprendimento: Il team dovrà acquisire maggiore familiarità con le API JavaScript di
LightweightCharts.jse con la gestione delle interazioni tra Python e JavaScript viaQWebChannel.