Dies sind frische Neuigkeiten über eine neue Funktion in Qt 5.15, die sehr aufregend ist.
Traditionell waren Fensterbehandlungen eine ziemlich langweilige Sache. Titel, Limit, Minimieren, Maximieren, Größe ändern, Beenden ... und das war's.
In letzter Zeit haben jedoch immer mehr Anwendungen eine anwendungsspezifische UI und Themen enthalten. Ein paar Screenshots, um zu erklären, was hier gesagt wird:
MacOS macht das schon seit geraumer Zeit.
... und Chrome und jeden anderen Webbrowser.
Das Einbetten von Menüs in Ihr Design kann viel Platz auf dem Bildschirm sparen.
...oder es könnte für Branding oder Design wichtig sein.
Leider waren solche Dinge bisher mit Qt nicht möglich.
Es war jedoch möglich, die Dekoration vom Fenster zu entfernen, d. H.:
Window {
flags: Qt.FramelessWindowHint
}
Aber das ließ Sie nur mit einem undekorierten Fenster zurück. Es konnte also nicht verschoben oder geändert werden. Wenn Sie dann versucht haben, das Fenster zu verschieben oder die Größe zu ändern, indem Sie die Maus greifen und die Größe und Position des Fensters manuell einstellen, werden Sie schnell feststellen, dass dies nicht sehr gut funktioniert. Fenstermanager haben in der Regel ein sehr spezifisches Verhalten beim Verschieben oder Ändern der Größe von Fenstern. Häufige Aktionen sind zum Maximieren nach oben ziehen, auf einer Kachel nach links/rechts ziehen, an anderen Fenstern oder der Taskleiste ausrichten, die Größe zweier Fenster gleichzeitig ändern, wenn sie nebeneinander liegen, und so weiter.
Um fair zu sein, wurde zuvor ein Helfer bereitgestellt - QSizeGrip. Es ermöglicht Ihnen, die Größe jeder beliebigen Fensterecke zu ändern, funktioniert jedoch nur an Ecken, nicht an Fensterrändern, und ist nur für Widget-Anwendungen verfügbar.
Qt 5.15 hat QWindow zwei neue Methoden hinzugefügt: startSystemMove und startSystemResize. Diese Methoden fordern den Fenstermanager auf, seine eigene Größenänderungs- oder Verschiebungsoperation zu übernehmen und zu starten. Das bedeutet, dass das Einrasten, Kacheln usw. wie von Zauberhand funktionieren sollte und die Implementierung des Headers in QML fast zu einem Einzeiler wird:
DragHandler {
onActiveChanged: if (active) window.startSystemMove();
target: null
}
Indem Sie dieses Code-Snippet in ein QtQuick-Element einfügen, rufen alle Ziehvorgangsauslöser den Verschiebungsvorgang des nativen Fensters auf.
startSystemResize funktioniert ähnlich, außer dass es ein Qt::Edges-Argument verwendet, das ein Bitfeld der erfassten Fensterränder ist, d. h. für die untere rechte Ecke würden Sie Folgendes aufrufen:
startSystemResize(Qt.RightEdge | Qt.BottomEdge)
Es ist auch sehr praktisch, da Sie ganz einfach einen Handler für alle vier Fensterrahmen haben und einfach das Rahmenargument wie folgt erstellen können:
DragHandler {
id: resizeHandler
grabPermissions: TapHandler.TakeOverForbidden
target: null
onActiveChanged: if (active) {
const p = resizeHandler.centroid.position;
let e = 0;
if (p.x < border) e |= Qt.LeftEdge;
if (p.x >= width - border) e |= Qt.RightEdge;
if (p.y < border) e |= Qt.TopEdge;
if (p.y >= height - border) e |= Qt.BottomEdge;
window.startSystemResize(e);
}
}
Wenn Sie ein vollständiges Beispiel dafür wünschen, wie dies verwendet werden kann, wurde ein Webbrowser-Mockup mit der neuen API erstellt.
Bitte beachten Sie, dass dies zwar eine plattformübergreifende API ist, aber nicht von allen Plattformen unterstützt wird. startSystemMove wird derzeit auf Wayland, X11, macOS und Windows unterstützt, während startSystemResize hingegen auf Wayland, X11 und Windows unterstützt wird, aber nicht auf macOS.
Um damit umzugehen, geben beide Methoden einen booleschen Wert zurück, der angibt, ob die Operation unterstützt wurde oder nicht. Das bedeutet, wenn Sie die Größenänderung auch unter macOS implementieren möchten, müssen Sie den Rückgabewert von startSystemResize überprüfen und Ihr Bestes geben, um im Fehlerfall einen Fallback zu implementieren, d. H.:
if (!window.startSystemResize(edges)) {
// your fallback code for setting window.width/height manually
}
Weitere Arbeit in Qt wird darin bestehen, Fallbacks oder Abstraktionen bereitzustellen, die die Arbeit für Sie erledigen, aber zumindest sollte Sie nichts davon abhalten, dies selbst zu tun.
Ein weiterer Verbesserungsbereich ist die Vereinbarung mit dem Fenstermanager, ob clientseitiges oder serverseitiges Styling verwendet werden soll. Einige Anwendungen möchten möglicherweise beide Modi unterstützen und den Fenstermanager entscheiden lassen, aber dies ist derzeit nicht möglich. Sobald FramelessWindowHint festgelegt ist, gibt es kein serverseitiges Styling.
Der dritte Bereich ist der Fensterschatten. Zumindest auf Wayland muss der Schatten als Teil der Fensterdekoration gezeichnet werden. Und obwohl es möglich ist, mit QtQuick Schatten zu zeichnen, gibt es derzeit keine Möglichkeit, dem QPA-Plug-in mitzuteilen, welcher Teil der Oberfläche der Schatten und welcher Teil der Fensterrahmen ist, was bedeutet, dass, wenn Sie versuchen, Schatten zu zeichnen, der Fenstermanager wird derzeit den Schattenteil von Fenstern berücksichtigen, und dies wird die Kachelung und das Einrasten mit anderen Fenstern durcheinander bringen. Auf anderen Plattformen zeichnet der Fenstermanager normalerweise Schatten, selbst für clientseitig dekorierte Fenster, daher ist dies ein schwer zu lösendes Problem.
