Xdg desktop portal что это
xdg-desktop-portal provides a portal frontend service for Flatpak, Snap, and possibly other desktop containment/sandboxing frameworks. This service is made available to the sandboxed application, and provides mediated D-Bus interfaces for file access, URI opening, printing and similar desktop integration features.
The implementation of these interfaces is expected to require user confirmation before responding to the sandboxed application's requests. For example, when the sandboxed application ask to open a file, the portal implementation will open an "Open" dialog outside the sandbox, and will only make the selected file available to the sandboxed app if that dialog is confirmed.
xdg-desktop-portal is designed to be desktop-agnostic, and uses a desktop-environment-specific GUI backend such as xdg-desktop-portal-gtk to provide its functionality.
Загрузка xdg-desktop-portal
| Архитектура | Размер пакета | В установленном виде | Файлы |
|---|---|---|---|
| amd64 | 207,8 Кб | 1 122,0 Кб | [список файлов] |
| arm64 | 197,9 Кб | 1 090,0 Кб | [список файлов] |
| armel | 165,2 Кб | 850,0 Кб | [список файлов] |
| armhf | 170,2 Кб | 670,0 Кб | [список файлов] |
| i386 | 215,1 Кб | 1 194,0 Кб | [список файлов] |
| mips | 155,3 Кб | 1 191,0 Кб | [список файлов] |
| mips64el | 156,1 Кб | 1 236,0 Кб | [список файлов] |
| mipsel | 159,3 Кб | 1 183,0 Кб | [список файлов] |
| ppc64el | 220,7 Кб | 1 534,0 Кб | [список файлов] |
| s390x | 188,7 Кб | 1 166,0 Кб | [список файлов] |
Эта страница также доступна на следующих языках (Как установить язык по умолчанию):
Авторские права © 1997 - 2021 SPI Inc.; См. условия лицензии. Debian это торговый знак компании SPI Inc. Об этом сайте.
Xdg desktop portal что это
A portal frontend service for Flatpak and possibly other desktop containment frameworks.
xdg-desktop-portal works by exposing a series of D-Bus interfaces known as portals under a well-known name (org.freedesktop.portal.Desktop) and object path (/org/freedesktop/portal/desktop).
The portal interfaces include APIs for file access, opening URIs, printing and others.
Documentation for the available D-Bus interfaces can be found here.
xdg-desktop-portal depends on GLib and Flatpak. To build the documentation, you will need xmlto and the docbook stylesheets.
Flatpak grants sandboxed applications talk access to names in the org.freedesktop.portal.* prefix. One possible way to use the portal APIs is thus just to make D-Bus calls. For many of the portals, toolkits (e.g. GTK+) are expected to support portals transparently if you use suitable high-level APIs.
To implement most portals, xdg-desktop-portal relies on a backend that provides implementations of the org.freedesktop.impl.portal.* interfaces. Different backends are available see:
- GTK xdg-desktop-portal-gtk
- GNOME xdg-desktop-portal-gnome
- KDE xdg-desktop-portal-kde
- Pantheon (Elementary) xdg-desktop-portal-pantheon
- wlroots xdg-desktop-portal-wlr
There are several reasons for the frontend/backend separation of the portal code:
- We want to have native portal dialogs that match the session desktop (i.e. GTK+ dialogs for GNOME, Qt dialogs for KDE)
- One of the limitations of the D-Bus proxying in flatpak is that allowing a sandboxed app to talk to a name implicitly also allows it to talk to any other name owned by the same unique name. Therefore, sandbox-facing D-Bus apis should generally be hosted on a dedicated bus connection. For portals, the frontend takes care of this for us.
- The frontend can handle all the interaction with portal infrastructure, such as the permission store and the document store, freeing the backends to focus on just providing a user interface.
- The frontend can also handle argument validation, and be strict about only letting valid requests through to the backend.
The portal apis are all following the pattern of an initial method call, whose response returns an object handle for an org.freedesktop.portal.Request object that represents the portal interaction. The end of the interaction is done via a Response signal that gets emitted on that object. This pattern was chosen over a simple method call with return, since portal apis are expected to show dialogs and interact with the user, which may well take longer than the maximum method call timeout of D-Bus. Another advantage is that the caller can cancel an ongoing interaction by calling the Cancel method on the request object.
One consideration for deciding the shape of portal APIs is that we want them to 'hide' behind existing library APIs where possible, to make it as easy as possible to have apps use them transparently. For example, the OpenFile portal is working well as a backend for the GtkFileChooserNative API.
When it comes to files, we need to be careful to not let portal apis subvert the limited filesystem view that apps have in their sandbox. Therefore, files should only be passed into portal APIs in one of two forms:
- As a document ID referring to a file that has been exported in the document portal
- As an open fd. The portal can work its way back to a file path from the fd, and passing an fd proves that the app inside the sandbox has access to the file to open it.
When it comes to processes, passing pids around is not useful in a sandboxed world where apps are likely in their own pid namespace. And passing pids from inside the sandbox is problematic, since the app can just lie.
Xdg desktop portal что это
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
A portal frontend service for Flatpak and possibly other desktop containment frameworks.
xdg-desktop-portal works by exposing a series of D-Bus interfaces known as portals under a well-known name (org.freedesktop.portal.Desktop) and object path (/org/freedesktop/portal/desktop).
The portal interfaces include APIs for file access, opening URIs, printing and others.
Documentation for the available D-Bus interfaces can be found here.
xdg-desktop-portal depends on GLib and Flatpak. To build the documentation, you will need xmlto and the docbook stylesheets.
Flatpak grants sandboxed applications talk access to names in the org.freedesktop.portal.* prefix. One possible way to use the portal APIs is thus just to make D-Bus calls. For many of the portals, toolkits (e.g. GTK+) are expected to support portals transparently if you use suitable high-level APIs.
To implement most portals, xdg-desktop-portal relies on a backend that provides implementations of the org.freedesktop.impl.portal.* interfaces. Different backends are available see:
- GTK xdg-desktop-portal-gtk
- GNOME xdg-desktop-portal-gnome
- KDE xdg-desktop-portal-kde
- Pantheon (Elementary) xdg-desktop-portal-pantheon
- wlroots xdg-desktop-portal-wlr
There are several reasons for the frontend/backend separation of the portal code:
- We want to have native portal dialogs that match the session desktop (i.e. GTK+ dialogs for GNOME, Qt dialogs for KDE)
- One of the limitations of the D-Bus proxying in flatpak is that allowing a sandboxed app to talk to a name implicitly also allows it to talk to any other name owned by the same unique name. Therefore, sandbox-facing D-Bus apis should generally be hosted on a dedicated bus connection. For portals, the frontend takes care of this for us.
- The frontend can handle all the interaction with portal infrastructure, such as the permission store and the document store, freeing the backends to focus on just providing a user interface.
- The frontend can also handle argument validation, and be strict about only letting valid requests through to the backend.
The portal apis are all following the pattern of an initial method call, whose response returns an object handle for an org.freedesktop.portal.Request object that represents the portal interaction. The end of the interaction is done via a Response signal that gets emitted on that object. This pattern was chosen over a simple method call with return, since portal apis are expected to show dialogs and interact with the user, which may well take longer than the maximum method call timeout of D-Bus. Another advantage is that the caller can cancel an ongoing interaction by calling the Cancel method on the request object.
One consideration for deciding the shape of portal APIs is that we want them to 'hide' behind existing library APIs where possible, to make it as easy as possible to have apps use them transparently. For example, the OpenFile portal is working well as a backend for the GtkFileChooserNative API.
When it comes to files, we need to be careful to not let portal apis subvert the limited filesystem view that apps have in their sandbox. Therefore, files should only be passed into portal APIs in one of two forms:
- As a document ID referring to a file that has been exported in the document portal
- As an open fd. The portal can work its way back to a file path from the fd, and passing an fd proves that the app inside the sandbox has access to the file to open it.
When it comes to processes, passing pids around is not useful in a sandboxed world where apps are likely in their own pid namespace. And passing pids from inside the sandbox is problematic, since the app can just lie.
Другие пакеты, относящиеся к xdg-desktop-portal
- зависимости
- рекомендации
- предложения
- enhances
- dep: bubblewrap setuid wrapper for unprivileged chroot and namespace manipulation
- dep: default-dbus-session-bus виртуальный пакет, предоставляемый dbus-user-session или dbus-session-bus виртуальный пакет, предоставляемый dbus-user-session, dbus-x11
- dep: fuse файловая система в пользовательском окружении
также виртуальный пакет, предоставляемый fuse3 - dep: libc6 (>= 2.28) библиотека GNU C: динамически подключаемые библиотеки
также виртуальный пакет, предоставляемый libc6-udeb - dep: libfontconfig1 (>= 2.12.6) общая библиотека настроек шрифтов (динамическая версия)
- dep: libfuse2 (>= 2.9) файловая система в пользовательском пространстве (библиотека)
- dep: libgdk-pixbuf2.0-0 (>= 2.22.0) библиотека GDK Pixbuf
- dep: libglib2.0-0 (>= 2.45.6) библиотека С-функций
- dep: libpipewire-0.2-1 (>= 0.2.2) служба для обработки аудио и видео в реальном времени — библиотеки
Пакет: xdg-desktop-portal (1.2.0-1)
xdg-desktop-portal provides a portal frontend service for Flatpak, Snap, and possibly other desktop containment/sandboxing frameworks. This service is made available to the sandboxed application, and provides mediated D-Bus interfaces for file access, URI opening, printing and similar desktop integration features.
The implementation of these interfaces is expected to require user confirmation before responding to the sandboxed application's requests. For example, when the sandboxed application ask to open a file, the portal implementation will open an "Open" dialog outside the sandbox, and will only make the selected file available to the sandboxed app if that dialog is confirmed.
xdg-desktop-portal is designed to be desktop-agnostic, and uses a desktop-environment-specific GUI backend such as xdg-desktop-portal-gtk to provide its functionality.
Другие пакеты, относящиеся к xdg-desktop-portal
- зависимости
- рекомендации
- предложения
- enhances
- dep: bubblewrap [не alpha, ia64, m68k, sh4, sparc64] utility for unprivileged chroot and namespace manipulation
- dep: default-dbus-session-bus виртуальный пакет, предоставляемый dbus-user-session или dbus-session-bus виртуальный пакет, предоставляемый dbus-user-session, dbus-x11
- dep: fuse файловая система в пользовательском окружении
- dep: libc6 (>= 2.27) [sh4] библиотека GNU C: динамически подключаемые библиотеки
также виртуальный пакет, предоставляемый libc6-udeb dep: libc6 (>= 2.28) [не alpha, ia64, m68k, sh4, sparc64] dep: libc6 (>= 2.7) [m68k, sparc64] - dep: libc6.1 (>= 2.27) [ia64] библиотека GNU C: динамически подключаемые библиотеки
также виртуальный пакет, предоставляемый libc6.1-udeb dep: libc6.1 (>= 2.7) [alpha] - dep: libfuse2 (>= 2.9) файловая система в пользовательском пространстве (библиотека)
- dep: libgdk-pixbuf-2.0-0 (>= 2.22.0) [не alpha, ia64, m68k, sh4, sparc64] библиотека GDK Pixbuf
- dep: libglib2.0-0 (>= 2.45.6) [alpha, ia64, m68k, sh4, sparc64] библиотека С-функций dep: libglib2.0-0 (>= 2.70.0) [не alpha, ia64, m68k, sh4, sparc64]
- dep: libjson-glib-1.0-0 (>= 1.5.2) [не alpha, ia64, m68k, sh4, sparc64] библиотека GLib для манипуляции данными JSON
- dep: libpipewire-0.3-0 (>= 0.3.10) [не alpha, ia64, m68k, sh4, sparc64] служба для обработки аудио и видео в реальном времени — библиотеки
Загрузка xdg-desktop-portal
| Архитектура | Версия | Размер пакета | В установленном виде | Файлы |
|---|---|---|---|---|
| alpha (неофициальный перенос) | 1.0.3-1 | 169,2 Кб | 1 141,0 Кб | [список файлов] |
| amd64 | 1.10.1-2 | 271,6 Кб | 1 467,0 Кб | [список файлов] |
| arm64 | 1.10.1-2 | 258,6 Кб | 1 455,0 Кб | [список файлов] |
| armel | 1.10.1-2 | 237,4 Кб | 1 219,0 Кб | [список файлов] |
| armhf | 1.10.1-2 | 229,2 Кб | 907,0 Кб | [список файлов] |
| hppa (неофициальный перенос) | 1.10.1-2 | 227,3 Кб | 1 370,0 Кб | [список файлов] |
| i386 | 1.10.1-2 | 282,7 Кб | 1 571,0 Кб | [список файлов] |
| ia64 (неофициальный перенос) | 1.0.3-1 | 189,7 Кб | 1 701,0 Кб | [список файлов] |
| m68k (неофициальный перенос) | 1.0.3-1 | 154,2 Кб | 786,0 Кб | [список файлов] |
| mips64el | 1.10.1-2 | 201,7 Кб | 1 607,0 Кб | [список файлов] |
| mipsel | 1.10.1-2 | 206,4 Кб | 1 562,0 Кб | [список файлов] |
| ppc64 (неофициальный перенос) | 1.10.1-2 | 276,6 Кб | 2 172,0 Кб | [список файлов] |
| ppc64el | 1.10.1-2 | 286,7 Кб | 1 979,0 Кб | [список файлов] |
| riscv64 (неофициальный перенос) | 1.10.1-2 | 236,2 Кб | 1 062,0 Кб | [список файлов] |
| s390x | 1.10.1-2 | 248,7 Кб | 1 511,0 Кб | [список файлов] |
| sh4 (неофициальный перенос) | 1.0.3-1 | 158,0 Кб | 759,0 Кб | [список файлов] |
| sparc64 (неофициальный перенос) | 1.0.3-1 | 130,1 Кб | 845,0 Кб | [список файлов] |
| x32 (неофициальный перенос) | 1.10.1-2 | 273,4 Кб | 1 331,0 Кб | [список файлов] |
Эта страница также доступна на следующих языках (Как установить язык по умолчанию):
Авторские права © 1997 - 2021 SPI Inc.; См. условия лицензии. Debian это торговый знак компании SPI Inc. Об этом сайте.
Читайте также: