GitLab

It is super ugly but looks like it does not work for forks made before the CI was set up.

I am using Nix for CI rather than the usual Fedora or Ubuntu,
since that is what I am most familiar with, and it also allows
to reproduce the same environment locally as on CI.

Nix [1] is purely functional package manager allowing to easily
install dependencies in a reproducible manner.
A developer can run `nix-shell` in the project directory
and they will be dropped into a shell with all the necessary
build dependencies.

The dependencies are pinned so that same version can be
used on CI and developers’ machines.
One can run `nix-shell --run 'niv update'` to update to latest version.

[1]: https://nixos.org/

Stephan Vedder authored Mar 31, 2022 and Jan Tojnar committed Apr 01, 2022

This will remove the need for the rename in flatpak manifest.

Fixes: #98

If Python is not present (e.g. when building in a sandbox),
Meson will fail in the middle of a build:

    /usr/bin/env: ‘python3’: No such file or directory

Let’s check for `python3` using `find_program` so that
the issue can be detected in the configure step.

It would be even nicer to get rid of the Python script
in favour of using Meson’s filesystem module to read
the supported-mime-types file in Meson itself but
the `fs.read` function will currently trigger full
Meson re-configuration when a change in the file is detected,
instead of just invalidation of the affected targets
like `configure_file` does.

Maximiliano authored Jul 23, 2021 and Jan Tojnar committed Mar 31, 2022

Also pushes nightly builds to the gnome-nightly repo.

Maximiliano authored Jul 23, 2021 and Jan Tojnar committed Mar 31, 2022

This is a continuation of
!4 (diffs), it
is based on the manifest used at flathub, but updated to build on the
master runtime.

The goal is  https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak.

Most of signal do not return any value. I verified using the following semantic patch that there are no signals that return a value in File Roller, and very little in GLib and GTK: https://gitlab.gnome.org/jtojnar/glib-refactoring/-/blob/5d70945511ce1f924f2f3eae59cb382bf39caeb7/patches/find-non-void-signals.cocci

Then I ran this semantic patch to set return values of all handlers to void:
https://gitlab.gnome.org/jtojnar/glib-refactoring/-/blob/a17a83dccb841108a760c7b4a7e26b34cb3231b4/patches/voidize-signal-handlers.cocci

Finally, I checked with Tartan that this transformation did not cause any new errors.

It is required for Tartan to properly analyze our types.

Otherwise it will try to install it to system-wide location
when just trying to install into a development prefix.

See https://www.bassi.io/articles/2018/03/15/pkg-config-and-paths/

The callback function type signature should match what the signal produces.

The official gtk_builder_new_from_resource is identical except
that it fails loudly. Given that resources are baked into the app,
not being able to load ui file should be a hard error anyway.

Transformed using the following semantic patch:
https://gitlab.gnome.org/jtojnar/glib-refactoring/-/blob/5d70945511ce1f924f2f3eae59cb382bf39caeb7/patches/file-roller/replaced-custom-gtk_builder_from_resource-wannabe.cocci

This is a best practice and also requirement for porting to GTK 4:
https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-blocking-dialog-functions

file_selector_response_cb is a response callback so it should not return value.

It is a macro so G_OBJECT cast is pointless. Or rather harmful since
it will prevent Tartan from properly checking the handler type:

    Could not find GObject subclass for expression when connecting
    to signal ‘…’. To improve static analysis, add a typecast
    to the GObject parameter of g_signal_connect_data()
    to the specific class defining the signal.

The casts were stripped using https://gitlab.gnome.org/jtojnar/glib-refactoring
and then I manually added more specific casts based on instructions from Tartan.

This is a best practice and also requirement for porting to GTK 4:
https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-blocking-dialog-functions

Also removed the return values of the signal handlers since GtkDialog::response
is supposed to return NULL. The return values were introduced in the following
commit but it probably was just a mistake:
04cf8259

gdk_cursor_new_for_display has been removed in GTK 4:
https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-cursor-api-changes

The constants are removed in GTK 4:
https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-gtkstylecontext-api-changes

GtkAccelGroup will be removed in GTK 4:
https://docs.gtk.org/gtk4/migrating-3to4.html#use-the-new-apis-for-keyboard-shortcuts

It might be nice to switch to GtkShortcutController when porting to GTK 4.
But until then we are stuck with gtk_application_set_accels_for_action,
which works in both GTK 3 & 4.

GtkMenu will not be present in GTK 4:
https://docs.gtk.org/gtk4/migrating-3to4.html#gtkmenu-gtkmenubar-and-gtkmenuitem-are-gone

We have long required greater versions of GTK so this code will never be used.

At least those discovered when built with
`-DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED`
and run with `G_ENABLE_DIAGNOSTIC=1`.

There should be no need to have the list_store updated.