Data & AI architect by day, open source developer by night. Ex-founder, Linux convert, and firm believer that the human is still the most important part of the loop.
Nice to see more native GTK 4 + libadwaita apps instead of another Electron wrapper. I’m building a GNOME photo app myself, so a couple of thoughts from a little further down the same road.
I’d pull Flatpak forward on the roadmap. I’m on Fedora, so the .deb and the install script don’t really work for me, and Flathub is how most GNOME users outside Ubuntu will find you. The bigger reason is what happens if you develop against your host’s GTK and package later: the GNOME runtime you end up targeting can ship a different GTK from your host, and APIs you’ve come to rely on aren’t there or behave differently. Building inside the GNOME SDK from the start means you develop against what your users will actually run. I wrote up the setup I use here. It’s Rust, but the Flatpak side carries over to Python.
On the stale-pages lint: I ran agents over legacy ETL code and built a checker expecting it to catch hallucinations. What it actually caught was documentation that had been correct and drifted out of date as the source changed. Since your pages already record where they came from, checking them against the current sources (if the lint doesn’t already) could make it really useful.
Starred, and I’ll give it a proper go once there’s a Flatpak.
Source drift is now tracked, straight from your point: gknowledge notices when an original file changed after ingestion. It flags the source, can update and re-ingest it, and exposes a stale_sources tool over MCP
(github.com/openapi/gknowledge/pull/42).
We took your runtime advice too: make start-flatpak runs the dev loop inside the GNOME runtime, so UI work is tested against the GTK/libadwaita that Flatpak users actually get. It already caught a real bug (SQLite WAL vs. the
document portal) before release.
We've only tested on Ubuntu so far. If you give it a spin on Fedora, I'd love to hear what breaks, and reviews or issues are very welcome. Also: would you mind if we linked your GNOME SDK write-up from our contributor docs?
Data & AI architect by day, open source developer by night. Ex-founder, Linux convert, and firm believer that the human is still the most important part of the loop.
Nice to see more native GTK 4 + libadwaita apps instead of another Electron wrapper. I’m building a GNOME photo app myself, so a couple of thoughts from a little further down the same road.
I’d pull Flatpak forward on the roadmap. I’m on Fedora, so the .deb and the install script don’t really work for me, and Flathub is how most GNOME users outside Ubuntu will find you. The bigger reason is what happens if you develop against your host’s GTK and package later: the GNOME runtime you end up targeting can ship a different GTK from your host, and APIs you’ve come to rely on aren’t there or behave differently. Building inside the GNOME SDK from the start means you develop against what your users will actually run. I wrote up the setup I use here. It’s Rust, but the Flatpak side carries over to Python.
On the stale-pages lint: I ran agents over legacy ETL code and built a checker expecting it to catch hallucinations. What it actually caught was documentation that had been correct and drifted out of date as the source changed. Since your pages already record where they came from, checking them against the current sources (if the lint doesn’t already) could make it really useful.
Starred, and I’ll give it a proper go once there’s a Flatpak.
Thanks again, Justin — your comment shaped the last release.
Flatpak is out (v0.3.0, GNOME 51 runtime, PDF support included):
flatpak install --user --from openapi.github.io/gknowledge/io.gi...
Source drift is now tracked, straight from your point: gknowledge notices when an original file changed after ingestion. It flags the source, can update and re-ingest it, and exposes a stale_sources tool over MCP
(github.com/openapi/gknowledge/pull/42).
We took your runtime advice too: make start-flatpak runs the dev loop inside the GNOME runtime, so UI work is tested against the GTK/libadwaita that Flatpak users actually get. It already caught a real bug (SQLite WAL vs. the
document portal) before release.
We've only tested on Ubuntu so far. If you give it a spin on Fedora, I'd love to hear what breaks, and reviews or issues are very welcome. Also: would you mind if we linked your GNOME SDK write-up from our contributor docs?
That was fast, and a stale_sources tool over MCP is a really nice touch. Good catch on the WAL and document portal bug.
Of course, link away. Part 1 is the one: fromthearchitect.dev/posts/gnome-r...
I'm on Fedora 44, so I'll install the Flatpak this week and open issues for anything that breaks.