Removed an unnecessary explanatory comment above the unconditional early return in log_handler(), leaving only the active behavior.
Removed an unneeded section marker comment before fe_idle() to keep surrounding code cleaner.
Changed the flow to prefer xdg-open first (with sanitized env) and only then fall back to gtk_show_uri, instead of trying GTK first under a potentially broken runtime environment.
Added explicit final warning when both mechanisms fail, and ensured temporary allocations (including xdg_open_path) are released cleanly.
Kept the existing behavior of trying gtk_show_uri first and only using xdg-open as fallback; this change only hardens the fallback path and preserves existing flow/logging.
Added an xdg-open fallback path when gtk_show_uri fails, which improves behavior in AppImage/sandbox-like environments where GTK/GIO handler resolution can fail.
Added warning logs for both the primary gtk_show_uri failure and fallback failure to make future debugging much easier.
Simplified the Windows theme block in fe-gtk.c from a GTK3-conditional compile guard to a direct Windows guard (#ifdef G_OS_WIN32), matching the GTK3-only codebase direction.
Simplified native file chooser guards in gtkutil.c from WIN32 && HAVE_GTK3 to #ifdef WIN32, removing remaining GTK3 compatibility-condition clutter in that file.
Removed GTK2 compatibility shims from headers (fe-gtk.h, gtkutil.h), leaving direct GTK3-facing declarations/includes only (and platform-specific guards unrelated to GTK2 kept as-is).
Cleaned GTK2-specific comments/wording now that behavior is GTK3-native (menu accelerator note and emoji/userlist comment blocks).
ZOITECHAT_ICON_PATH (user override env var),
current working directory + share/icons,
argv[0] directory + share/icons.
Valid directories are appended to GTK’s icon search path.
Added diagnostic logging so startup clearly reports either the selected icon path source/path or that none of the expected locations were usable, to speed up Windows missing-icon triage.
Reused/stored the computed argv[0] directory in fe_args (via win32_argv0_dir) so it can be used both for chdir and for icon fallback resolution.
I also fixed Windows packaging to include what the SVG path needs at runtime: librsvg DLLs, gdk-pixbuf loader modules, and loaders.cache in the release bundle.
Removed Adwaita icon bundle copy rules from the Windows packaging project (copy.vcxproj), so share/icons/Adwaita is no longer pulled into Windows build artifacts.
Removed Adwaita icon inclusion from the Windows installer manifest (zoitechat.iss.tt), so installer builds no longer ship Adwaita icon files.
Added a Win32 icon-theme setup helper that appends bundled share/icons to GtkIconTheme search paths and forces Adwaita when available, so the emoji chooser’s category/menu symbolic icons resolve instead of showing placeholder squares.
Invoked the new Win32 icon-theme configuration immediately after gtk_init() so it applies before UI usage, including the emoji chooser popover created from entries.
sets gtk-application-prefer-dark-theme when that GtkSettings property exists, and
applies an app-level GtkCssProvider with dark/light fallback classes (zoitechat-dark / zoitechat-light) to keep non-chat widgets aligned with mode changes.
Updated the shared theme apply path so fe_apply_theme_for_mode() still applies the palette layer (palette_apply_dark_mode) and now also applies the Windows GTK layer, ensuring auto/manual modes flow through one path.
Extended toplevel theme application to add/remove the new dark/light CSS classes on Windows GTK3 windows, while preserving native titlebar dark-mode handling.
Made AUTO mode resolve from the cached auto_dark_mode_enabled state, and initialized that state in fe_init() before the first fe_apply_theme_for_mode() call so initial and subsequent behavior are consistent.
Added a unified theme application pipeline via fe_apply_theme_for_mode() and fe_apply_theme_to_toplevel(), and routed auto-mode refresh logic through it so palette + GTK input styling are applied consistently from one place.
Switched startup and settings-apply flows to use the unified theming function, replacing direct palette-only calls so system-mode detection → theme apply is consistent across initialization and preferences changes.
Applied native titlebar updates when top-level windows are shown and during setup reapply across open sessions, and wired Windows builds to link dwmapi in both Meson and MSVC project files.
Updated the GTK3 input CSS generation to include base/foreground colors, caret color, and the Adwaita/Yaru background-image override while applying the provider to the screen.
Updated setup color selection and styling to use RGBA-aware GTK3 overrides/CSS while preserving GTK2 behavior in guarded paths.
Switched tree view color models/renderers and other palette consumers (user list, notify, DCC, menus, spell entry, input style) to RGBA-aware types/properties with shared RGB16 conversion usage.
- Updated palette handling to respect the effective dark mode (including auto) when saving colors, applying themes, and refreshing user list styling.
- Added auto dark-mode tracking that listens to system theme changes and reapplies palette/styles live when Auto is selected, so updates happen without restart (including channel list styling updates via setup_apply_real).
- Synced the stored auto dark-mode state when preferences are applied, keeping Auto mode consistent after manual changes.
- Exposed a helper for keeping the Auto state synchronized from the GTK layer to preferences handling.
- Replaced the dark mode checkbox with an Auto/Dark/Light color mode selector and ensured palette edits use the resolved mode.
- Applied the resolved color mode consistently across palette saving and GTK styling in the user list and channel tree/theme application paths.
- Updated the xtext renderer to accept Cairo background surfaces and dropped the GtkStyle attach during realize to keep rendering Cairo/Pango-focused.
- Switched background surface ownership and cleanup to use cairo_surface_t across the shared state and settings update path.
This solves the issue where the parent dialog is closed and then
the child dialog is used.
This is however only a partial fix:
- Many other dialogs throughout the codebase do not currently have
parent windows and need to be refactored.
- Not all window managers respect modal so users can still trigger
bugs. We can be more defensive against this but it requires more
refactoring.
Closes#2686
- Combine the three properties into a single one
- Finally fully fix the handling with plugins handling events
TODO: Look into lastact handling of these, seems wrong
Part 2 of 03767ee0f9
So how the colors work should be pretty straight forward:
- A message comes in and is handled, this sets the state flags:
nick_said, msg_said, new_data. These map to tab colors.
- This state is reset under one of these conditions:
- It is commited to the UI when actually printed on unfocused tab
- Event is interupted by a plugin hook
- The tab focus is changed
It just duplicates functionality and this fixes:
- alert_taskbar chanopt not being respected
- tab color being incorrect when highlight print events are eaten
This splits notifications up into multiple backends
currently only libnotify on unix and win8 toasts.
The win8 backend was originally written by @leeter
though heavily modified.
