plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
/* GIMP - The GNU Image Manipulation Program
|
|
|
|
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
|
|
|
|
*
|
|
|
|
* Screenshot plug-in
|
|
|
|
* Copyright 1998-2007 Sven Neumann <sven@gimp.org>
|
|
|
|
* Copyright 2003 Henrik Brix Andersen <brix@gimp.org>
|
|
|
|
* Copyright 2016 Michael Natterer <mitch@gimp.org>
|
|
|
|
* Copyright 2017 Jehan <jehan@gimp.org>
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2018-07-12 05:27:07 +08:00
|
|
|
* along with this program. If not, see <https://www.gnu.org/licenses/>.
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include <glib.h>
|
|
|
|
|
|
|
|
#include <libgimp/gimp.h>
|
|
|
|
#include <libgimp/gimpui.h>
|
|
|
|
|
|
|
|
#include "screenshot.h"
|
|
|
|
#include "screenshot-freedesktop.h"
|
|
|
|
|
|
|
|
|
|
|
|
static GDBusProxy *proxy = NULL;
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
screenshot_freedesktop_available (void)
|
|
|
|
{
|
|
|
|
proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SESSION,
|
|
|
|
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START,
|
|
|
|
NULL,
|
|
|
|
"org.freedesktop.portal.Desktop",
|
|
|
|
"/org/freedesktop/portal/desktop",
|
|
|
|
"org.freedesktop.portal.Screenshot",
|
|
|
|
NULL, NULL);
|
|
|
|
|
|
|
|
if (proxy)
|
|
|
|
{
|
|
|
|
GError *error = NULL;
|
|
|
|
|
|
|
|
g_dbus_proxy_call_sync (proxy, "org.freedesktop.DBus.Peer.Ping",
|
|
|
|
NULL,
|
|
|
|
G_DBUS_CALL_FLAGS_NONE,
|
|
|
|
-1, NULL, &error);
|
|
|
|
if (! error)
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
g_clear_error (&error);
|
|
|
|
|
|
|
|
g_object_unref (proxy);
|
|
|
|
proxy = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
ScreenshotCapabilities
|
|
|
|
screenshot_freedesktop_get_capabilities (void)
|
|
|
|
{
|
|
|
|
/* Portal has no capabilities other than root screenshot! */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2019-08-16 17:54:50 +08:00
|
|
|
screenshot_freedesktop_dbus_signal (GDBusProxy *proxy,
|
|
|
|
gchar *sender_name,
|
|
|
|
gchar *signal_name,
|
|
|
|
GVariant *parameters,
|
|
|
|
GimpImage **image)
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
{
|
|
|
|
if (g_strcmp0 (signal_name, "Response") == 0)
|
|
|
|
{
|
|
|
|
GVariant *results;
|
|
|
|
guint32 response;
|
|
|
|
|
|
|
|
g_variant_get (parameters, "(u@a{sv})",
|
|
|
|
&response,
|
|
|
|
&results);
|
|
|
|
|
|
|
|
/* Possible values:
|
|
|
|
* 0: Success, the request is carried out
|
|
|
|
* 1: The user cancelled the interaction
|
|
|
|
* 2: The user interaction was ended in some other way
|
|
|
|
* Cf. https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Request.xml
|
|
|
|
*/
|
|
|
|
if (response == 0)
|
|
|
|
{
|
|
|
|
gchar *uri;
|
|
|
|
|
|
|
|
if (g_variant_lookup (results, "uri", "s", &uri))
|
|
|
|
{
|
|
|
|
GFile *file = g_file_new_for_uri (uri);
|
|
|
|
|
2019-09-12 03:48:34 +08:00
|
|
|
*image = gimp_file_load (GIMP_RUN_NONINTERACTIVE, file);
|
|
|
|
gimp_image_set_file (*image, g_file_new_for_path ("screenshot.png"));
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
|
|
|
|
/* Delete the actual file. */
|
|
|
|
g_file_delete (file, NULL, NULL);
|
|
|
|
|
|
|
|
g_object_unref (file);
|
|
|
|
g_free (uri);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
g_variant_unref (results);
|
|
|
|
/* Quit anyway. */
|
|
|
|
gtk_main_quit ();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
GimpPDBStatusType
|
|
|
|
screenshot_freedesktop_shoot (ScreenshotValues *shootvals,
|
2018-04-29 23:27:47 +08:00
|
|
|
GdkMonitor *monitor,
|
2019-08-16 17:54:50 +08:00
|
|
|
GimpImage **image,
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
GVariant *retval;
|
|
|
|
gchar *opath = NULL;
|
|
|
|
|
|
|
|
if (shootvals->shoot_type != SHOOT_ROOT)
|
|
|
|
{
|
|
|
|
/* This should not happen. */
|
|
|
|
return GIMP_PDB_EXECUTION_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (shootvals->screenshot_delay > 0)
|
|
|
|
screenshot_delay (shootvals->screenshot_delay);
|
|
|
|
|
|
|
|
retval = g_dbus_proxy_call_sync (proxy, "Screenshot",
|
|
|
|
g_variant_new ("(sa{sv})", "", NULL),
|
|
|
|
G_DBUS_CALL_FLAGS_NONE,
|
|
|
|
-1, NULL, error);
|
|
|
|
g_object_unref (proxy);
|
|
|
|
proxy = NULL;
|
|
|
|
if (retval)
|
|
|
|
{
|
|
|
|
g_variant_get (retval, "(o)", &opath);
|
|
|
|
g_variant_unref (retval);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (opath)
|
|
|
|
{
|
|
|
|
GDBusProxy *proxy2 = NULL;
|
|
|
|
|
|
|
|
proxy2 = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SESSION,
|
|
|
|
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START,
|
|
|
|
NULL,
|
|
|
|
"org.freedesktop.portal.Desktop",
|
|
|
|
opath,
|
|
|
|
"org.freedesktop.portal.Request",
|
|
|
|
NULL, NULL);
|
2019-08-16 17:54:50 +08:00
|
|
|
*image = NULL;
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
g_signal_connect (proxy2, "g-signal",
|
|
|
|
G_CALLBACK (screenshot_freedesktop_dbus_signal),
|
2019-08-16 17:54:50 +08:00
|
|
|
image);
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
|
|
|
|
gtk_main ();
|
|
|
|
g_object_unref (proxy2);
|
|
|
|
g_free (opath);
|
|
|
|
|
|
|
|
/* Signal got a response. */
|
2019-08-16 17:54:50 +08:00
|
|
|
if (*image)
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
{
|
|
|
|
GimpColorProfile *profile;
|
|
|
|
|
|
|
|
/* Just assign profile of current monitor. This will work only
|
|
|
|
* as long as this is a single-display setup.
|
|
|
|
* We need to figure out how to do better color management for
|
|
|
|
* portal screenshots.
|
|
|
|
* TODO!
|
|
|
|
*/
|
2018-04-29 23:27:47 +08:00
|
|
|
profile = gimp_monitor_get_color_profile (monitor);
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
if (profile)
|
|
|
|
{
|
2019-08-16 17:54:50 +08:00
|
|
|
gimp_image_set_color_profile (*image, profile);
|
plug-ins: implementation of the Freedesktop portal for screenshot.
I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).
Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.
See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
2017-12-16 09:15:57 +08:00
|
|
|
g_object_unref (profile);
|
|
|
|
}
|
|
|
|
|
|
|
|
return GIMP_PDB_SUCCESS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return GIMP_PDB_EXECUTION_ERROR;
|
|
|
|
}
|