icon: one 1024 master downscaled to five sizes, with transparency by Ryanmello07 · Pull Request #7 · urnetwork/linux

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 · 2026-08-21T06:20:18Z

Stacked PR — depends on #5 (app id rename).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Two separate defects in the shipped icon, both visible on an ordinary desktop.

Transparency. The old artwork had an opaque background baked in, so the icon
rendered as a square tile wherever the shell composites over its own surface —
the GNOME dash, the app grid, and the window's own title bar. The replacements
are RGBA with a real alpha channel.

Sizes. Only 48 and 256 were installed. The desktop asks for 64 in the app
grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the
nearest size it has, so those lookups were being served an upscale. This
installs 48, 64, 128, 256 and 512.

All five are downscales of a single 1024×1024 master — the same AppIcon artwork
the Apple client ships — so they cannot drift apart the way separately-drawn
assets do. The master is committed at
app/packaging/icons/com.bringyour.network-master-1024.png for regenerating
them.

512 is the ceiling, deliberately

Installing the 1024 breaks the Flatpak build outright. flatpak build-export
refuses it:

Image too large (1024x1024). Max. size 512x512

and fails the whole build at export time. Nothing downstream wants a larger one
— Flathub renders the store page at up to 512 — so the master stays in the tree
but is not installed. The comment in app/meson.build says so, because this is
exactly the kind of thing someone re-adds six months later.

Both installers list the same five sizes

app/meson.build installs for the Flatpak; packaging/lib/common.sh's
assemble_daemon_root() builds the staging tree that the .deb, .rpm and
tarball are all cut from. They now list the same five, and the tarball
uninstaller removes all five — a size installed by one and forgotten by the
other is a file left behind on uninstall.

Why this is split this way

Artwork review and rename review are different jobs. PR 2 renames the two
existing icons byte-for-byte so its diff stays legible as a rename; this PR
changes what the pixels are and which sizes ship, which is the part worth
actually looking at. It cannot go first: the filenames it writes to only exist
after the rename.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Ryanmello07 added 2 commits August 20, 2026 23:05

Ryanmello07 changed the title ~~PR 3 — upstream/app-icon~~icon: one 1024 master downscaled to five sizes, with transparencyAug 21, 2026

This was referenced Aug 21, 2026
metainfo: stamp the release version at build time, add a screenshot, validate it #9
Merged
flatpak: stamp the version and arch in the build script, and name the bundle by arch #10
Merged

Ryanmello07 marked this pull request as ready for review August 21, 2026 15:40

Ryanmello07 merged commit d6bc4a6 into urnetwork:mainAug 21, 2026
3 checks passed

Uh oh!

Conversation

Ryanmello07 commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

512 is the ceiling, deliberately

Both installers list the same five sizes

Why this is split this way

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Ryanmello07 commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

512 is the ceiling, deliberately

Both installers list the same five sizes

Why this is split this way

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Ryanmello07 commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

512 is the ceiling, deliberately

Both installers list the same five sizes

Why this is split this way

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Ryanmello07 commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

512 is the ceiling, deliberately

Both installers list the same five sizes

Why this is split this way

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Ryanmello07 commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

512 is the ceiling, deliberately

Both installers list the same five sizes

Why this is split this way

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Ryanmello07 commented Aug 21, 2026•
edited
Loading

Ryanmello07 commented Aug 21, 2026•
edited
Loading

Ryanmello07 commented Aug 21, 2026•
edited
Loading

Ryanmello07 commented Aug 21, 2026•
edited
Loading

Ryanmello07 commented Aug 21, 2026•
edited
Loading

Ryanmello07 commented Aug 21, 2026•
edited
Loading

Ryanmello07 commented Aug 21, 2026•
edited
Loading