web-page.c was left as additional font
sizes besides the GUI choices could be set
via a PDB call. The export plug-ins int
combos will be updated in a separate
merge request.
Additionally, the region choice in screenshot.c
was hidden on Windows since it does not
yet implement that option.
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!
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
This was true in the "old world" where X11 support being built-in meant
that X11 screenshot would be usable. Now we must not only check it is
built, but also that we are actually running under X11. Otherwise with a
Wayland compositor, screenshot would fail. Also it meant that the
Freedesktop portal was never tried if both X11 and Wayland support were
built-in.
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).
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.
...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).
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.
Add error reporting to all screenshot backends, but only really use it
in the gnome-shell backend: check all DBus calls for errors instead of
crashing.
Also fix detection if gnome-shell is running: just creating the
GDBusProxy always succeeds, so call org.freedesktop.DBus.Peer.Ping
on the newly created proxy.
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.
Alx Sa