deepend/zoitechat
1
0
Fork 0
mirror of https://github.com/ZoiteChat/zoitechat.git synced 2026-03-10 07:50:19 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
757892819990ca62087b7c1fad9af797b3a9b9a0
zoitechat/data/zoitechat.gresource.xml

139 lines
11 KiB
XML
Raw Normal View History

Reorganize files and migrate images to gresource
2013-09-27 21:56:13 -04:00
<?xml version="1.0" encoding="UTF-8"?>
<gresources>
<gresource prefix="/icons">
new name after fork
2026-01-05 23:12:38 -07:00
<file alias="zoitechat.png" preprocess="to-pixdata">icons/zoitechat.png</file>
Don't combine compression with pixdata option for icon resources This made minimal difference and is not recommended by upstream. It also is affected by a regression in the latest gdk-pixbuf release. https://bugzilla.gnome.org/show_bug.cgi?id=776105
2016-12-17 19:55:06 -05:00
<file alias="book.png" preprocess="to-pixdata">icons/book.png</file>
Reorganize files and migrate images to gresource
2013-09-27 21:56:13 -04:00
Don't combine compression with pixdata option for icon resources This made minimal difference and is not recommended by upstream. It also is affected by a regression in the latest gdk-pixbuf release. https://bugzilla.gnome.org/show_bug.cgi?id=776105
2016-12-17 19:55:06 -05:00
<file alias="ulist_voice.png" preprocess="to-pixdata">icons/ulist_voice.png</file>
<file alias="ulist_halfop.png" preprocess="to-pixdata">icons/ulist_halfop.png</file>
<file alias="ulist_op.png" preprocess="to-pixdata">icons/ulist_op.png</file>
<file alias="ulist_owner.png" preprocess="to-pixdata">icons/ulist_owner.png</file>
<file alias="ulist_founder.png" preprocess="to-pixdata">icons/ulist_founder.png</file>
<file alias="ulist_netop.png" preprocess="to-pixdata">icons/ulist_netop.png</file>
Reorganize files and migrate images to gresource
2013-09-27 21:56:13 -04:00
new name after fork
2026-01-05 23:12:38 -07:00
<file alias="tray_normal.png" preprocess="to-pixdata">icons/zoitechat.png</file>
Don't combine compression with pixdata option for icon resources This made minimal difference and is not recommended by upstream. It also is affected by a regression in the latest gdk-pixbuf release. https://bugzilla.gnome.org/show_bug.cgi?id=776105
2016-12-17 19:55:06 -05:00
<file alias="tray_fileoffer.png" preprocess="to-pixdata">icons/tray_fileoffer.png</file>
<file alias="tray_highlight.png" preprocess="to-pixdata">icons/tray_highlight.png</file>
<file alias="tray_message.png" preprocess="to-pixdata">icons/tray_message.png</file>
Reorganize files and migrate images to gresource
2013-09-27 21:56:13 -04:00
Disable compression on tree_channel.png This causes some artifacts in the icon, none of the others seem to have the problem
2014-03-13 12:00:25 -04:00
<file alias="tree_channel.png" preprocess="to-pixdata">icons/tree_channel.png</file>
Don't combine compression with pixdata option for icon resources This made minimal difference and is not recommended by upstream. It also is affected by a regression in the latest gdk-pixbuf release. https://bugzilla.gnome.org/show_bug.cgi?id=776105
2016-12-17 19:55:06 -05:00
<file alias="tree_dialog.png" preprocess="to-pixdata">icons/tree_dialog.png</file>
<file alias="tree_server.png" preprocess="to-pixdata">icons/tree_server.png</file>
<file alias="tree_util.png" preprocess="to-pixdata">icons/tree_util.png</file>
updated, fixed or replaced menu icons.
2026-02-17 20:05:13 -07:00
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/new.png" preprocess="to-pixdata">icons/menu/light/new.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/new.svg">icons/menu/light/new.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/network-list.png" preprocess="to-pixdata">icons/menu/light/network-list.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/network-list.svg">icons/menu/light/network-list.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/load-plugin.png" preprocess="to-pixdata">icons/menu/light/load-plugin.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/load-plugin.svg">icons/menu/light/load-plugin.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/detach.png" preprocess="to-pixdata">icons/menu/light/detach.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/detach.svg">icons/menu/light/detach.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/close.png" preprocess="to-pixdata">icons/menu/light/close.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/close.svg">icons/menu/light/close.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/quit.png" preprocess="to-pixdata">icons/menu/light/quit.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/quit.svg">icons/menu/light/quit.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/disconnect.png" preprocess="to-pixdata">icons/menu/light/disconnect.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/disconnect.svg">icons/menu/light/disconnect.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/connect.png" preprocess="to-pixdata">icons/menu/light/connect.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/connect.svg">icons/menu/light/connect.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/join.png" preprocess="to-pixdata">icons/menu/light/join.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/join.svg">icons/menu/light/join.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/chanlist.png" preprocess="to-pixdata">icons/menu/light/chanlist.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/chanlist.svg">icons/menu/light/chanlist.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/preferences.png" preprocess="to-pixdata">icons/menu/light/preferences.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/preferences.svg">icons/menu/light/preferences.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/clear.png" preprocess="to-pixdata">icons/menu/light/clear.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/clear.svg">icons/menu/light/clear.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/copy.png" preprocess="to-pixdata">icons/menu/light/copy.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/copy.svg">icons/menu/light/copy.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/delete.png" preprocess="to-pixdata">icons/menu/light/delete.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/delete.svg">icons/menu/light/delete.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/add.png" preprocess="to-pixdata">icons/menu/light/add.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/add.svg">icons/menu/light/add.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/remove.png" preprocess="to-pixdata">icons/menu/light/remove.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/remove.svg">icons/menu/light/remove.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/spell-check.png" preprocess="to-pixdata">icons/menu/light/spell-check.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/spell-check.svg">icons/menu/light/spell-check.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/save.png" preprocess="to-pixdata">icons/menu/light/save.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/save.svg">icons/menu/light/save.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/save-as.png" preprocess="to-pixdata">icons/menu/light/save-as.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/save-as.svg">icons/menu/light/save-as.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/refresh.png" preprocess="to-pixdata">icons/menu/light/refresh.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/refresh.svg">icons/menu/light/refresh.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/search.png" preprocess="to-pixdata">icons/menu/light/search.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/search.svg">icons/menu/light/search.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/find.png" preprocess="to-pixdata">icons/menu/light/find.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/find.svg">icons/menu/light/find.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/previous.png" preprocess="to-pixdata">icons/menu/light/previous.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/previous.svg">icons/menu/light/previous.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/next.png" preprocess="to-pixdata">icons/menu/light/next.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/next.svg">icons/menu/light/next.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/help.png" preprocess="to-pixdata">icons/menu/light/help.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/help.svg">icons/menu/light/help.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/light/about.png" preprocess="to-pixdata">icons/menu/light/about.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/about.svg">icons/menu/light/about.svg</file>
Updated the Network List Connect button icon on GTK3 to use the bundled zc-menu-connect asset, which avoids theme-dependent missing network-connect behavior. Added a Help menu _Update entry with a dedicated zc-menu-update icon constant, so Windows builds can display an appropriate update icon in the Help menu. Extended icon mapping/fallback logic so emoji/update icons resolve correctly across stock/icon-name paths (zc-menu-emoji, zc-menu-update) including GTK2 stock fallback compatibility. Added zc-menu-emoji to the input entry fallback icon list so the emoji affordance has a deterministic built-in fallback when theme emoji icons are missing. Added new update and emoji icon assets in both SVG and PNG for light/dark variants, and registered the PNG resources in the gresource manifest for runtime loading.
2026-02-18 01:30:45 -07:00
<file alias="menu/light/update.png" preprocess="to-pixdata">icons/menu/light/update.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/update.svg">icons/menu/light/update.svg</file>
Updated the Network List Connect button icon on GTK3 to use the bundled zc-menu-connect asset, which avoids theme-dependent missing network-connect behavior. Added a Help menu _Update entry with a dedicated zc-menu-update icon constant, so Windows builds can display an appropriate update icon in the Help menu. Extended icon mapping/fallback logic so emoji/update icons resolve correctly across stock/icon-name paths (zc-menu-emoji, zc-menu-update) including GTK2 stock fallback compatibility. Added zc-menu-emoji to the input entry fallback icon list so the emoji affordance has a deterministic built-in fallback when theme emoji icons are missing. Added new update and emoji icon assets in both SVG and PNG for light/dark variants, and registered the PNG resources in the gresource manifest for runtime loading.
2026-02-18 01:30:45 -07:00
<file alias="menu/light/emoji.png" preprocess="to-pixdata">icons/menu/light/emoji.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/light/emoji.svg">icons/menu/light/emoji.svg</file>
updated, fixed or replaced menu icons.
2026-02-17 20:05:13 -07:00
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/new.png" preprocess="to-pixdata">icons/menu/dark/new.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/new.svg">icons/menu/dark/new.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/network-list.png" preprocess="to-pixdata">icons/menu/dark/network-list.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/network-list.svg">icons/menu/dark/network-list.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/load-plugin.png" preprocess="to-pixdata">icons/menu/dark/load-plugin.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/load-plugin.svg">icons/menu/dark/load-plugin.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/detach.png" preprocess="to-pixdata">icons/menu/dark/detach.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/detach.svg">icons/menu/dark/detach.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/close.png" preprocess="to-pixdata">icons/menu/dark/close.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/close.svg">icons/menu/dark/close.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/quit.png" preprocess="to-pixdata">icons/menu/dark/quit.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/quit.svg">icons/menu/dark/quit.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/disconnect.png" preprocess="to-pixdata">icons/menu/dark/disconnect.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/disconnect.svg">icons/menu/dark/disconnect.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/connect.png" preprocess="to-pixdata">icons/menu/dark/connect.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/connect.svg">icons/menu/dark/connect.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/join.png" preprocess="to-pixdata">icons/menu/dark/join.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/join.svg">icons/menu/dark/join.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/chanlist.png" preprocess="to-pixdata">icons/menu/dark/chanlist.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/chanlist.svg">icons/menu/dark/chanlist.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/preferences.png" preprocess="to-pixdata">icons/menu/dark/preferences.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/preferences.svg">icons/menu/dark/preferences.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/clear.png" preprocess="to-pixdata">icons/menu/dark/clear.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/clear.svg">icons/menu/dark/clear.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/copy.png" preprocess="to-pixdata">icons/menu/dark/copy.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/copy.svg">icons/menu/dark/copy.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/delete.png" preprocess="to-pixdata">icons/menu/dark/delete.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/delete.svg">icons/menu/dark/delete.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/add.png" preprocess="to-pixdata">icons/menu/dark/add.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/add.svg">icons/menu/dark/add.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/remove.png" preprocess="to-pixdata">icons/menu/dark/remove.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/remove.svg">icons/menu/dark/remove.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/spell-check.png" preprocess="to-pixdata">icons/menu/dark/spell-check.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/spell-check.svg">icons/menu/dark/spell-check.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/save.png" preprocess="to-pixdata">icons/menu/dark/save.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/save.svg">icons/menu/dark/save.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/save-as.png" preprocess="to-pixdata">icons/menu/dark/save-as.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/save-as.svg">icons/menu/dark/save-as.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/refresh.png" preprocess="to-pixdata">icons/menu/dark/refresh.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/refresh.svg">icons/menu/dark/refresh.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/search.png" preprocess="to-pixdata">icons/menu/dark/search.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/search.svg">icons/menu/dark/search.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/find.png" preprocess="to-pixdata">icons/menu/dark/find.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/find.svg">icons/menu/dark/find.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/previous.png" preprocess="to-pixdata">icons/menu/dark/previous.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/previous.svg">icons/menu/dark/previous.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/next.png" preprocess="to-pixdata">icons/menu/dark/next.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/next.svg">icons/menu/dark/next.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/help.png" preprocess="to-pixdata">icons/menu/dark/help.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/help.svg">icons/menu/dark/help.svg</file>
Switched menu resource loading to use bundled PNG assets (instead of SVG paths) for zc-menu-* icons, so menu icon resolution is consistent and no longer depends on SVG/icon-theme availability on different platforms (including Win32 builds). Updated the GResource manifest so all menu icons now come from data/icons/menu/{light,dark} PNG files and are embedded with to-pixdata preprocessing, ensuring the app uses one unified internal icon set across platforms. Generated and added PNG assets for both light and dark menu icon variants under data/icons/menu/ to back the new resource paths used by the GTK menu code. Fixed menu icon resource detection to fall back from PNG to SVG when probing zc-menu-* entries, so menu item icon lookup no longer fails just because one format is unavailable at runtime. Updated GTK menu icon loading to use gdk_pixbuf_new_from_resource (instead of ..._at_scale) and added explicit fallback order across variant/light and PNG/SVG resources, which addresses the “red no-entry square” missing-icon behavior you reported. Kept compatibility with your previous menu resource setup while making loading more resilient on Win32 and other environments where resource/pixbuf behavior differs.
2026-02-18 01:16:03 -07:00
<file alias="menu/dark/about.png" preprocess="to-pixdata">icons/menu/dark/about.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/about.svg">icons/menu/dark/about.svg</file>
Updated the Network List Connect button icon on GTK3 to use the bundled zc-menu-connect asset, which avoids theme-dependent missing network-connect behavior. Added a Help menu _Update entry with a dedicated zc-menu-update icon constant, so Windows builds can display an appropriate update icon in the Help menu. Extended icon mapping/fallback logic so emoji/update icons resolve correctly across stock/icon-name paths (zc-menu-emoji, zc-menu-update) including GTK2 stock fallback compatibility. Added zc-menu-emoji to the input entry fallback icon list so the emoji affordance has a deterministic built-in fallback when theme emoji icons are missing. Added new update and emoji icon assets in both SVG and PNG for light/dark variants, and registered the PNG resources in the gresource manifest for runtime loading.
2026-02-18 01:30:45 -07:00
<file alias="menu/dark/update.png" preprocess="to-pixdata">icons/menu/dark/update.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/update.svg">icons/menu/dark/update.svg</file>
Updated the Network List Connect button icon on GTK3 to use the bundled zc-menu-connect asset, which avoids theme-dependent missing network-connect behavior. Added a Help menu _Update entry with a dedicated zc-menu-update icon constant, so Windows builds can display an appropriate update icon in the Help menu. Extended icon mapping/fallback logic so emoji/update icons resolve correctly across stock/icon-name paths (zc-menu-emoji, zc-menu-update) including GTK2 stock fallback compatibility. Added zc-menu-emoji to the input entry fallback icon list so the emoji affordance has a deterministic built-in fallback when theme emoji icons are missing. Added new update and emoji icon assets in both SVG and PNG for light/dark variants, and registered the PNG resources in the gresource manifest for runtime loading.
2026-02-18 01:30:45 -07:00
<file alias="menu/dark/emoji.png" preprocess="to-pixdata">icons/menu/dark/emoji.png</file>
Good catch on data/icons/menu — I updated the resource bundle to include the new SVG menu icons (for both light and dark variants), not just PNG entries. This ensures those assets are actually packaged and available at runtime (including Flatpak). Kept existing PNG entries intact and added SVG entries alongside them so the current icon-loading fallback behavior continues to work while enabling the newer icon files.
2026-02-21 15:46:43 -07:00
<file alias="menu/dark/emoji.svg">icons/menu/dark/emoji.svg</file>
Reorganize files and migrate images to gresource
2013-09-27 21:56:13 -04:00
</gresource>
</gresources>
Reference in New Issue Copy Permalink