gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
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.
Oleksii Samorukov