Bad usage of `find`. I didn't pay attention that I removed icons from
the Legacy icon theme which is frozen. Obviously the previous commit was
only expecting to touch Color and Symbolic icon themes.
- Remove some forgotten lines related to 24x24 vector icons which were
removed a few days ago already.
- Don't install the 64x64 icons anymore as PNG when in the vector icon
case. Not sure why we ever did this, but it doesn't look useful.
- This should also fix the CI which was not looking for the tool
gtk-encode-symbolic-svg in vector icon install.
Some points to note:
- gimp-web and gimp-toilet-paper had some usage elsewhere so I also left
them in 2 of the more generic size files.
- I remove gimp-floppy altogether as it's used nowhere in any of our
code or data files.
There are some clear and obvious groups in the icons. For instance, the
Preferences icons are one of them. Looking up the code, we only use them
in 16px (in Preferences side menu) and 48px (in Preferences page
headers). Until now, we were storing in other unrelated size (22px) and
also the lists per-sizes were not consistent. Some icons were missing
here, other there.
With this new organization, the Preferences icons are listed in a single
file, ensuring usage and contents consistency. Also it allows to install
them only for the needed sizes (note that it is possible that they might
be needed in different size, for instance with custom themes; but we
can't just randomly distribute icons in all sizes; or to be more
accurate, this is exactly why we encourage rather the SVG/scalable
icons, so if some people explicitly go for raster icons, they also get
the drawbacks which come with).
Last note: it may be possible that some icons end up in different
"semantic" icon group. This is not a problem with this new organization
as my scripts handle duplicates gracefully.
Build-time tool, which basically just rasterize SVG images (it doesn't
do anything special like gtk-encode-symbolic-svg which creates special
PNG for GTK to recolor them).
It looks like I had this prepared since 2018 according to file header,
but I just never finished doing it! :P
Basically now PNG icons of the Color icon themes do not need anymore to
be committed in the repository. They will be generated from the SVG
icons.
Also adding a missing icon from the 16px list (the Playground icon for
Preferences dialog was needed in 16x16 as well, yet missing).
It may actually be meaningful to have redundant vector icons at specific
size, for instance when you want sligthly different designs (e.g. more
details at bigger size). But here looking at our 24x24 vector icons, it
doesn't look like it at all. It's mostly the exact same icons,
duplicated (with some forgotten).
Makes no sense here. So let's simply install the scalable/ icons for all
size, and that's it.
Since this is probably much less tested than the default vector icon
case, any bug there might go unseen for some time. So let's add a new
pipeline to check this. I make so this pipeline is not actually run on
every commit (i.e. manually only), then I'll just add a scheduled
pipeline to check the non-vector icon case at regular intervals.
This pipeline also test the icon-list.mk files are not outdated.
Just so that someone who happens to look in there is not tempted to
modify these files directly and get some instructions.
The comment is inspired from other similarly generated Makefile.am (i.e.
in plug-ins/commons/).
The lists are still exactly the same (except for one icon file whose
name the script fixed, which proves its usage/need even starting this
initial commit).
Now we also get more consistent tabbing than the manual one. Only
missing thing is that it was nice to separate some icons by categories
for easy reading. Maybe later.
… listing.
This way, both the Color and Symbolic icon themes, both on meson and
autotools build systems all share the exact same list of icons.
I think there are still improvements to be done on what we list and
chosen sizes and icon categories. But this step is about just getting on
the same state as we currently are, simply with shared listings. Once we
are there, we can go forward.
I realize that this module is available since meson 0.53.0 though our
current requirement is meson 0.50.0.
Note sure why meson was not popping any warning (normally it does when
we use a feature younger than the minimum requirement; but maybe this
doesn't work for modules).
Anyway this does the same thing without the 'fs' module, and maybe even
better (we know which icons should be converted or used from source, no
need to add any test logics here).
Now we get back (slowly) to something a bit saner, with a common list
shared on both icon themes. This way, we make sure we won't miss any
icon when we will add/remove/change any icon.
This is only for the meson build right now, but next step is to use the
same list in the autotools build as well. This will get maximum
consistency across build systems.
The whole logics of creating specially prepared PNG images for vector
icons (with gtk-encode-symbolic-svg) was absent. This option was
basically completely broken, yet we now know that we need the ability to
install PNG alternatives for the icons (see #6821).
This is a continuation of previous commit which is straightening a bit
our whole icon theme builds. Note though that more needs to be done
because I definitely still see room for more mess and far too much
duplication.
Some icons were missing on one side or another side, though mostly on
the meson build. Also the option -Dvec-icons=false was basically
completely broken and clearly untested, most likely ever since the
original meson build contribution.
This commit doesn't even completely fix the non-vector icon rule,
because even the file names are wrong, and the bitmap icons are not even
constructed from their vector counterpart! I am going to fix this in the
next commit.
Currently it's a mandatory option (and it has been the case for years,
ever since commit 43e218859b) so let's update the info.
Note that there are still discussions going on about this dependency and
it being hard or impossible to build on many platforms (which are stuck
on old C version, before the move to Rust). See #6821.
We'll see how it goes.
This includes:
- "copy-icon" set
- Permission and cleanup rules updated
- Exiv2 bumped to 0.27.5
- Adding an x-checker-data for OpenEXR
- Poppler bumped to 22.01.00
- OpenBlas bumped to 0.3.19
- graphviz bumped to 2.50.0
We should really get back to a single shared list as we have in
gimp-2-10.
Also just keeping the "no SVG icons" option feels wrong to me, yet it
turns out librsvg is quite a problem because of Rust, so recent versions
are just not available on many platforms (see #6821). This is what
blocked me so far to remove this whole listing of PNG variants for our
vector icon themes. Otherwise they would be gone by now.
I really wonder as well about all these size categories. Not that they
are not needed when in PNG format, but because it feels like nobody has
really taken the time to list which icons are needed in which size for
years. We really need to do some cleaning in this area.
This moves to standard fullscreen behavior for Gimp.
Added benefit is that it no longer requires gdkquartz-cocoa-access.h
which the Gtk team wish to stop supporting https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4303.
Bug 756178 also no longer manifests, cdc7542d46
so it is now safe to do.
Finally, removes dependency on objective c in the app/display directory.
Since I removed some files and forgot to change these rules. Though I
actually wonder if this still makes sense to distribute all these files
within the tarball anymore. It made sense in the way software was
distributed 20 years ago, but nowadays people who want to develop would
clone the git repo not get a tarball. We'll see.
This change makes sure that plugins can load when gimp is built with
meson. This is because .typelibs and .gir files do not have full library
paths when build using meson (this is different from autotools).
Add some more text and links to existing documents.
I also remove 3 files which are now either outdated or whose contents is
also written (with more or less similar text) in other more up-to-date
files.
Add more links to other files after I reviewed they were still relevant.
The `gitlab-milestones.txt` in particular had to be updated because the
contents was outdated (though we still need to manage milestones, simply
now we are a bit more fine-grained).
Loosely based on the old structure.xml, except it was widely outdated.
So I removed or updated what was obsolete and added missing folders.
Obviously getting rid of the old `structure.xml` (now we have easier doc
generation through Gitlab).
Finally, I fix the table of contents and replaced the title with some
metadata-style stuff which Gitlab docs suggest (otherwise the document
title ends up in the table of contents, which is a bit silly).
Sometimes we want to make quick tests on old versions of GIMP.
Rebuilding from source is definitely still an option, yet with flatpak,
we have many past builds available easily to us (at time of writing: 19
stable builds, 12 dev point-release builds and at least 3 nightlies —
though I seem to have issues with signatures on gnome-nightly right now,
so maybe there are more!).
There are some command lines needed to check the build history, then to
install a specific build, which I explained in developer docs (see
devel-docs/debugging-tips.txt, section "Testing older GIMP versions").
Yet it's clearly cumbersome and slow so I wrote this script today to
automatize the process a bit.
Running simply this command will list all available releases on the
Flathub repository (adding --beta or --nightly will list the development
releases and nightly builds instead):
$ tools/flatpak-releases
The listing will contain a topic describing the build as well as the
date, all this prefixed by a number. For instance, this is an excerpt of
the output for the dev releases:
$ tools/flatpak-releases --beta
0: Update dependencies (127a0fa7) [2022-01-13 16:59:43 +0000]
1: Issue #106: File->Create->From Screenshot not working. (9c831b14) [2021-12-14 21:46:52 +0000]
2: Release GIMP 2.99.8. (908bf5b0) [2021-10-20 20:29:00 +0000]
3: Release GIMP 2.99.6. (e04355dd) [2021-04-26 14:08:32 +0000]
…
The last build updates dependencies, the previous one fixes some
specific issue and the 2 previous ones are point releases.
Now say I needed to test/compare some behavior with how it was in 2.99.6
(e.g. to verify a regression), I would then run:
$ tools/flatpak-releases --beta -3
This would install this specific dev build number 3. In just 2
easy-to-remember commands and a few seconds, we can therefore list and
install specific Flatpak builds.
