This patch makes it so that you can click the preview for
Original and Rotated images in the Metadata Rotation Import Dialog,
and have it open the image rotated as shown in the preview.
This supplements the existing button options, and matches how other
software works.
When hovering over the images, the cursor turns into a pointer to
further suggest it is clickable.
The "Save"/"Save as" icons that appear in the Quit
Dialog when there are two or more images with unsaved
changes were always sized as GTK_ICON_SIZE_MENU,
or 16px, regardless of icon theme settings.
This patch adds code on Quit Dialog creation to check
the current theme and update the icon size accordingly
via `quit_style_updated ()`.
Note that this is a limited implementation due to the pending
release of GIMP 3.2. It is not connected to notify::custom-icon-size
signals to reduce complexity and potential issues.
In the future, we may move this to the parent GimpMessageDialog
if other dialogs would also benefit from getting a button icon size from
the theme.
This patch replaces adding a custom widget
to the Path Export dialog with a built-in
combobox from gtk_file_chooser_add_choice ().
This makes our code more compatible
with a future port to native file dialogs
in GTK3, without a loss of functionality.
The Canvas Size dialogue and the default options
for it in the Preferences dialogue were listed in
opposite order. This patch puts them in the same
order as the Canvas Size dialogue (Fill with, then
Resize Layers) to keep them consistent.
Procreate swatches are zipped JSON files.
They contain an object array of HSB
color palette values. Newer versions of the
format also support different color models,
spaces, and color profiles.
This patch adds support for importing the
palette name, colors, and associated color
profile in the original HSB format.
In particular, for indexed images, color choice will happen within the
colormap.
The following uses are made context-aware:
* Test tool options color;
* Fill colors.
These other uses will not be context-aware:
* Padding, quick-mask and padding colors;
* Out-of-gamut colors;
* Generically generated color buttons (e.g. in filter dialogs);
* Foreground selection's mask color;
* Grid colors.
Normally the error should not be NULL if file_open_layers() returns no
layers. But just in case, in order not to crash when we could avoid it,
let's double-check.
...if layers won't be resized.
This patch adds code to check if the
"Resize layers" option is set to None and
"Resize Text Layers" is turned off. If so,
then the "Fill With" combobox is not
needed and will be set to insensitive to
reduce confusion. Otherwise, the fill combo
is set to enabled.
This commit updates the hint in the keyboard shortcuts dialog to provide
more detailed instructions on how to edit shortcut keys. The hint now
explains that users need to click on the "Shortcut" column of the corresponding
row to type a new accelerator or press backspace to clear it.
See: https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/issues/594
Rasterizable objects are all created from some side data and can be
renamed automatically based on this data (from the link file for link
layers; from the path for vector layers; from the text for text layers).
So let's share code.
- Getting rid of the dedicated vector layer options dialog (with fill
and stroke settings) which appeared when double-clicking on a vector
layer. This is a duplicated with the Path tool options.
- Double-clicking a vector layer instead will simply start the Path tool
(same as double-clicking a text layer starts the Text tool).
- The path choice settings only is missing from the Path tool options.
Instead of moving it there, I move it to the generic layer options
dialog. I don't think it's the kind of setting you really change often
(most of the time, you likely just make a new vector layer).
- Offsets are ignored too and hidden for vector layers.
- Also making sure that the path changes shows live when editing the
setting in dialog, but it is properly reverted if canceling the
attributes edition.
- Also make sure the undo step changes the path back.
Users were thinking the tutorials are some kind of official docs,
but they are not maintained as the official GIMP help website,
they are more like informal documentation about GIMP made public.
Let's clarify this reordering the buttons.
I think most, if not all, failure cases of file_open_with_proc_and_display()
should allocate a GError by now. But just in case we missed some edge
case, better not crash.
For instance, we were crashing when opening a remote file because of
this line before the previous commit was pushed.
While there are cases when you want to edit the mask straight away (this is
often the case when starting with a white or black mask), in many other cases,
the mask may be already as you want it per its initialization (e.g. when
initializing with a channel, selection, the alpha channel, etc.).
Until now, the Add Mask dialog was always switching to the "Edit Layer Mask"
mode by default, which forced an additional unneeded click each time you created
a mask (and were in a case where you initialize the mask as you want it
directly).
Now adding "Edit mask immediately" feature in the "Add Layer Mask dialog":
* It's checked by default to keep historical behavior.
* As most other dialogs, the last value is remembered, allowing people with
repetitive workflow not to have to repeatedly set the settings each and every
time.
* This default is also visible and settable in Preferences > Interface > Dialog
Defaults.
Fixes following warning, seen on CI:
> ./app/dialogs/about-dialog.c:549:7: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
GIMP supports importing a number of palette formats
such as Adobe Swatch Exchange and SwatchBooker.
However, this is not immediately apparent from the import
palette dialogue.
This patch adds the currently supported palette formats as
filters in the dialogue, both to let users hide irrelevant files from
view and to highlight which formats we support.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
Revert the logic of opening all files as link layers back into loading
their current content as normal layers.
Instead just add a new action dedicated to open images as link layers
and add it to the File menu.
Per UX discussions with Aryeom.
We now re-render a link (by loading its file) immediately upon setting
the new file, i.e. during the calls of gimp_link_new() or
gimp_link_set_file(). As part of this change:
* A GimpLink now stores a GeglBuffer. And this is changed each time a
file change happens (per the GFileMonitor). In particular that also
means that gimp_link_get_buffer() does not reload the image file at
each call for no reasons, and gimp_link_is_broken() does not have a
`recheck` argument either. This is much more efficient.
* These 2 functions also have a GimpProgress and GError now. We use this
among other things to pass on a specific GimpProgress object. In
particular, the image file dialogs now show correct loading
progression again.
* As a general rule, the code is less confusing as we don't have to
wonder whether a GimpLink is ready. We can assume it always is, from
now on.
Note that gimp_link_duplicate() does not trigger a reload of the image
file. Since we assume that the source GimpLink is supposed to be
up-to-date already, we just copy its buffer as-is as an optimization.
This is still mostly a test of workflow. It is based on the idea that
link layers are normal yet enhanced layers: eventually we should be able
to have some improved less-destructive scaling/rotation (even without
NDE transform effects); you can manually drop the link anytime anyway
(hence getting back to the good old fully destructive workflow); any
pixel editing automatically drops the link too.
Now this still raises quite a lot of questions:
* The link can be confusing to people used to the old way and they may
not realize that editing the original file separately would also
update the render in this file (which may not be what they wanted;
maybe they just wanted to grab a snapshot of this file at a given
time).
* You could also want to link XCF files.
* You could also want to link remote files (especially in a controlled
network environment).
* Linked images are currently taken as a whole; we definitely want layer
support to handle multi-layer image formats (so that you could link
only a single layer, or a collection of layers; do we want to be able
to edit visibility of linked layers separately too? Would be neat). So
how would we handle automatic linking when opening a file? Maybe we
just reproduce the layer structure as link layers (one link layer
monitoring only one layer from the linked file)?
Anyway this is work-in-progress, UX-wise.
This commit changes the following:
- It's now possible to set whether to store an absolute or relative path
when editing link layer properties.
- New layer dialog doesn't propose an "Image link" fill type anymore.
Link layers won't be created this way (see in a future commit).
By default, we set them as relative paths. This seems like the more
practical and allows for relocatable folders when one work with project
folders containing all their assets.
We don't have yet a way to set this to being absolute path, but it will
come in a further commit.
These are layers who content depends on another source (right now only
an external image). This can be useful when for instance working at
several people on a single artwork, hence being able to load new
versions of an image without even touching anything in the XCF (for
instance, say you draw an animated character while someone else is
taking care of the background).
Similarly to what we do for text layers, once you start modifying the
contents, it turns into a "normal" layer. The link information is still
available though, so it is possible to revert to the monitoring state
with the menu item "Monitor Linked Image" which appear when a link layer
became a normal layer.
This is not finale as I'm still experimenting. In particular, I have not
implemented XCF saving/loading yet for this new layer type.
While there is a style "background color", the idea of a "widget
background color" is completely bogus, the widget background can be a
gradient or whatever.
- Get rid of "background" in GimpViewable's preview API, only leave the
"foreground color" there for things like brushes or fonts.
- In GimpViewRenderer, add the background types to be used to class and
instance, so each renderer type can choose what it needs.
- Render all previews to alpha surfaces, and do the background
for all renderers generically in gimp_view_renderer_real_draw(),
then render the preview surface on top of it.
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
Extensions is used both for file extensions and for
GIMP's planned Extension format. This patch adds translation
context so translators know which one we're referring to.
This commit adds support for activating user-defined keyboard shortcuts in the Welcome Dialog to:
- Create a new file
- Open a file
- Open one of the 10 most recent files
Closes#5856 - provide a way to export images without adding or
changing any metadata.
Handles issue #3490 together with !2367. The latter makes sure that
an image comment when present is favored over similar metadata tags.
This commit makes sure that when you disable the preference to
update metadata automatically, it does not synchronize the
image comment with similar metadata tags (possibly overwriting other
metadata), it does not update the modification date, and does not
add or update software and change history metadata.
This adds a metadata preference (enabled by default) that on export
determines whether we add and update some non essential metadata.
When this setting is disabled, we only touch the metadata that we
cannot avoid (e.g. updating size, presence of thumbnail, etc.).
It completely relies on GListModel and doesn't manage any list items
itself. The port should be pretty much feature-complete.
Add a ton of stuff to GimpRow in order to look and behave like a
GimpContainerTreeView row.
Add a playground switch to use the new widgets in all views that can
be switched between list and grid view (brushes, patterns etc.)
Please test!
From the horse's mouth:
"WARNING: appstream-glib is heavy maintenance mode, use appstream
instead"
Additionally, appstream-glib no longer conforms fully to the
appstream specification.
Some care is taken to taken to support both libappstream 1.0 as well
as libappstream 0.16.x to support stable distros.
The old API to select stuff and its signals was doing unexpected
stuff and was very confusing. Change things to be "normal":
The selection API is now set_selected() and get_selected(), with no
internal data exposed, and set_selected() emitting the expected
signal.
The signals are now "selection-changed" and "item-activated".
"selection-changed" is always emitted in response to changing the
selection, be it via the API, or by changes in the model (the internal
callbacks in from e.g. GimpContext or GimpImage simply call set_selected()
and don't do any unxpected magic).
Following Linux and Windows implementations, this commit add the
system color scheme detection on MacOS, enabling the "System Colors"
setting also on this OS.
Fetch date and time via GetDateFormatEx/GetTimeFormatEx to respect
the user's custom formats from Windows Region settings instead of
falling back to C locale defaults.
When the time or date format is changed from macOS system settings,
these changes do not affect the locale but the user preferences.
This commit ensures that the date and time are retrieved directly from
those settings, respecting the selected format.
...when setting animations for GtkStack.
Adds a check if gimp_widget_animation_enabled ()
is TRUE before setting an animation type in
gtk_stack_set_transition_type (). If it's FALSE,
then we turn off animations with
GTK_STACK_TRANSITION_TYPE_NONE.
This affects the Input Controller dialogue,
Preferences dialogue, and the Welcome
dialogue.
