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.
(cherry picked from commit 870ca6334d)
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.
(cherry picked from commit 3a0c03a61c)
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.
(cherry picked from commit d94b954c2a)
... 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. :-)
(cherry picked from commit 2caa400a96)
"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! ;-)
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).
... 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).
The screenshot-win32.c file was absolutely not following our coding
style. A lot of things are still wrong (like camelCase functions), but
at least I fixed a bunch of indentations, space between function and
arguments, alignments, curly brackets at start of lines, etc.
Delay should indeed happen before root and window screenshots, but must
happen in-between region selection and region screenshot.
One can notice that the logics is different for Windows screenshot in
X11. The reason is that X11 window screenshot has an additional window
selection step (and therefore delay must happen in between selection and
actual screenshot). Window screenshot in Wayland doesn't have this step
and simply screenshots whatever is the currently active Window.
Fix first the delay in X11.
Actually both for region and window screenshots, it makes no sense to
delay *before* region or window selection. Usually when one uses a
delay, the point is to prepare in-between selection and shot. For
instance, I often used a delay to snap the contents of a menu because
PrintScreen key would not work when a menu is opened. So I would set a
delay, select my window/region, then quickly open the menu before the
delay is counting down. This would not be possible with the way delay
occurred (before selection), which just has no use that I can see of.
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).
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
... include mouse pointer.
This is working find and tested under GNOME which already had the code
for it (was only missing the GUI). I added the feature in OSX and X11,
though it is untested. Windows does not seem to have the capability (at
least according to screenshot_win32_get_capabilities() in our code).
It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
Commit e518b97 broke Win32 compilation with a non-defined variable
"monitor". I made a dirty "fix" by using shootvals->monitor.
Apparently, seeing previous comment, that is probably not the right
value but Mitch is on it and I leave him work it out.
At least now it builds.
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.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
