Alx confirms that "Drop shadows, Inner Shadows, and Outer Glow are all
layer styles in Photoshop", which I wasn't certain about (this software
has different concepts for what is basically just effects). So let's
combine in a single item.
It's mostly copy-pasting of dev versions' metadata, with reordering per
category.
I didn't copy features which were backported in the 3.0 series since, or
still in playground, some of the less visible features, what looks a bit
more like fixes than features, regrouped some points when relevant, etc.
This is based off ongoing Teams/GIMP/CoreTeam/Discussions#9 discussion
and is meant to take care of worries which were raised in since-reverted
commit c4b4f343d4.
Basically GIMP is not a "toy software" indeed, made to just do quick
one-click edits, such as a quick crop-rotation, or apply common filters
with no options, by finger-swiping, for your social network account. It
is not to say that you cannot do all of this, but this is still part of
a much bigger feature-set, with a lot of advanced options to customize
renders, in a software made for high-end image editing and creation. The
target therefore includes graphics professionals (such as ourselves!),
but not only, which is why the reverted commit was not fine. It can be
amateurs doing high quality work too, and we don't want these creators
and usage to be left out.
The Core Team discussion is about our updated Project Vision. This is an
ongoing discussion which may span for a few more months, possibly until
the next physical meeting of contributors. So far, our Vision is
summarized as one sentence:
> GIMP is Community-driven Free Software for high-end image creation and manipulation.
This sums up several of the main aspects of GIMP: its community and how
it's being created by it, the fact it is Free Software, the fact it
targets high-end creation/manipulation, and the generic aspect of the
type of graphics works (creation or manipulation), because it is not
just about photo retouching.
This commit therefore reuses the current wording in the initial
paragraph of our metadata description. I move one example of such type
of graphics work in the second paragraph and remove the "simple" word,
as it may imply again "toy" and ourselves, as well as many other digital
painters across the world, have proved long ago that this program is not
just to do "simple painting".
This is an update before the RC release (where we will start freezing
strings). Of course, we may update further the text later (when we'll
start working on 3.4 probably), if the Project Vision further evolves.
This URLs are useful when users want to see more information about
release notes. They are visible on software stores like GNOME Software
and software websites like Flathub.
This reverts commit c4b4f343d4.
Though I did obviously say such things, I think we must think more
thoroughly on how we want to word it, since it is the entry point to our
software. So it's pretty important.
Also using the word "professional" in particular is problematic as we
seem to exclude various amateurs (in the laudative sense of the term) of
high skills. Wording such as "advanced", "expert" or "high end" may be
more appropriate.
Anyway reverting until we make a team decision for better wording.
I realized that without a listing of changes, the "Release Notes" tab is
missing from the Welcome dialog. I can change this in the code, but
having just a single small sentence filling a big tab is not really nice
either. So instead, let's add some more details even if these are not as
major changes as on a minor point release.
After all, these are still nice changes anyway.
Several of these even take good advantage of the demo feature in our
AppStream parsing.
We are very likely releasing on Monday 4, and not even now but after a
good night. The whole Gitlab infrastructure is clearly half-borked right
now, we are constantly waiting for runners, sometimes we get random
error 500 when loading Gitlab pages, sometimes some stuff get stuck on
display and we need to refresh.
Not only this, but the Flathub infra is also broken (I believe it's also
hosted by GNOME?) and all our builds are either failing or sometimes
going further then failing at "Committing builds" or other steps,
usually with some HTTP error.
It's not the wisest idea to make a RC1 release in such condition.
