When several drawables were selected, it was pasting at the top of the layer
stack. Instead, paste over the top selected layer ("top" visually in the Layers
dockable).
There was the question of: what should we do when pasting over a layer group.
Should we consistently paste the new layers above the group or inside the group?
After discussions with Aryeom, we decided to stay consistent and paste above, at
least for now.
This changes the default selection pasting behavior to be a new layer,
rather than a floating selection. It also removes the
"Paste as New Layer" submenu options as they are now redundant.
The histogram is still not multi-drawable aware. In the future, it would be nice
to add ability to generate histogram for all selected layers (merged and as
separate images) as well as the whole visible image, therefore 3 possible cases.
But for now, it's alright like this (no more, but no less feature than before)
and at least we got rid of the last usage of functions assuming single item
selection.
- Option dockable is named "Align and Distribute" rather than "Alignment".
First, because it's not just about alignment; also because this way, it looks
like other software, such as Inkscape; lastly because it's more consistent
with other tool options ("Move", "Rotate", etc.).
- Add a tooltip to the Anchor Point widget to explain what it's used for.
- Rewrite various align/distribute button tooltips to make clearer that we are
aligning anchor points with specific edges (or distributing these anchor
points).
- Rename the first section to simpler "Targets".
- Some more rewording of other texts.
It's clearly broken right now. I can see it might have been used even to
progressively shift aligned items, but this was not used anymore. As for being
used while distributing, it doesn't make any sense anymore with the new logic of
not moving the extreme (first/last in coordinates) items.
I can see how an additional concept of offset can be useful in some situations,
but for now, let's get rid of this. We'll see in the future if someone asks for
it and provides valid use cases to work from.
There was one case in Inkscape which we could not do: distributing objects
keeping even gaps between them. Until now, we could only distribute keeping even
distance between anchor points (top, left, bottom, right or center).
With these 2 additional distribute options, I believe that GIMP is able to do
all the Alignment and Distribution options available in Inkscape (not the
"Rearrange" or node features, neither the text align/distrib; I just mean the
common align/distribute on objects), and even a bit more thanks to the anchor
point system (e.g. in Inkscape, we can't left or right-align to a reference
object/image center, or we can't center to a reference left/right/bottom/top
border; but we can do it in GIMP).
The icons are hopefully temporary, until we can make better ones.
- Use g_malloc* functions instead of malloc, so we don't continue on
failed allocations unless we test for NULL.
- Make sure we don't iterate past the known number of control points (ncps).
- Safely allocate, initialize and free points. Since points seems to be
used uninitialized, we use g_malloc0 to set everything to 0.
After discussing with Aryeom, we decided that "Distribute" should work within
the current horizontal or vertical bounds, as this is how it is usually done in
other software (e.g. Inkscape). For instance, if there are 4 items, the first
and last (coordinate-wise) stay untouched, and only the 2 intermediate items get
distributed evenly.
Since the Reference is not relevant anymore for "Distribute", I undo part of my
previous commit, where I was organizing the reference setting into its own
section of the Alignment tool options. This setting is back as part of the
"Align" section.
- Adding a separate pivot widget to allow choosing which point of the items we
align or distribute. E.g. until now, we could only align the right side of
objects to the right side of the reference object, left to left and center to
center. Now these are independent. Therefore I can align the left side of
objects to the right border of a selection or a layer, and so on.
- Only keep 2 "distribute" buttons (for now). Most of the distribution actions
were basically broken or extremely hard to understand. Also they were
apparently mixing concepts of alignments with distributions. Now let's
basically only keep the bases: horizontal or vertical distributions.
Everything is still possible using a mix of alignment and distribution
buttons, and it's much clearer.
- Since the GimpAlignmentType was used nearly only there (except for some usage
like to store dock side or filter preview split direction, but these
GIMP_ARRANGE_* values were unused there), I removed the various enum values
which we don't use anymore.
- The Reference settings gets its own subsection in the Align tool options.
Until now, it looked like it only applied to alignment, whereas it applies to
distribution too.
Note: this is still work-in-progress, mostly some initial dev work to put some
algorithmic bases. We had some UI and specification discussions with Aryeom
already and some things might still change a lot.
There were various cases when the reference's on-canvas handles were not
redrawn, or drawn at all:
- When the reference is an image, we now draw them. It may seem redundant as
it's the image bounds, but it's still useful to see what are the reference
bounds in a glimpse. Moreover in "Show All" mode, it's even more useful.
- Start the tool, hence draw the reference handles, in oper_update() if not
started yet.
- When the "align-reference" property changes.
- When the display (active image) changes.
When the reference is a guide in particular, no distribution is possible (on one
dimension, the size is 0, on the other, it's infinite) and alignment is only
possible in one direction (depending on guide orientation).
I find these options always a bit unwise when people have no idea how to change
their mind. Therefore adding a tooltip with the information (though maybe we
should even do it even more clearly and adding that in checkbox text too?).
For this to happen, I've updated the main question to be "Keep the Embedded
Working Space?" instead of "Convert to * Working Space?". Basically now we put
emphasis on keeping the image's color profile as being the proposed action.
Therefore "Keep" is the default answer, on the right.
Yet "Convert" stays on the right too. There is no "Cancel" button anymore
because it is not a question we can really escape even though "Esc" still works,
and it still corresponds to "Keep", same as Enter now. The reason is that "Keep"
is actually the non-destructive option. So if someone really doesn't want to
answer and make an explicit choice, we do it for them with the only
non-destructive choice possible.
Also I'm changing "Convert" mnemonic to 'c'. I guess that earlier devs might
have used 'o' because it is the usual mnemonic for "OK", so it was right when
the question was "Convert?". But since now the question is the opposite, there
is no reason to make it look like "OK". Let's just use the first letter, which
is easier to guess (and not taken by any other button here).
I've been hesitating because I don't think "Convert" was the right default
anymore with our anyRGB move. Until now, it was kinda implying that sRGB (when
no preferred color profile was set) was kinda the recommended space. It's not.
If a file already has another space, it's probably much better to keep it.
First because "Convert" is often a destructive change (even more if the target
is sRGB), so for people who don't necessarily understand all the ins and outs,
we were kinda promoting a destructive default behavior.
On the other hand (and that's why I was hesitating):
* "Keep" is also what happens when we hit "Esc" so some might complain that
there is no easy "Convert" key anymore (there is alt-c, but it's for sure not
as easy as Esc or Enter). Basically it makes the "Convert" option always a
much more explicit choice (yet it is likely for the best for people who care
about their colors).
* There might have been many people who would just use the default (Convert
until now) without thinking too much of what was asked, and that was working
good because they would just publish on the web or similar basic usage. If
they continue just accepting with Enter without reading and understanding what
is asked, now they could publish images with a color profile (and we know it
doesn't always work perfectly on the web).
In other words, it might be the best default for professional usage now, yet
it requires to understand a bit what you are doing.
It's really a hard call!
Thanks to a report by Stefan Cornelius, we became aware that the flame
plug-in does no checking for correct input when loading a pre-saved
settings file.
I reworked the parser to read one or more values based on the type of
token, making sure we also don't read past the end of our token buffer.
All int values have a min and max value set. If any unexpected input is
encountered, we will give a warning.
The flame plug-in can read stored settings from a file. The expected
input is that a ; signifies the end of input.
However, with user input we cannot depend on this to be true, so we need
to make sure that we do not read past the end of our input buffer.
To do so, we add a length check.
We were using the plug-in name with underscores, which is incorrect.
Since nobody ever complained about this, this doesn't seem to be used
very often.
We will use the const that defines the plug-in name instead.
Daniel Novomeský