IntelSight/ClaudeProjectManager-main
3
0
Fork 0
Code Issues Pull-Requests Actions Pakete Projekte Releases Wiki Aktivität

Anpassungen GUI

Quellcode durchsuchen
Dieser Commit ist enthalten in:
Claude Project Manager
2025-07-08 14:56:05 +02:00
Ursprung 5f32daf3a4
Commit b3eb96566f
6 geänderte Dateien mit 51 neuen und 882 gelöschten Zeilen
Patch-Datei herunterladen Vergleichs-Datei herunterladen Alle Dateien ausklappen Alle Dateien einklappen

161
REFACTORING_GUIDE.md
Datei anzeigen

@ -1,161 +0,0 @@
# Refactoring Guide - MainWindow
## Übersicht
Dieses Dokument beschreibt, wie das Refactoring der `main_window.py` verwaltet wird.
## Feature Flags
Das Refactoring verwendet Feature Flags für schrittweise Migration:
- `USE_GITEA_HANDLER` - Gitea/Git Operationen
- `USE_PROCESS_HANDLER` - Prozess-Management
- `USE_PROJECT_HANDLER` - Projekt-Operationen
- `USE_UI_HELPERS` - UI Hilfs-Funktionen
- `ENABLE_DEBUG_LOGGING` - Debug-Ausgaben
- `FORCE_ORIGINAL_IMPLEMENTATION` - Notfall-Override
## Verwaltung
### CLI-Tool verwenden
```bash
# Status anzeigen
python manage_refactoring.py status
# Einzelnen Handler aktivieren
python manage_refactoring.py enable gitea
python manage_refactoring.py enable process
python manage_refactoring.py enable project
python manage_refactoring.py enable ui
# Alle deaktivieren
python manage_refactoring.py disable-all
# Spezifisches Flag setzen
python manage_refactoring.py set ENABLE_DEBUG_LOGGING true
# Test-Konfiguration erstellen
python manage_refactoring.py test-config
```
### Umgebungsvariablen
Überschreiben die Konfigurationsdatei:
```bash
# Alle Handler aktivieren
export CPM_USE_NEW_HANDLERS=true
# Einzelne Flags
export CPM_USE_GITEA_HANDLER=true
export CPM_USE_PROCESS_HANDLER=false
```
### Konfigurationsdatei
Gespeichert in: `~/.claude_project_manager/refactoring_config.json`
```json
{
"USE_GITEA_HANDLER": false,
"USE_PROCESS_HANDLER": false,
"USE_PROJECT_HANDLER": false,
"USE_UI_HELPERS": false,
"ENABLE_DEBUG_LOGGING": false,
"FORCE_ORIGINAL_IMPLEMENTATION": false
}
```
## Test-Strategie
### Phase 1: UI Helpers
Sicherste Option - nur UI-Hilfsfunktionen
```bash
python manage_refactoring.py disable-all
python manage_refactoring.py enable ui
python main.py # Testen
```
### Phase 2: Project Manager
Projekt-Operationen hinzufügen
```bash
python manage_refactoring.py enable project
python main.py # Testen
```
### Phase 3: Process Manager
Prozess-Management hinzufügen
```bash
python manage_refactoring.py enable process
python main.py # Testen
```
### Phase 4: Gitea Operations
Komplexeste Operationen zuletzt
```bash
python manage_refactoring.py enable gitea
python main.py # Vollständig refactored
```
## Rollback
Bei Problemen:
```bash
# Sofort alle neuen Handler deaktivieren
python manage_refactoring.py disable-all
# Oder Notfall-Override in der Anwendung
export CPM_FORCE_ORIGINAL_IMPLEMENTATION=true
```
## Entwicklung
### Neue Handler hinzufügen
1. Handler-Klasse in `gui/handlers/` erstellen
2. In `gui/handlers/__init__.py` exportieren
3. In `MainWindow._init_handlers()` initialisieren
4. Feature Flag in `gui/config.py` hinzufügen
5. Facade-Methoden in `MainWindow` erstellen
### Handler implementieren
```python
# In MainWindow - Facade Pattern
def some_method(self, *args):
"""Method description - Facade"""
if hasattr(self, '_handler') and self.REFACTORING_FLAGS.get('USE_MY_HANDLER', False):
return self._handler.some_method(*args)
else:
return self._original_some_method(*args)
def _original_some_method(self, *args):
"""Original implementation"""
# Existing code here
```
## Monitoring
Logs prüfen für Refactoring-Status:
```bash
# In den Logs suchen
grep "Refactoring" app.log
grep "handler initialized" app.log
```
## Bekannte Probleme
1. **Duplizierte Methoden**: Einige Methoden existieren mehrfach
- `manage_branches`, `link_to_gitea` - Placeholder vs. Implementierung
- `test_gitea_connection`, `verify_repository_on_gitea` - Verschiedene Versionen
2. **Fehlende Methoden**: Einige erwartete Methoden fehlen
- `show_git_status`, `commit_changes` - Möglicherweise umbenannt
Diese werden in Phase 4 und 5 des Refactorings adressiert.

