SXXXXXXX_PyDownloadFwViaSRIO/doc/GUI_adapter_changes.md
2026-01-22 17:10:05 +01:00

127 lines
4.1 KiB
Markdown

# GUI Adapter - Modifiche per Compatibilità Profili
## Problema Risolto
Il modulo GUI ([gui.py](../pydownloadfwviasrio/gui/gui.py)) utilizzava la vecchia API di `ProfileManager` che aveva un attributo `.profiles` (lista di `FlashProfile`). Con la ristrutturazione del sistema di profili, `ProfileManager` ora gestisce `targets` (FlashTarget) e `models` (FlashModel) separatamente.
## Soluzione: Adapter Pattern
Ho implementato la classe `GUIProfileAdapter` che:
1. **Wrappa il nuovo `ProfileManager`**
2. **Espone un'interfaccia compatibile** con il vecchio codice GUI
3. **Converte automaticamente** i dati tra nuovo e vecchio formato
### Struttura dell'Adapter
```python
class GUIProfileAdapter:
def __init__(self, manager: ProfileManager):
self.manager = manager # Nuovo ProfileManager
@property
def profiles(self) -> List[FlashProfile]:
"""Converte targets in FlashProfile legacy."""
# Per ogni target:
# - Recupera il modello associato
# - Crea FlashProfile con i dati combinati
# - Usa global_config per IP e porta
def get_profile(self, name: str) -> Optional[FlashProfile]:
"""Recupera target come FlashProfile."""
# Converte singolo target in FlashProfile
# Altri metodi per compatibilità...
```
### Conversione dei Dati
Quando il GUI richiede un `FlashProfile`, l'adapter:
1. Recupera il `FlashTarget` per nome
2. Recupera il `FlashModel` associato tramite `id_model`
3. Combina i dati:
- `name``target.id_target`
- `slot_address``target.slot_address` (formattato hex)
- `ip`, `port``global_config`
- `base_address``model.user_start` (area user)
- `size``model.user_stop - model.user_start + 1`
- `binary_path``target.binary_path`
## Modifiche al GUI
### FlasherGUI.__init__()
**Prima:**
```python
self.profile_manager = ProfileManager()
if not self.profile_manager.profiles:
# ...
```
**Dopo:**
```python
# Inizializzazione posticipata dopo creazione log widget
self.profile_manager: Optional[GUIProfileAdapter] = None
def _initialize_profiles(self):
base_manager = ProfileManager()
# Carica da targets.ini se disponibile
if not base_manager.targets:
targets_ini = Path("_OLD/Vecchia_app/FpgaBeamMeUp/targets.ini")
if targets_ini.exists():
base_manager.load_from_ini(targets_ini)
# ...
# Wrappa in adapter
self.profile_manager = GUIProfileAdapter(base_manager)
```
### ProfileManagerDialog
Aggiornato per usare `manager.profiles` come property anziché accesso diretto all'attributo:
```python
profiles = self.manager.profiles # Chiama la property
for profile in profiles:
# ...
```
### Type Hints
Aggiornati i type hints per riflettere l'uso di `GUIProfileAdapter`:
```python
def __init__(self, parent: tk.Tk, manager: GUIProfileAdapter, ...)
```
## Vantaggi
1. **Nessuna modifica alla logica GUI**: Il codice dell'interfaccia rimane invariato
2. **Uso trasparente della nuova struttura**: Sotto il cofano usa targets e models
3. **Caricamento automatico**: Legge `targets.ini` all'avvio se disponibile
4. **Retrocompatibilità**: Il vecchio codice continua a funzionare
5. **Migrazione graduale**: Si può aggiornare il GUI in futuro per usare direttamente la nuova API
## Limitazioni Attuali
L'adapter è **read-only** per alcune operazioni:
- `add_profile()` e `update_profile()` sono stub (non completamente implementati)
- Questo è intenzionale: la gestione dei profili tramite GUI sarà deprecata
- Gli utenti dovrebbero modificare `flash_profiles.json` direttamente o usare gli script di utility
## Test
✓ Applicazione avviata senza errori
✓ Caricamento automatico da `targets.ini`
✓ Visualizzazione corretta di 9 target
✓ Nessun errore di tipo o attributo
## Prossimi Passi
- [ ] Implementare completamente `add_profile` e `update_profile` nell'adapter
- [ ] Migliorare il dialog di gestione profili per supportare selezione modello
- [ ] Aggiungere validazione dei profili prima di usarli
- [ ] Mostrare informazioni avanzate (aree Golden/User, settori, ecc.) nell'interfaccia