A lot less lines for the same functionalities!
This includes improvements too:
* "include-pointer" as new PDB argument;
* settings storage thanks to GimpProcedureDialog;
* it should hopefully work better in non-interactive (though it's untested).
The macOS and Windows screenshots are untested after this change, though they
should still work the same. Please report if there is any problem!
On recent KDE, the screenshot plug-in fails with an authorization error,
unless we add a desktop file with a special KDE-only desktop entry to
give the permission, which seems a bit over-the-top (if we were to add a
desktop file for every plug-in, and with dedicated entries to every
desktop environment out there, it's never-ending). Of course, we are not
against either, but nobody has contributed a patch doing this in the
last year anyway.
Also Méven (KDE dev) was telling us that KDE recommends to use the
Freedesktop portal nowadays. So maybe let's just move on from the
KDE-specific portal, just as we did recently for the GNOME portal too.
This should hopefully take care of all permission issues and in the same
time simplifies the code.
Note that the Freedesktop API might miss some of the features (this was
one of the reason we were avoiding putting it as priority implementation
until now, to avoid feature regression), but the more we go, the less we
have a choice. It's either this or always fighting against the current.
Turn the boolean "root" argument into enum ShootType and reorder that
enum to { WINDOW, ROOT, REGION } so that the "0", and "1" values match
the former boolean. Adapt parameter checking accordingly so that
callers without optional arguments (e.g. script-fu) can call all the
plug-ins's features.
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
This indicates if a delay can be inserted in-between the window pick and
the actual shot. This is indeed not always possible, for instance using
KWin API. Obviously this feature is only meaningful if
SCREENSHOT_CAN_PICK_WINDOW feature is enabled as well. For instance X11
screenshot has the feature, but GNOME won't need it since there is no
window selection (it simply snaps whatever is the active window).
... and a delay before the screenshot.
Until now, there was only delay before selection, which I changed in
commits d9cd4b61bc and 614bcf6d0a. Actually a delay before selection may
also be useful, for instance when you use a tablet without keyboard (no
alt-tab possible) and the window/area you wish to capture is behind GIMP
window. Then you'd want to interact with the desktop with the pointer
before the cursor changes for selection interaction.
I add some logics so that the selection delay doesn't show when it is
unecessary (for instance for full-screen screenshot, or when the window
screenshot is based on the active window, not click selection, like with
GNOME shell API).
Only thing I could not properly figure out yet is how to select an area.
The "screenshotArea" method is there in KDE API, but it needs
coordinates and I can't find the API to grab coordinates in Wayland (as
in GNOME shell API).
Add color management options to the screenshot plug-in:
By default, it tries to tag the image with the monitor profile;
alternatively, there is an option to convert the image to sRGB.
This works mostly fine on *one* monitor given its profile is
configured correctly. With more than one monitor, funny things happen
depending on the platform and on what we are shooting (window, screen,
area). There are some FIXMEs left in the code.
Some more abstraction in the screenshot plug-in, now allows for
runtime backend selection. Add stubs for the gnome-shell backend,
registers itself as unavailable because it's still unimplemented.
Move OS X and X11 specific code to its own files, to prepare for more
shooting backends being added. Also remove unimplemented G_OS_WIN32
stubs, if anyone feels like implementing a Windows backend, by all
means go ahead.
Jehan