324
REFACTORING_PLAN.md
Datei anzeigen

@ -1,324 +0,0 @@
# Refactoring Plan: main_window.py
## 🎯 Ziel
Sichere Refaktorierung der `gui/main_window.py` (2.704 Zeilen, 81 Methoden) ohne Breaking Changes.
## 📊 Ausgangslage
### Datei-Statistiken
- **Datei**: `gui/main_window.py`
- **Zeilen**: 2.704
- **Methoden**: 81
- **Problem**: God Class Anti-Pattern, duplizierte Methoden, überlange Funktionen
### Identifizierte Duplikate
```
Zeile 1844 & 2602: verify_repository_on_gitea()
Zeile 1462 & 2388: manage_branches()
Zeile 1466 & 2444: link_to_gitea()
Zeile 1809 & 2503: test_gitea_connection()
```
### Überlange Methoden
```
init_and_push_to_gitea: 211 Zeilen
push_to_gitea: 184 Zeilen
verify_repository_on_gitea: 104 Zeilen
test_gitea_connection: 99 Zeilen
```
## 🛡️ Sicherheitsprinzipien
1. **Keine Breaking Changes** - Alle bestehenden Funktionen bleiben erhalten
2. **Facade Pattern** - Alte APIs bleiben, leiten intern um
3. **Feature Flags** - Neuer Code kann zur Laufzeit aktiviert/deaktiviert werden
4. **Schrittweise Migration** - Kleine, reversible Änderungen
## 📋 Phasen-Plan
### Phase 0: Vorbereitung
```bash
# 1. Backup erstellen
git checkout -b refactoring/main-window-backup
git add -A && git commit -m "Backup before refactoring"
# 2. Tests erstellen
# Datei: tests/test_main_window_api.py
# - Dokumentiere alle public methods
# - Erstelle Smoke Tests für kritische Funktionen
```
### Phase 1: Duplikate-Analyse
**WICHTIG: In dieser Phase wird KEIN Code geändert!**
```python
# Aufgaben für KI:
1. Vergleiche die duplizierten Methoden Zeile für Zeile
2. Dokumentiere Unterschiede in DUPLICATE_ANALYSIS.md
3. Identifiziere welche Version wo aufgerufen wird
4. Empfehle welche Version behalten werden soll
```
### Phase 2: Handler-Struktur erstellen
#### Neue Dateistruktur:
```
gui/
├── main_window.py # Original, wird schrittweise reduziert
├── handlers/
│ ├── __init__.py
│ ├── gitea_operations.py # Git/Gitea Operationen
│ ├── process_manager.py # Prozess-Überwachung
│ ├── project_manager.py # Projekt-Operationen
│ └── ui_helpers.py # Dialog und UI-Hilfen
```
#### Beispiel-Implementation:
```python
# gui/handlers/gitea_operations.py
class GiteaOperationsHandler:
def __init__(self, main_window):
self.main_window = main_window
self.repo_manager = main_window.repo_manager
self.project_manager = main_window.project_manager
# Alle benötigten Referenzen
def init_and_push_to_gitea(self, project):
# EXAKTE Kopie der Original-Methode
# TODO: Später refactoren
pass
# gui/main_window.py - Facade Pattern
class MainWindow:
def __init__(self):
# ... existing code ...
self._init_handlers()
def _init_handlers(self):
"""Initialize refactored handlers"""
from gui.handlers.gitea_operations import GiteaOperationsHandler
self._gitea_handler = GiteaOperationsHandler(self)
# Facade method - alte API bleibt
def init_and_push_to_gitea(self, project):
if hasattr(self, '_gitea_handler') and ENABLE_REFACTORED_HANDLERS:
return self._gitea_handler.init_and_push_to_gitea(project)
else:
# Original Code bleibt unverändert
# ... existing code ...
```
### Phase 3: Feature Flags
```python
# gui/config.py
REFACTORING_FLAGS = {
'USE_GITEA_HANDLER': False,
'USE_PROCESS_HANDLER': False,
'USE_PROJECT_HANDLER': False,
'USE_UI_HELPERS': False,
}
# Umgebungsvariable für Tests
import os
if os.getenv('CPM_USE_NEW_HANDLERS'):
REFACTORING_FLAGS['USE_GITEA_HANDLER'] = True
```
### Phase 4: Methoden-Migration (Priorität nach Komplexität)
#### Level 1 - Einfache Methoden (keine/wenige Abhängigkeiten)
```
update_status()
download_log()
load_and_apply_theme()
_show_scrollable_info()
```
#### Level 2 - Moderate Komplexität
```
create_header()
create_content_area()
create_status_bar()
refresh_ui()
```
#### Level 3 - Hohe Komplexität
```
refresh_projects()
add_new_project()
open_project()
delete_project()
```
#### Level 4 - Sehr hohe Komplexität (zuletzt)
```
init_and_push_to_gitea()
push_to_gitea()
manage_branches()
verify_repository_on_gitea()
```
### Phase 5: Refactoring der Handler
Nach erfolgreicher Migration:
```python
# Vorher: 211 Zeilen Methode
def init_and_push_to_gitea(self, project):
# ... 211 Zeilen Code ...
# Nachher: Aufgeteilt in logische Einheiten
class GiteaOperationsHandler:
def init_and_push_to_gitea(self, project):
"""Hauptmethode - koordiniert den Ablauf"""
if not self._validate_project(project):
return False
if not self._ensure_git_initialized(project):
return False
repo = self._create_or_get_repository(project)
if not repo:
return False
return self._push_to_repository(project, repo)
def _validate_project(self, project):
"""Validiert Projekt-Voraussetzungen"""
# ~20 Zeilen
def _ensure_git_initialized(self, project):
"""Stellt sicher dass Git initialisiert ist"""
# ~30 Zeilen
def _create_or_get_repository(self, project):
"""Erstellt oder holt Repository von Gitea"""
# ~50 Zeilen
def _push_to_repository(self, project, repo):
"""Führt den Push durch"""
# ~40 Zeilen
```
## 🧪 Test-Strategie
### 1. API-Kompatibilitäts-Tests
```python
# tests/test_api_compatibility.py
def test_all_public_methods_exist():
"""Stellt sicher dass alle öffentlichen Methoden noch existieren"""
window = MainWindow()
required_methods = [
'init_and_push_to_gitea',
'push_to_gitea',
'manage_branches',
# ... alle 81 Methoden
]
for method in required_methods:
assert hasattr(window, method), f"Method {method} missing!"
```
### 2. Verhaltens-Tests
```python
# tests/test_behavior.py
def test_gitea_push_workflow():
"""Testet kompletten Push-Workflow"""
# 1. Projekt erstellen
# 2. Git initialisieren
# 3. Push zu Gitea
# 4. Verifizieren
```
### 3. Performance-Tests
```python
# tests/test_performance.py
def test_refactoring_performance():
"""Vergleicht Performance vor/nach Refactoring"""
# Messe Zeit für kritische Operationen
# Stelle sicher dass keine Regression
```
## 🔄 Rollback-Plan
### 1. Git-Strategie
```bash
# Jede Phase in eigenem Branch
git checkout -b refactoring/phase-1-duplicates
git checkout -b refactoring/phase-2-handlers
# etc.
# Rollback einfach durch Branch-Wechsel
git checkout main
```
### 2. Code-Level Rollback
```python
# Quick disable aller Änderungen
ENABLE_REFACTORED_HANDLERS = False # Sofort alles auf Original
```
### 3. Methoden-Level Rollback
```python
def init_and_push_to_gitea(self, project):
if FORCE_ORIGINAL_IMPLEMENTATION:
return self._init_and_push_to_gitea_original(project)
# ... rest of facade code
```
## 📊 Erfolgs-Metriken
### Muss-Kriterien (Go/No-Go)
- [ ] Alle bestehenden Features funktionieren
- [ ] Keine Performance-Regression (±5%)
- [ ] Alle Tests grün
- [ ] Keine neuen Bugs gemeldet
### Soll-Kriterien (Qualität)
- [ ] Code-Zeilen pro Datei < 500
- [ ] Methoden-Länge < 50 Zeilen
- [ ] Keine duplizierten Methoden
- [ ] Cyclomatic Complexity < 10 pro Methode
## 🚀 Ausführungs-Anweisungen für KI
### Für jede Phase:
1. **Lese** diese Datei komplett
2. **Erstelle** einen Branch: `git checkout -b refactoring/phase-X`
3. **Implementiere** NUR die beschriebenen Änderungen
4. **Teste** mit den vorgegebenen Tests
5. **Dokumentiere** in `REFACTORING_PROGRESS.md`
6. **Committe** mit aussagekräftiger Message
### Wichtige Regeln:
- **NIEMALS** die Original-Funktionalität brechen
- **IMMER** Facade Pattern für API-Kompatibilität nutzen
- **IMMER** Feature Flags für neue Implementierungen
- **NIEMALS** mehr als eine Phase gleichzeitig
### Bei Problemen:
1. Stoppe sofort
2. Dokumentiere das Problem in `REFACTORING_ISSUES.md`
3. Warte auf menschliche Entscheidung
4. Nutze Rollback wenn nötig
## 📝 Progress Tracking
### Template für REFACTORING_PROGRESS.md:
```markdown
# Refactoring Progress
## Phase 1: Duplikate-Analyse
- Status: ⏳ In Progress / ✅ Complete / ❌ Failed
- Datum: YYYY-MM-DD
- Durchgeführt von: [KI-Name]
- Änderungen:
- ...
- Tests: X/Y bestanden
- Probleme:
- ...
```
---
**WICHTIG**: Dieser Plan ist für schrittweise, sichere Ausführung designed. Jede Phase muss vollständig abgeschlossen und getestet sein, bevor die nächste beginnt.

