Интеграция с рабочим столом

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

This information is primarily intended for developers who are new to Linux. However, it is also relevant to desktop-specific Linux applications seeking to target a broader range of Linux environments.

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

Определение локали

Наборы прикладных инструментов, такие как Electron, GTK и Qt, предоставляют встроенную поддержку для определения того, какой языковой стандарт использовать. В противном случае можно использовать функцию setlocale.

Порталы

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

  • Определение статуса сети

  • Открытие файла с помощью средства выбора файла

  • Открытие URIs

  • Preventing the device from suspending, sleeping, or powering off

  • Печать

  • Отправка электронной почты

  • Отображение уведомлений

  • Создание скриншотов и скринкастов

Такие инструменты, как GTK и Qt, обеспечивают прозрачную поддержку порталов.

If you are not using one of these toolkits, it is possible to access the portal API directly. See XDG Desktop Portal for more information.

Уведомления

A number of toolkits and frameworks provide transparent support for Linux desktop notifications. These include Electron, GTK, KDE and QML.

Значки состояния

Status icons are similar to the system tray or taskbar on Windows, or menu bar icons on macOS. These are supported on most Linux distributions through abstractions such as libappindicator.

A number of Linux distributions don’t show status icons. It is still possible to provide a status icon, and it will be shown in some distributions. However, to ensure compatibility, it is recommended to use status icons only in a supplementary manner, rather than relying on them as the only mechanism for providing status information or access to particular features. These include «minimize to tray» (or equivalent) functionality.

XEmbed style icons will function on desktops that support them with the x11 permission.

StatusNotifier

StatusNotifier style icons will not function without extra permissions, as they require talking to a non-hardened host service. Risks include impersonation of other softwares and exploitation of bugs in host services such as image decoders.

To use StatusNotifier, you must at least have the --talk-name=org.kde.StatusNotifierWatcher permission to register an item.

Depending on the exact implementation of StatusNotifier that your application is using, it may need session bus ownership of org.kde.StatusNotifierItem-$PID-$ITEM_ID.

This permission is problematic in Flatpak as the $PID value is often the same in sandboxes, leading to potential conflicts with other applications. However, if needed, the --own-name=org.kde.* permission will allow this.

Предупреждение

This introduces many new risks, including the ability to impersonate any KDE service or application, possibly capturing important user data.

Most implementations of StatusNotifier have dropped this requirement, but known exceptions include Electron versions older than 23.3.0.

Current versions of Electron, Chromium, KNotifications, and libappindicator are known to work without ownership permissions.

Окно управления

Window controls are the buttons used to close, maximize and minimize windows. These vary across Linux desktops, particularly in terms of which controls are shown. Whether applications follow these variations is at their discretion. Providing the exact same controls as used by a particular desktop environment should not be seen as a hard requirement.

From a user experience perspective, it is important to ensure that window controls appear on the same side of the window as in other desktop applications. On Linux, this is the right side of the window (like Windows).

On X11, applications can rely on system-provided title bars if they don’t want to draw their own window controls. For a consistent Wayland experience, applications must always provide their own. Typically, toolkits handle this, but raw Wayland clients can use libdecor for a general solution.

Оконные украшения

If your application uses a dark visual style as well as system-provided window decorations, the GTK_THEME_VARIANT=dark X11 window property should be used to ensure that window decorations match the rest of the application window. This can be done by running:

xprop -f _GTK_THEME_VARIANT 8u -set _GTK_THEME_VARIANT dark

Тематика

Flatpak applications cannot directly use the system theme because flatpaks do not have access to data files or libraries in /usr (where system themes are typically located). The solution is to package themes as flatpaks; relying on the host to have the correct version for every flatpak defeats the portability benefits Flatpak provides. These themes are provided as Extensions to the Freedesktop runtime for Gtk3 themes and to the KDE runtime for Qt themes.

The theming system requires Flatpak 0.8.4+ and applications using up-to-date org.gnome.Platform 3.24+, org.freedesktop.Platform 1.6+, or org.kde.Platform 5.9+.

Установка тем

Instructions for Gtk themes

As of Flatpak 0.10.1, Flatpak can automatically detect the active Gtk theme on the host by reading the value of the gtk-theme DConf key.

If the corresponding theme is packaged as an extension in the remote, Flatpak will automatically install it during flatpak install or flatpak update.

Instructions for Qt themes

There are a few Qt theme extensions packaged on Flathub. To see a list, you can run:

$ flatpak remote-ls --columns=application flathub | grep org.kde.KStyle

Then you can install the theme with:

$ flatpak install flathub org.kde.KStyle.Foo

replacing Foo with the name of the desired theme. The theme needs to be available for the KDE runtime branch used by the application.

Gtk look and feel in Qt applications

On Wayland, starting from the 5.15-22.08+ and 6.5+ branches of the org.kde.Platform runtime, org.kde.WaylandDecoration.QAdwaitaDecorations and org.kde.WaylandDecoration.QGnomePlatform-decoration need to be installed. Please see the upstream usage instructions as well.

These plugins will be part of upstream starting at Qt 6.8.

For older runtimes, org.kde.PlatformTheme.QGnomePlatform and org.kde.WaylandDecoration.QGnomePlatform-decoration need to be installed.

Применение тем

The prerequisite for applying themes in Flatpak is to have the theme available to the application in the sandbox, commonly done by packaging them as theme extensions.

Now the system theme needs to be communicated from the host to the sandbox.

On X11, Gtk3 picks up themes from XSettings. Specifically, on GNOME, the GNOME XSettings daemon gsd-xsettings reads the DConf values and converts them into XSettings values. On GNOME, this should work by default, provided gsd-xsettings is running.

On Wayland, the active theme is exposed via the corresponding Settings portal. This requires the portal backend for the desktop environment to be installed.

Once the theme is installed and exposed in the sandbox, it will be automatically applied, depending on the toolkit or libraries used by the application.

If the theme is not available via Flatpak extensions, or either the Settings portal or XSettings support is lacking, Gtk and Qt applications will fall back to using Adwaita or the default Qt theme.

In that case, either the theme needs to be packaged as an extension, or the application needs to have permission to read the theme and Gtk or Qt settings from the host, usually by giving it filesystem access. This is undesirable in most cases, as it weakens the sandbox and reduces portability. Instead, desktop environments should provide proper support for the Settings portal or XSettings daemon.

If a Gtk theme is not packaged as an extension, an unmaintained extension can be created for it. Please see Creating an unmaintained Gtk theme extension.

Appearance Settings

Appearance settings, such as the Freedesktop color-scheme preference, are also exposed similarly via the respective Settings portal. The application needs to support reading it, and the proper portal backends need to be installed for this to work.

Icons

Since Flatpak 0.8.8, host icons from /usr/share/icons are exposed in the sandbox at /run/host/share/icons and $XDG_DATA_HOME/icons in /run/host/user-share/icons.

~/.icons is a legacy path and should not be used.

Fonts

Flatpak exposes fonts from the host to the sandbox, and the runtime ships the default fontconfig from upstream.

Fonts from /usr/share/fonts are exposed at /run/host/fonts, from /usr/local/share/fonts at /run/host/local-fonts, and from $XDG_DATA_HOME/fonts at /run/host/user-fonts.

~/.fonts is a legacy path and should not be used.

Fontconfig config files from the host are not exposed.