There were a lot of incertainty of what should happen when we copy layers being
descendant of each other (i.e. when you select a group layer and some of its
children), then when you paste such data. So we sat down with Aryeom and tried
to come up with some consistent behavior which is somewhat expectable, but also
which would allow the most use-case.
Otherwise it was making very weird result when pasting the data, duplicating
some layers and whatnot, which was obviously a buggy behavior and never the
expected result.
We decided that if you select one leaf item, then even if you also selected a
parent item, it would be as though the parent was not selected. This is very
often what you expect anyway when you select a whole bunch of layers and would
work well if, say, you shift-click over many layers in sub-groups. Then you
wouldn't have to manually ctrl-click to unselect every group.
Then what if you were instead expecting to copy many groups? Then you could
shift-click the group arrow, closing all same-level groups. Once they are all
closed, you can shift-click the groups to only select group layers, not their
contents.
This way, both use cases are still quite doable easily with this default choice.
- 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.
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).
We should not check if all items are locked, but if one item is locked. It is
enough to forbid the translation from happening.
Otherwise it is currently possible to bypass position lock by using keyboard
arrows for layers or channels.
Instead of using the layer borders, we use the bounding box for the contents.
This is similar to first run "Crop to Content" on every selected layer except
we don't actually need to crop. Therefore we can work on bigger layer than the
actual content while still arranging them based on content bounds.
So often the result of alignment/distribution feels wrong because it doesn't
correspond to the content we are seeing. With this option, we'll have the option
to choose the desired behavior.
The old interaction was quite horrible. I don't think I ever really got a good
use of it. It was so hard to understand what you were picking and so on.
Now that we can multi-select items, let's just use this as the base of what we
want to align or distribute. Clicking on canvas will now mostly be used to pick
an item as reference. From now on, only the reference object will get on-canvas
handle, making it very obvious how your alignment or distribution will work.
I leave only an alternative picking method (with Alt or Shift-Alt pick) to add
guides to objects to align or distributes, as these don't have a selection
dockable.
I'm also improving the selection of stacked layers by looping through them
(similar as the layer selection on canvas feature) so that we can select even
background layers which have a lot of layers showing above.
I am planning to improve this tool even further, but this is a first step to
make it actually usable within the new multi-item interaction logic.
This ports Massimo’s code to work in the latest version of GIMP.
It adds new outline-related properties to GimpText and GimpTextOptions.
These are controlled via the Text Tool Editor.
Cairo is currently used to draw the outline around the text.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
… new action_pixel_size of GimpMyBrushTool.
MyPaint brush tool clearly shows the limits of my trick to have some
enum actions work with absolute values whereas others work with
per-mille values between the property min and max.
Indeed firstly MyBrush's "radius" value is logarithmic and can be
negative. Since the enum trick relies on the fact that negative values
are the semantic enumerated constants, it's broken in such case. The
second issue is that while it was acceptable to use int size for most
paint tools (even though they were double), here radius only goes from
-2.0 to 6.0; so using int values only would leave us with jumping brush
sizes.
So now I create a proper double action which simply takes pixel size and
use this from the on-canvas brush size changing. No weird trick, no int
or sign limitations.
I also add a new optional action_pixel_size in GimpToolControl.
Note: I'm also updating a bit the logic for the MyPaint brush outline
function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit
through mypaint-brush.c code in libmypaint, I am not sure at all we need
to use the offset_by_random like this. And really this shown outline
seems more indicative than anything else when I see the actual size
printed by the various brushes. Finally here it was counter-productive
as I needed to get easily the logarithmic radius from the pointer
interaction on canvas.
Note that the other paint tool which is not as common as others is the
MyPaint brush tool. At first I thought the circle outline didn't work.
It does actually work, but the radius concept is simply very weird in
this tool so we have to move a lot. To be investigated.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Similar to the previous commit, use the new
gimp_tools_show_tool_options() before blinking various tool options
widgets since these are good hints for wrongly set options and it's nice
to be able to point at these.
Create a new utils function gimp_tools_show_tool_options() because
showing the tool options is likely a common action. And use this when we
want to blink the selection mode box, for this particular case.
Note that I could not reproduce the CRITICAL here (i.e. even if the
dockable was not showing, it seems the widget did already exist anyway).
Anyway it's a nice idea to raise the tool options as the goal is to
explicitly show how to fix the issue here. And it should fix the bug for
people encountering it.
So it turns out that the "notify::src-drawables" property signal in
particular can happen during gimp_paint_tool_paint_interpolate() called
from gimp_paint_tool_paint_thread(). Though the function
gimp_clone_options_gui_update_src_label() was run in the main thread in
simple cases, being called this way through a paint thread happens when
very quickly changing the source while painting, which is what Aryeom
does (when I see her using the clone tool, she would sometimes change
the source very quickly several times in barely a few seconds).
Yet GTK and GDK calls must not happen in non-main threads. It used to be
acceptable when protected with gdk_threads_enter|leave() calls but doing
this is deprecated. The now sanctioned method is to call the GTK code in
an idle function since these are guaranteed to run in the main thread.
This was most likely explaining why crashes could quite randomly happen,
though I'm not sure why I never had those (even though I could reproduce
the GTK calls happening in non-main threads, but without crashing GIMP)
and why Aryeom gets these much more often suddenly. Maybe some recent
dependency change which would trigger these more easily or other
context-dependant changes (as most non thread-safe code, bugs and crash
often happen in race conditions, so are harder to reproduce reliably)?
We take a step back from the original MR which was proposing the "single
dot" cursor as a new "Pointer mode" option. I was really unsure this was
the best solution, especially reading again the whole original report.
It means that now nearly all of the original patch has been rewritten
another way, but let's leave the contributor commit as a start point to
get to where we are, and as acknowledgement of the contribution.
The reporter was annoyed by the crosshair when none were requested and
probably mostly for painting tools only (at least examples were about
brush or pencil, etc.) while showing outline. It looks to me like the
real issue was maybe when we were showing the big crosshair when using
the 4-arc fallback outline, for instance when using a dynamics changing
size. If so, this main issue is already fixed by my commit 64dc26064b.
No need of a new option for this, especially if the option can be as
confusing as a barely visible dot-cursor (I can already imagine the bug
reports of people tweaking random preferences and unhappy because the
pointer became invisible, while they don't know how they did it).
Instead I would say that when people specifically uncheck both "Show
brush outline" and "Show pointer" options, showing a huge crosshair
feels quite counter-productive. This is where I think that our small
unobtrusive cursor (probably a better name than "Single dot" by the way,
as it's not a single dot anymore) might be of use, the ultimate case
when someone really want a cursor as inconspicuous as possible, while
still having a visible feedback of the pointer position (even with
display-tablets, parallax issues make such a visual feedback important
to target where one paints).
So let's try this first and see how it goes.
If someone explicitly asked not to get a pointer, yet to have the
outline, we should not force a crosshair on them while the fallback
outline is a perfectly visible mark (4 arcs around the pointer's
position, well delimiting the brush size).
It's still the same visually but it will be useful for 2 reasons: first,
it makes nicer code to show/hide only this one box instead of 3 frames;
second it will be used for the release note demo feature so that we can
blink the full line art settings box.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
… a given order, not at the same time.
This will be used for the release item notifications to show people
where new or changed features are, but in an ordered blink scenario. For
instance: select a tool first, then blink some tool icon, open the tool
options and finally blink the specific new/changed option. I am hoping
it would help awareness of changes (just words on a web news may make
some features a bit foreign when not used to look in details in advanced
options).
It should help with scrolling the dockable to make the widget visible,
as I don't see a generic and simple scrolling API for GTK scrollable
containers.
In my own testing, it did work if the dockable was already opened. But
if it was just created by the blink API, then giving focus immediately
doesn't properly scroll. I am not really going to investigate now, but
this should be fixed eventually.
This function will help us raise attention to various widgets in
dockables by blinking them similarly to how we blink locks or visibility
icons.
I associate this with the fact that property widgets identifier will be
the property name, so we get identifiers for free when creating widgets
through the propwidgets API.
… on the line art source.
Also now the default tooltip itself will be more appropriate rather than
reusing the "fill-transparent" property blurb (maybe I should have made
this its own property in fact).
This is the same thing as setting the max gap length to 0, except that
it would mean constantly having to play with the gap length and possibly
losing settings you carefully tweaked. Instead with this additional
settings, we hide the gap length settings when automatic closure is
disabled.
Also it makes kind of a nice parallel with the "Manual closure" settings
which can also be enabled/disabled similarly.
Since we can't select a source, the source tools would fail stroking
with an error. It was usable when stroking a path or selection as we
can have the source tool started while running these. Since only one
tool can be started at once, this is not possible when running bucket
fill tool (it would require some logics change on tools).
This change has 2 parts: add an "insensitive" column to
GimpContainerComboBox (allowing to mark some cells as insensitive), then
use this new attribute in the GimpBucketFillOptions to show all source
tools as insensitive.
Alx Sa