390
REFACTORING_PROGRESS.md
Datei anzeigen

@ -1,390 +0,0 @@
# Refactoring Progress - main_window.py
## Phase 0: Vorbereitung
- **Status**: ✅ Complete
- **Datum**: 2025-07-05
- **Durchgeführt von**: Claude
- **Branch**: `refactoring/main-window-backup`
### Änderungen:
1. Backup-Branch erstellt: `refactoring/main-window-backup`
2. Commit erstellt: "Backup before refactoring main_window.py - 2658 lines, 67 methods"
3. Test-Verzeichnis erstellt
4. API-Kompatibilitäts-Tests dokumentiert in `tests/test_main_window_api.py`
- 67 öffentliche Methoden dokumentiert
- 11 private Methoden identifiziert
- Test-Struktur für Verhaltenstests vorbereitet
### Aktuelle Datei-Analyse:
- **Dateigröße**: 2.658 Zeilen
- **Methoden gesamt**: 67 (56 öffentlich, 11 privat)
- **Duplizierte Methoden**: 4 Paare
- `manage_branches` (Zeile 1374 & 2336)
- `link_to_gitea` (Zeile 1378 & 2392)
- `test_gitea_connection` (Zeile 1757 & 2457)
- `verify_repository_on_gitea` (Zeile 1792 & 2556)
- **Überlange Methoden** (>50 Zeilen): 16
- Größte: `init_and_push_to_gitea` mit 214 Zeilen
### Tests:
- API-Kompatibilitäts-Tests erstellt
- Mocking-Struktur für GUI-Dependencies vorbereitet
- Behavioral Test-Struktur angelegt (TODO)
### Nächste Schritte:
- Phase 1: Duplikate-Analyse durchführen
- Unterschiede zwischen duplizierten Methoden dokumentieren
- Empfehlungen für Konsolidierung erstellen
---
## Phase 1: Duplikate-Analyse
- **Status**: ✅ Complete
- **Datum**: 2025-07-05
- **Durchgeführt von**: Claude
- **Dokumentation**: DUPLICATE_ANALYSIS.md
### Ergebnisse:
1. **Placeholder-Methoden identifiziert** (können sofort gelöscht werden):
- `manage_branches` (Zeile 1374) - nur "coming soon" Dialog
- `link_to_gitea` (Zeile 1378) - nur "coming soon" Dialog
2. **Methoden mit unterschiedlichen Implementierungen** (müssen zusammengeführt werden):
- `test_gitea_connection` - Erste Version basic, zweite erweitert mit optionalem Parameter
- `verify_repository_on_gitea` - Erste mit Git-Vorprüfung, zweite mit Debug-Info
### Empfehlungen:
- **Sofort**: Placeholder-Methoden löschen (keine Funktionalität verloren)
- **Phase 2**: Bei Handler-Erstellung die zusammenzuführenden Methoden konsolidieren
### Nächste Schritte:
- Phase 2: Handler-Struktur mit Facade Pattern erstellen
- Dabei Duplikate auflösen
---
## Phase 2: Handler-Struktur erstellen
- **Status**: ✅ Complete
- **Datum**: 2025-07-05
- **Durchgeführt von**: Claude
- **Branch**: `refactoring/phase-2-handlers`
### Änderungen:
1. **Handler-Verzeichnis erstellt**: `gui/handlers/`
- `__init__.py` - Export aller Handler
- `gitea_operations.py` - Gitea/Git Operationen
- `process_manager.py` - Prozess-Management
- `project_manager.py` - Projekt-Operationen
- `ui_helpers.py` - UI-Hilfen
- `base_handler.py` - Basis-Klasse
2. **MainWindow mit Facade Pattern erweitert**:
- `_init_handlers()` Methode hinzugefügt
- Feature Flags implementiert (alle standardmäßig False)
- Umgebungsvariable `CPM_USE_NEW_HANDLERS` für Tests
3. **Facade-Methoden implementiert für**:
- `init_and_push_to_gitea` → `_original_init_and_push_to_gitea`
- `push_to_gitea` → `_original_push_to_gitea`
- `test_gitea_connection` → `_original_test_gitea_connection` (v1) und `_original_test_gitea_connection_v2`
- `verify_repository_on_gitea` → `_original_verify_repository_on_gitea` (v1) und `_original_verify_repository_on_gitea_v2`
- `manage_branches` → `_original_manage_branches` (placeholder) und `_original_manage_branches_v2`
- `link_to_gitea` → `_original_link_to_gitea` (placeholder) und `_original_link_to_gitea_v2`
### Tests:
- Handler-Struktur kann mit Umgebungsvariable aktiviert werden
- Alle Original-Funktionen bleiben erhalten
- Keine Breaking Changes
### Probleme:
- Einige erwartete Methoden (show_git_status, commit_changes) scheinen zu fehlen oder anders benannt zu sein
### Nächste Schritte:
- Phase 3: Feature Flags in Konfigurations-Datei verschieben
- Phase 4: Erste einfache Methoden migrieren
---
## Phase 3: Feature Flags Konfiguration
- **Status**: ✅ Complete
- **Datum**: 2025-07-05
- **Durchgeführt von**: Claude
- **Branch**: `refactoring/phase-3-feature-flags`
### Änderungen:
1. **Konfigurations-System erstellt**:
- `gui/config.py` - RefactoringConfig Klasse
- Speichert Flags in `~/.claude_project_manager/refactoring_config.json`
- Unterstützt Umgebungsvariablen-Override
- Debug-Logging und Notfall-Override Flags
2. **Management-Tool entwickelt**:
- `manage_refactoring.py` - CLI für Flag-Verwaltung
- Befehle: status, enable, disable-all, set, test-config
- Ermöglicht schrittweise Aktivierung
3. **MainWindow Integration**:
- Lädt Flags aus Konfiguration statt Hardcoding
- Behält Kompatibilität mit Umgebungsvariablen
4. **Dokumentation**:
- `REFACTORING_GUIDE.md` - Vollständige Anleitung
- Test-Strategie in 4 Phasen
- Rollback-Prozeduren
### Features:
- **Persistente Konfiguration**: Einstellungen bleiben zwischen Starts erhalten
- **Flexible Overrides**: Umgebungsvariablen haben Vorrang
- **Granulare Kontrolle**: Jeder Handler einzeln aktivierbar
- **Notfall-Override**: FORCE_ORIGINAL_IMPLEMENTATION für schnellen Rollback
- **Debug-Support**: ENABLE_DEBUG_LOGGING für Fehlersuche
### Test-Ausgabe:
```
=== Refactoring Configuration Status ===
Config file: /home/hendr/.claude_project_manager/refactoring_config.json
Feature Flags:
USE_GITEA_HANDLER: ❌ DISABLED
USE_PROCESS_HANDLER: ❌ DISABLED
USE_PROJECT_HANDLER: ❌ DISABLED
USE_UI_HELPERS: ❌ DISABLED
ENABLE_DEBUG_LOGGING: ❌ DISABLED
FORCE_ORIGINAL_IMPLEMENTATION: ❌ DISABLED
```
### Nächste Schritte:
- Phase 4: Erste einfache Methoden migrieren
- Beginne mit UI_HELPERS (sicherste Option)
---
## Phase 4: Methoden-Migration (Level 1)
- **Status**: ✅ Complete (erste Methoden)
- **Datum**: 2025-07-05
- **Durchgeführt von**: Claude
- **Branch**: `refactoring/phase-4-simple-methods`
### Migrierte Methoden:
1. **load_and_apply_theme** (UIHelpersHandler)
- Sehr einfache Methode (3 Zeilen)
- Direkt im Handler implementiert
- Facade-Pattern in MainWindow
2. **_show_scrollable_info** (UIHelpersHandler)
- Eigenständige UI-Methode (33 Zeilen)
- Keine externen Abhängigkeiten
- Direkt im Handler implementiert
### Tests:
- Test-Script erstellt: `test_refactoring.py`
- Beide Methoden erfolgreich getestet
- Handler-Initialisierung funktioniert
- Logging bestätigt korrekte Ausführung
### Aktivierung:
```bash
python3 manage_refactoring.py enable ui
```
### Test-Ergebnis:
```
✅ load_and_apply_theme executed successfully
✅ _show_scrollable_info executed successfully
```
### Weitere migrierbare Methoden:
Aus der Analyse sind folgende einfache Methoden identifiziert:
- update_status() - Status-Bar Update
- download_log() - Log-Download
- create_header() - UI-Erstellung
- create_content_area() - UI-Erstellung
- create_status_bar() - UI-Erstellung
### Nächste Schritte:
- Weitere einfache Methoden migrieren
- Schrittweise komplexere Methoden angehen
- Phase 5: Große Methoden refactoren
### Update: Weitere Methoden migriert
- **create_header** ✅ - UI-Erstellung (44 Zeilen)
- **create_status_bar** ✅ - UI-Erstellung (22 Zeilen)
- **on_window_resize** ✅ - Event Handler (10 Zeilen)
### Status:
- **Gesamt migriert**: 5 Methoden
- **Tests**: Alle erfolgreich
- **MIGRATION_STATUS.md** erstellt für detaillierte Übersicht
### Update 2: Weitere Handler aktiviert
- **ProjectManagerHandler** ✅ aktiviert
- delete_project migriert
- **ProcessManagerHandler** ✅ aktiviert
- update_status migriert
- download_log migriert
- **GiteaOperationsHandler** ✅ aktiviert
- test_gitea_connection konsolidiert
- verify_repository_on_gitea konsolidiert
- 2 Placeholder-Methoden entfernt
### Finale Metriken Phase 4:
- **Gesamt migriert**: 10 Methoden (14.9%)
- **Alle 4 Handler aktiviert** (100%)
- **Duplikate**: 2 von 4 aufgelöst
- **Tests**: Alle erfolgreich
---
## Phase 5: Große Methoden refactoren
- **Status**: 🔄 In Progress
- **Datum**: 2025-07-05
- **Durchgeführt von**: Claude
- **Branch**: `refactoring/phase-5-large-methods`
### Ziel:
16 Methoden mit mehr als 50 Zeilen in kleinere, fokussierte Methoden aufteilen.
### Refactored Methods:
#### 1. init_and_push_to_gitea (214 → 8 Methoden) ✅
**Original**: 214 Zeilen monolithische Methode
**Refactored in**:
- `_get_repository_name()` - Repository Name vom Benutzer erhalten
- `_create_gitea_repository()` - Repository auf Gitea erstellen
- `_verify_repository_creation()` - Erstellung verifizieren
- `_initialize_local_repository()` - Lokales Git Repo initialisieren
- `_handle_large_files()` - Große Dateien prüfen und verwalten
- `_commit_and_push()` - Änderungen committen und pushen
- `_determine_repository_owner()` - Owner (User/Org) bestimmen
- `_handle_successful_push()` - Erfolgreichen Push verarbeiten
**Improvements**:
- Single Responsibility für jede Methode
- Bessere Fehlerbehandlung
- Klarere Ablauflogik
#### 2. push_to_gitea (176 → 10 Methoden) ✅
**Original**: 176 Zeilen mit verschachtelter Logik
**Refactored in**:
- `_verify_git_repository()` - Prüfen ob Git Repo existiert
- `_check_remote_configuration()` - Remote Konfiguration prüfen
- `_handle_uncommitted_changes()` - Uncommitted Changes verwalten
- `_check_and_handle_large_files()` - Große Dateien prüfen
- `_remove_large_files_from_git()` - Große Dateien aus Git entfernen
- `_offer_gitignore_creation()` - .gitignore Erstellung anbieten
- `_perform_push()` - Eigentlichen Push durchführen
- `_search_repository_in_all_locations()` - Repo in allen Orten suchen
- `_build_push_issues_message()` - Fehlermeldungen aufbauen
- `_get_push_authentication()` - Authentifizierung erhalten
**Improvements**:
- Klare Trennung zwischen Validierung und Aktion
- Bessere Wiederverwendbarkeit
- Einfachere Testbarkeit
#### 3. manage_large_files (160 → 11 Methoden) ✅
**Original**: 160 Zeilen mit UI und Logik vermischt
**Refactored in**:
- `_scan_for_large_files()` - Nach großen Dateien scannen
- `_show_large_files_dialog()` - Dialog mit Optionen anzeigen
- `_build_large_files_message()` - Nachricht mit Dateiliste erstellen
- `_add_large_files_action_buttons()` - Action Buttons hinzufügen
- `_remove_large_files_action()` - Dateien aus Git entfernen
- `_update_gitignore_with_large_files()` - .gitignore aktualisieren
- `_remove_files_from_git_index()` - Dateien aus Git Index entfernen
- `_commit_large_files_removal()` - Entfernung committen
- `_show_removal_result()` - Ergebnis anzeigen
- `_show_gitignore_content()` - .gitignore Inhalt zeigen
- `_show_git_status_action()` - Git Status anzeigen
**Improvements**:
- UI-Logik von Business-Logik getrennt
- Wiederverwendbare Komponenten
- Bessere Fehlerbehandlung bei jedem Schritt
#### 4. setup_git_lfs (131 → 9 Methoden) ✅
**Original**: 131 Zeilen mit komplexem Dialog-Flow
**Refactored in**:
- `_confirm_lfs_setup()` - LFS Setup Bestätigung
- `_build_lfs_confirmation_message()` - Bestätigungsnachricht aufbauen
- `_initialize_git_lfs()` - Git LFS initialisieren
- `_get_lfs_tracking_choice()` - Tracking-Option vom Benutzer
- `_get_lfs_patterns()` - Patterns basierend auf Auswahl
- `_get_file_type_patterns()` - Dateityp-Patterns erhalten
- `_track_files_with_lfs()` - Dateien mit LFS tracken
- `_offer_lfs_migration()` - Migration zu LFS anbieten
**Improvements**:
- Klarer Dialog-Flow
- Separate Methoden für verschiedene Tracking-Modi
- Bessere Benutzerführung
#### 5. fix_repository_issues (110 → 9 Methoden) ✅
**Original**: 110 Zeilen mit Dialog und Diagnose vermischt
**Refactored in**:
- `_diagnose_repository_issues()` - Repository Probleme diagnostizieren
- `_check_remote_issues()` - Remote Konfiguration prüfen
- `_check_lfs_issues()` - Git LFS Probleme prüfen
- `_show_fix_repository_dialog()` - Dialog mit Optionen anzeigen
- `_add_fix_buttons()` - Passende Fix-Buttons hinzufügen
- `_fix_remote_action()` - Remote URL korrigieren
- `_get_current_organization()` - Aktuelle Organisation erhalten
- `_disable_lfs_action()` - LFS temporär deaktivieren
- `_check_on_gitea_action()` - Repository auf Gitea prüfen
**Improvements**:
- Klare Trennung zwischen Diagnose und Aktion
- Modulare Button-Erstellung basierend auf gefundenen Problemen
- Wiederverwendbare Diagnose-Methoden
### Metriken Phase 5:
- **Refactored**: 5 von 16 großen Methoden (31%)
- **Neue Methoden erstellt**: 47
- **Zeilen reduziert**: 791 → ~35 pro Methode (durchschnittlich)
- **Komplexität**: Deutlich reduziert durch Single Responsibility
### Status Phase 5:
- **Status**: ✅ Complete
- **Abgeschlossen**: 2025-07-05
- Alle identifizierten großen Methoden wurden erfolgreich refactored
- Bei genauerer Prüfung stellte sich heraus, dass viele der ursprünglich als "groß" eingestuften Methoden tatsächlich kleiner waren
- 5 tatsächlich große Methoden (>100 Zeilen) wurden erfolgreich refactored
---
## Zusammenfassung des Refactorings
### Gesamtergebnis:
Das Refactoring der main_window.py wurde erfolgreich abgeschlossen. Die ursprüngliche "God Class" mit 2,658 Zeilen und 67 Methoden wurde systematisch in eine modulare, wartbare Struktur überführt.
### Erreichte Ziele:
1. **Handler-Architektur** ✅
- 4 spezialisierte Handler erstellt
- Klare Trennung der Verantwortlichkeiten
- Facade Pattern für schrittweise Migration
2. **Feature Flags** ✅
- Persistente Konfiguration
- Granulare Kontrolle über Migration
- Rollback-Möglichkeiten
3. **Duplikate aufgelöst** ✅
- 2 von 4 Duplikaten konsolidiert
- 2 Placeholder-Methoden entfernt
4. **Große Methoden refactored** ✅
- 5 Methoden >100 Zeilen in 47 kleinere aufgeteilt
- Single Responsibility Principle angewendet
- Durchschnittliche Methodengröße: ~35 Zeilen
### Verbesserungen:
- **Wartbarkeit**: Deutlich verbesserte Codestruktur
- **Testbarkeit**: Kleinere, fokussierte Methoden
- **Erweiterbarkeit**: Neue Features können in spezifischen Handlern hinzugefügt werden
- **Lesbarkeit**: Klare Methodennamen und Verantwortlichkeiten
### Nächste Empfohlene Schritte:
1. **Tests erweitern**: Unit-Tests für refactored Methoden
2. **Weitere Migration**: Schrittweise mehr Methoden in Handler verschieben
3. **Handler aktivieren**: Feature Flags in Produktion testen
4. **Original-Code entfernen**: Nach erfolgreicher Migration

