Пользовательские оформления окон на стороне клиента в Qt 5.15

UI, Client, Qt, Design, UX

Это свежие новости о новой функции в Qt 5.15, которая очень порадовала.

Традиционно оформление окон были довольно скучной вещью. Заголовок, ограничить, минимизировать, максимизировать, изменить размер, выйти... и всё.

Однако, в последнее время приложения всё чаще и чаще включают Пользовательский интерфейс приложения (application specific UI) и оформление тем. Пара скриншотов для объяснения, о чем здесь говорится:

MacOS занимается этим довольно давно.

... и Chrome, и любой другой веб-браузер.

Встраивание меню в оформление может сэкономить много места на экране.

... или это может быть важно для брендинга или дизайна.
К сожалению, подобные вещи ранее не были возможны с Qt.
Однако можно было убрать оформление с окна, т. е.:

Window {
    flags: Qt.FramelessWindowHint
}

Но это только оставило вас с окном без оформлея. Таким образом, это не могло быть перемещено или изменено. Если бы вы затем попытались реализовать движение окна или изменить размер, схватив мышь и вручную установив размер и положение окна, вы быстро обнаружили бы, что это не очень-то хорошо. Менеджеры окон, как правило, имеют очень специфическое поведение при перемещении или изменении размеров окон. Обычные действия: перетаскивание вверх, чтобы максимизировать, перетаскивание влево/вправо на плитку, привязка к другим окнам или панели задач, изменение размеров двух окон одновременно, если они расположены рядом друг с другом и так далее.

Справедливости ради, ранее был предоставлен один помощник - QSizeGrip. Он позволяет изменить размер любого заданного угла окна, но работает только с углами, а не с границами окна, и доступен только для приложений виджетов.

В Qt 5.15 было добавлено два новых метода в QWindow: startSystemMove и startSystemResize. Эти методы просят оконный менеджер вступить во владение и начать собственную операцию изменения размера или перемещения. Это означает, что привязка, разбиение на тайлы и так далее, должны работать просто волшебным образом, а реализация заголовка в QML становится почти однострочной:

DragHandler {
    onActiveChanged: if (active) window.startSystemMove();
    target: null
}

Поместив этот фрагмент кода в элемент QtQuick, все триггер операции перетаскивания вызовут операцию перемещения собственного окна.
startSystemResize работает аналогично, за исключением того, что он принимает аргумент Qt::Edges, который является битовым полем границ окна, которые вы захватили, то есть для нижнего правого угла, вы бы вызвали:

startSystemResize(Qt.RightEdge | Qt.BottomEdge)

Это также очень удобно, так как вы можете легко иметь один обработчик для всех четырех границ окна и просто создать аргумент границ следующим образом:

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);
    }
}

Если вы хотите получить полный пример того, как это можно использовать, был сделан макет веб-браузера с использованием нового API.

Обратите внимание, что, хотя это кроссплатформенный API, не все платформы поддерживают его. startSystemMove в настоящее время поддерживается в Wayland, X11, macOS и Windows, в то время как startSystemResize, с другой стороны, поддерживается в Wayland, X11 и Windows, но не в macOS.

Чтобы справиться с этим, оба метода возвращают логическое значение, которое указывает, была ли операция поддержана или нет. Это означает, что если вы хотите реализовать изменение размера и в macOS, вам придется проверить возвращаемое значение startSystemResize и постараться сделать все возможное, чтобы реализовать запасной вариант в случае сбоя, т. е.:

if (!window.startSystemResize(edges)) {
    // your fallback code for setting window.width/height manually
}

Дальнейшая работа в Qt будет заключаться в том, чтобы предоставить запасные варианты или абстракции, которые бы сделали эту работу за вас, но, по крайней мере, ничто не должно помешать вам сделать это самостоятельно.

Другая область улучшения - согласование с оконным менеджером в том, следует ли использовать оформление на стороне клиента или на стороне сервера. Некоторые приложения могут захотеть поддерживать оба режима и позволить оконному менеджеру решать, но в настоящее время это невозможно. После установки FramelessWindowHint оформления на стороне сервера не будет.

Третья область - тень окна. По крайней мере, на Wayland тень должна быть нарисована, как часть оформления окна. И хотя можно рисовать тени с помощью QtQuick, в настоящее время нет способа сообщить плагину QPA, какая часть поверхности является тенью, а какая - оконной рамкой, что означает, что, если вы попытаетесь нарисовать тени, менеджер окон в настоящее время будет рассмотрите теневую часть окна, и это испортит мозаику и привязку с другими окнами. На других платформах диспетчер окон обычно рисует тени, даже для окон, оформленных на стороне клиента, поэтому эту проблему сложно решить.