Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
because they are deprecated.
Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the
libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a
PNG blob of the pixbuf to pass around on the wire and for storage in
pluginrc.
Our plug-ins have no "optional" parameters per-se. Clarify the
description to make explicit that the last 4 parameters are simply only
taken into account when the shoot type is SHOOT-REGION.
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.
... Windows.
Reviewer note (Jehan): I have not built on Windows because I need to
refresh my crossbuild environment, but it looks sane enough, and Gil
previously did good patches. I push as-is, hoping it still builds fine
on Windows. :-)
"magnification-api-win32.h" was not included in the dist!
Note that I know that alphabetical order is wrong. I am planning to
actually change the name of the file (more in line with other filenames)
but I am waiting to finish a review of another patch from Gil before
doing so. So just let it as-is for now! ;-)
(cherry picked from commit a2902790cc)
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
Also avoid global variables when possible. We can just use the data
variable of EnumDisplayMonitors() which will be passed on to the
callback. This is not perfect yet since rectScreensCount is still
global, but let's go for it for now.
Mostly warnings about wrong types for some function parameters.
There is still a single warning remaining about ignoring the #pragma
macro, but I am not sure what to do about this warning. Apparently it is
something specifically for use with Visual Studio. We don't need this,
but since the contributor uses it, let's keep it.
This was lost in commit 966843564d. It's not a big deal since this code
path would only happen when the capture using magnification API fails,
yet we may as well make it perfect.
Also taking the opportunity to change the return type to gboolean for
the various capture functions (though it is technically the same,
semantically we were returning success boolean).
And removing a comment which had been duplicated and left at a the wrong
place.
This fixes bugs 793722 and 796121.
In particular it fixes:
- Single-window screenshot when partly off-screen or covered by another
window.
- Screenshots when display scaling is not 100%.
... from first monitor
While researching the cause for the missing window contents (bug
793722), I noticed that the full screen capture mode was also not
working as expected. No matter how many monitors were connected, it only
ever captured the contents of the main monitor. This patch adjusts the
source rectangle for the BitBlt copy operation so that multiple monitors
are captured correctly.
... thewindow is IE 11.
The screenshot plugin for windows had a problem when capturing
applications that use hardware rendering acceleration (e.g.
Chromium-based Apps, IE11). Those applications seem to render their
content to a device context (DC) that is different from the one that can
be retrieved via GetDCEx(hWnd). So a screenshot that simply copies the
main window DC will be incomplete (see bug attachment) or just plain
black.
This patch removes the code that uses GetDCEx for single window
screenshots and always uses the display device context instead. This
makes sure that all window contents are actually visible in the
screenshot. With this change, we now have to set the source coordinates
in the call to BitBlt() to the window's coordinates to exclude
everything that isn't the window from the screenshot when doing a single
window screenshot.
Review comment by Jehan: as Simon notes in bug 793722, there is a
regression though, which is that this new code cannot capture any part
of a window which is not in any screen. This is still an improvement
because at least for what is on screen, we always get exactly the same
as what is displayed. This is especially true since hardware-accelerated
applications are more and more common. So let's push this first commit
and hope for further improvements.
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
The plug-in dialog GUI was always visible in my full-screen screenshots
on KDE, when no delay. It seems the culprit is their fading out effect
which takes longer than the screenshot to happen, therefore the dialog
was showing up with transparency.
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).