narrowing the GDK include guard to #if defined(HAVE_GTK3), and
removing legacy HAVE_GTK2 / HAVE_GTK toolkit label branches from sysinfo_detect_toolkit(),
narrowing GDK display probing guard in sysinfo_detect_display_backend() to GTK3-only.
Updated Windows and macOS sysinfo backends to remove HAVE_GTK2 / HAVE_GTK fallback labels so sysinfo_detect_toolkit() now returns only "GTK3" (or NULL).
Updated API docs for sysinfo_backend_get_ui() to remove the outdated "GTK2 / X11" example so comments match runtime behavior.
Removed the deprecated Meson option option('gtk3', ... deprecated: true) from meson_options.txt, leaving gtk-frontend/text-frontend options intact.
Removed -Dgtk3=true from Debian’s Meson configure flags in debian/rules (override_dh_auto_configure).
Removed remaining active -Dgtk3=true packaging consumers in Flatpak config:
dropped it from config-opts
dropped -Dgtk3=true from cflags.
Removed -Dgtk3=true from Solus packaging Meson configure args.
Committed changes on the current branch (e018bfd) and created a PR record via the make_pr tool.
Removed the GTK2 fallback branch in src/fe-gtk/meson.build, so the GTK frontend now always resolves gtk_dep from dependency('gtk+-3.0', version: '>= 3.22') and always defines -DHAVE_GTK3.
Kept AppIndicator logic gated for non-Windows builds and intact in behavior (Ayatana first, then AppIndicator, with error on enabled if neither is found).
Simplified non-Windows GDK X11 probing to always use gdk-x11-3.0, consistent with GTK3-only frontend builds.
Updated src/fe-gtk/meson.build to always resolve gtk_dep from dependency('gtk+-3.0', version: '>= 3.22'), removed the GTK2 fallback branch and -DHAVE_GTK2, and kept AppIndicator detection guarded under host_machine.system() != 'windows' as requested. The GTK X11 helper dep is now unconditionally checked within that same non-Windows block (no gtk3 toggle).
Updated Meson summary output to explicitly report the GTK frontend as GTK+ 3.22+ when enabled, reinforcing that GTK2 builds are no longer expected.
Added a new Meson feature option appindicator (default auto) so this backend is explicitly controllable.
Updated GTK Meson logic to honor -Dappindicator=... and fail fast if enabled is requested but neither ayatana-appindicator3-0.1 nor appindicator3-0.1 is found (prevents silently shipping a build without AppIndicator tray support).
Updated AppImage CI configure flags to force -Dappindicator=enabled, which should prevent AppImage artifacts from lacking StatusNotifier/AppIndicator tray support in XFCE-like environments.
Switched the GTK frontend build logic to select GTK2/GTK3 dependencies and emit corresponding preprocessor defines.
Added GTK3 GtkGrid/alignment handling and GTK3 GtkBox replacements for the channel list controls while preserving GTK2 table behavior behind guards.
Switched the ban list layout to use GtkGrid under GTK3 with GTK2 table fallback for checkbox placement.
Updated main GTK UI layouts to use GTK3 GtkGrid/GtkBox and alignment/attachment logic (quit dialog, topic bar, search/entry, chanview placement, main window table) while keeping GTK2 behavior via HAVE_GTK3 guards.
Since hexchat already depends on GLib, it's better to use GProxyResolver
instead. This might use libproxy, or not, as appropriate.
P.S. This removes a memory safety issue because proxy_list is allocated
using malloc(), not g_malloc(), and therefore using g_strfreev() is
incorrect. The proper way to free the proxy list returned by libproxy
is to use px_proxy_factory_free_proxies() (but nobody does that because
it was added in libproxy 0.4.16, which is somewhat recent).
This is mostly useful to avoid a newer gettext dependency
for translating the appdata file but it is also just useless
data for some distros without any app store.
Closes#2219
This was accidentally left behind, expose it beind an option as
with the old build system but default to false now. Enough time
has passed and only distros that care about it can enable it.
Quick rundown of benefits:
- Much faster:
- Autotools (with autogen): 22 seconds
- Meson: 7 seconds
- Meson (with ccache): 2 seconds
- Simpler:
- ~1000 lines smaller
- Single simple language
- Potentially better Windows (Visual Studio) support
What is not done:
- Complete Windows support
- OSX support (easy)
Closes#2013Closes#1937Closes#1803