13
data/projects.json
Datei anzeigen

@ -71,7 +71,18 @@
"cpm"
],
"gitea_repo": null
},
{
"id": "f1a73b61-40ed-4359-b8bb-c35142367e93",
"name": "Metadaten-Crawler",
"path": "C:/Users/hendr/Desktop/IntelSight/Projektablage/Metadaten-Crawler",
"created_at": "2025-07-08T13:51:49.398180",
"last_accessed": "2025-07-08T13:51:49.398180",
"readme_path": "C:/Users/hendr/Desktop/IntelSight/Projektablage/Metadaten-Crawler\\CLAUDE_PROJECT_README.md",
"description": "",
"tags": [],
"gitea_repo": null
}
],
"last_updated": "2025-07-08T12:12:48.006792"
"last_updated": "2025-07-08T13:51:49.398180"
}

41
gui/main_window.py
Datei anzeigen

@ -315,8 +315,9 @@ class MainWindow:
# Get all projects
projects = self.project_manager.get_all_projects()
# Update count
project_count = len([p for p in projects if p.id not in ["vps-permanent", "admin-panel-permanent", "vps-docker-permanent"]])
# Update count (only local projects)
vps_ids = ["vps-permanent", "admin-panel-permanent", "vps-docker-permanent", "activity-server-permanent"]
project_count = len([p for p in projects if p.id not in vps_ids])
self.count_label.configure(text=f"{project_count} project{'s' if project_count != 1 else ''}")
if differential and self.project_tiles:
@ -371,9 +372,41 @@ class MainWindow:
self.create_project_tile_flow(vps_docker_project, current_row_frame, is_vps=True)
tiles_in_current_row += 1
# Add project tiles
# Add Activity Server tile fourth
activity_project = next((p for p in projects if p.id == "activity-server-permanent"), None)
if activity_project:
if tiles_in_current_row >= tiles_per_row:
create_new_row()
self.create_project_tile_flow(activity_project, current_row_frame, is_vps=True)
tiles_in_current_row += 1
# Add separator line between VPS tiles and local projects
separator_frame = ctk.CTkFrame(self.flow_frame, fg_color="transparent")
separator_frame.pack(fill="x", pady=15)
# Use a more visible separator
separator_line = ctk.CTkFrame(
separator_frame,
height=2, # Thicker line
fg_color=COLORS['accent_secondary'] # More visible blue-gray color
)
separator_line.pack(fill="x", padx=20)
# Label for local projects section
local_label = ctk.CTkLabel(
self.flow_frame,
text="Lokale Projekte",
font=FONTS['tile_text'],
text_color=COLORS['text_secondary']
)
local_label.pack(pady=(0, 10))
# Start new row for local projects
create_new_row()
# Add local project tiles
for project in projects:
if project.id not in ["vps-permanent", "admin-panel-permanent", "vps-docker-permanent"]:
if project.id not in vps_ids:
if tiles_in_current_row >= tiles_per_row:
create_new_row()
self.create_project_tile_flow(project, current_row_frame)

4
gui/styles.py
Datei anzeigen

@ -104,8 +104,8 @@ def get_button_styles():
# Window Configuration
WINDOW_CONFIG = {
'title': 'Claude Project Manager',
'width': 1200,
'height': 800,
'width': 1600, # Increased to fit 4 VPS tiles side by side
'height': 1000, # Increased to show Gitea repos without scrolling
'min_width': 800,
'min_height': 600,
}