adminandClaude Sonnet 5
a4733c156b
Nach dem ersten Live-Test mit echtem Bridge-Prozess: der bisherige ConfirmDialog fiel zu wenig auf, wenn LehrerApp im Hintergrund lief (Normalfall, da der Anstoß vom KI-Client in einem anderen Fenster kommt). Neuer, eigenständiger McpConfirmDialog statt Änderung am geteilten ConfirmDialog (hätte alle anderen Aufrufer mitbetroffen): breiter, auffälliger Kopfbereich, Topmost. AvaloniaMcpConfirmationService holt das Hauptfenster zusätzlich aus einer möglichen Minimierung und aktiviert es vor dem Anzeigen. move_lesson kapselt die bereits vorhandene LessonSchedulingService.Move (shiftFollowingLessons öffnet eine Lücke für eine neue Stunde, indem spätere Stunden derselben Einheit mitverschoben werden) - keine neue Terminlogik, nur Wiederverwendung. delete_lesson ist eine bewusste, gezielte Ausnahme von "v1 ohne Lösch-Tools" auf expliziten Nutzerwunsch: eigene AllowedDestructiveWriteTools-Liste, Destructive=true-Annotation, Bestätigungstext betont ausdrücklich die fehlende Papierkorb-Deckung für Lessons. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
58 lines
2.6 KiB
C#
58 lines
2.6 KiB
C#
using Avalonia;
|
|
using Avalonia.Controls;
|
|
using Avalonia.Controls.ApplicationLifetimes;
|
|
using Avalonia.Threading;
|
|
using LehrerApp.Desktop.Views.Mcp;
|
|
|
|
namespace LehrerApp.Desktop.Services.Mcp;
|
|
|
|
/// <summary>
|
|
/// Produktive <see cref="IMcpConfirmationService"/>-Implementierung: zeigt <see cref="McpConfirmDialog"/>
|
|
/// über dem Hauptfenster an. Der aufrufende Tool-Handler läuft auf einem Hintergrund-Thread
|
|
/// (MCP-Pipe-Session in <see cref="McpServerHostedService"/>), deshalb Marshalling über
|
|
/// <see cref="Dispatcher.UIThread"/>.
|
|
///
|
|
/// Nutzer-Feedback: der Dialog fiel zu wenig auf, wenn LehrerApp im Hintergrund lief (naheliegend,
|
|
/// da der Anstoß von einem KI-Client in einem anderen Fenster kommt) — deshalb wird das Hauptfenster
|
|
/// vor dem Anzeigen aus einer möglichen Minimierung geholt und aktiviert, und der Dialog selbst
|
|
/// läuft `Topmost`.
|
|
///
|
|
/// Ohne Reaktion des Nutzers würde die Pipe-Session (und damit der wartende KI-Client) unbegrenzt
|
|
/// hängen bleiben — nach <see cref="Timeout"/> wird der Dialog automatisch geschlossen und die
|
|
/// Änderung als abgelehnt gewertet.
|
|
/// </summary>
|
|
public sealed class AvaloniaMcpConfirmationService : IMcpConfirmationService
|
|
{
|
|
private static readonly TimeSpan Timeout = TimeSpan.FromMinutes(2);
|
|
|
|
public async Task<bool> ConfirmAsync(string title, string message, CancellationToken ct)
|
|
{
|
|
if (Application.Current?.ApplicationLifetime is not IClassicDesktopStyleApplicationLifetime { MainWindow: { } owner })
|
|
return false;
|
|
|
|
// Die gesamte Warte-/Timeout-Logik läuft als ein Stück innerhalb des UI-Thread-Callbacks:
|
|
// Avalonias Dispatcher-Synchronisationskontext sorgt dafür, dass die Fortsetzung nach
|
|
// "await Task.WhenAny(...)" wieder auf dem UI-Thread läuft, sodass dialog.Close() dort
|
|
// sicher aufgerufen werden kann.
|
|
return await Dispatcher.UIThread.InvokeAsync(async () =>
|
|
{
|
|
if (owner.WindowState == WindowState.Minimized) owner.WindowState = WindowState.Normal;
|
|
owner.Activate();
|
|
|
|
var dialog = new McpConfirmDialog
|
|
{
|
|
DataContext = new McpConfirmDialogInfo { Title = title, Message = message, ConfirmText = "Übernehmen" },
|
|
};
|
|
var dialogTask = dialog.ShowDialog<bool>(owner);
|
|
var timeoutTask = Task.Delay(Timeout, ct);
|
|
var completed = await Task.WhenAny(dialogTask, timeoutTask);
|
|
if (completed != dialogTask)
|
|
{
|
|
dialog.Close(false);
|
|
return false;
|
|
}
|
|
return await dialogTask;
|
|
});
|
|
}
|
|
}
|