I've had fun in my last couple of Always Developing sessions.
In the first of them, Always Developing #55, I had a quick look at the Wails desktop app framework that uses Go for the backend, and web technologies for the frontend.
I of course used Svelte on the frontend đ. After a quick look, I then started seeing if I could work out how to package the demo app as a Flatpak. This was in response to a discussion thread I'd seen on the Wails GitHub repo.
I didn't get far with the Flatpak in session #55 as I ran out of time. But this morning I had a bit of time so had a go at finishing it off in Always Developing #56, and actually managed to do it. đ
Today I published a rather sombre Always Developing session to YouTube. In it I go over how far I've managed to get with my attempt to package Snippet Pixie as a Flatpak.
As you can tell from this post's title, and first sentence, it's not looking good for getting Snippet Pixie packaged up using Flatpak, and therefore it's unlikely to make it into elementary OS 6.0's AppCenter.
This is a shame as I really like elementary OS, and I especially like what the elementary project is trying to do to encourage Linux application development via a number of initiatives, including the AppCenter. And elementary OS 6 is fantastic, the amount of work that has gone into it is mind boggling, it is a truly beautiful release that all involved should be extremely proud of.
However, the new AppCenter requires curated applications to be provided as Flatpak packages, and unfortunately Snippet Pixie uses a couple of technologies that the Flatpak sandbox will not allow as they have the potential to be abused.
I've made no bones about the fact that I prefer Canonical's more flexible Snap package format over Flatpak, and very much wish elementary could have used Snap instead, but given their criteria I totally agree that Flatpak is the correct choice for the AppCenter.
It's just unfortunate that Flatpak does not have the equivalent of Snap's "classic" confinement which allows for an application to be distributed as a Snap but does not impose a sandbox on it. Snap has this "classic" confinement (i.e. not confined) mode to enable certain classes of application to be distributed which Snap's current sandbox features can't yet support, or may never support. I guess that's one of the main strengths of Snap, because there is a single Snap Store managed by a trustworthy company (Canonical, makers of Ubuntu), they have the ability to vet an application that needs to break out of the sandbox to ensure it is safe. This is different to Flatpak which does not have a single source of packages (even though flathub is effectively the de-facto single source), and so the Flatpak project can't vet each package for trustworthiness. You could argue that each repository of Flatpaks should verify each new package and determine whether its permissions are appropriate, but the Flatpak project can't stop a nefarious repository from springing up that distributes compromised versions of apps. So I understand why the Flatpak project is reticent to allow various potentially dangerous sandbox permissions, or enable a non-sandboxed mode.
Therefore Snippet Pixie is very unlikely to make it into the elementary OS 6.0 AppCenter. It is however available via the Snap Store, and nixpkgs.
In the future I may explore other means of distributing Snippet Pixie. I haven't as yet tried packaging it as an AppImage, and given that up until elementary OS 6.0 the AppCenter has been using Debian packages, maybe I should investigate whether packaging for Debian is a goer too. đ¤ˇī¸
I may also explore using different technologies for building Snippet Pixie seeing as I no longer have a strong incentive for using the technology stack that elementary promotes. There are some definite shortcomings in the way I built Snippet Pixie that I'd like to address now that I know better, maybe a Snippet Pixie 2.0 rewrite in a different language could be on the horizon? Having said that, the whole Vala + GTK + Granite thing is pretty sweet, there definitely could be a case made for just improving what's already there?
Subscribe to my Always Developing YouTube channel to find out what I do next with Snippet Pixie!
Today we were de-cluttering and I found my wedding ring! đī¸
I thought I'd lost it before moving back to the UK from NZ, when I'd lost a good chunk of weight, figuring it just fell off while out and about and was lost for good. I had been very conscious of how loose it was at the time. But it turns out I somehow left it in a small bag of ties, cufflinks etc. Maybe it fell off while I was filling the bag and didn't notice at the time.
So for approx 5 and a half years I've not been wearing a ring, feels great to be wearing it again.
The other day I was using an Ubuntu VM and noticed that for some reason Snippet Pixie failed to run with some weird error related to its settings schema not being available. As I was mucking about with configuring an i3wm desktop I didn't really think much of it, thinking I'd likely broken something along the way.
However, this evening I thought I'd just double check what was up with that VM and give the Snippet Pixie snap a proper test on a stock Ubuntu VM I have hanging around for just that use-case. At first all looked fine, but then I decided to fully purge the existing Snippet Pixie install and clean install it. And of course it then had the same problem.
After much experimentation I found that some time between when Snippet Pixie 1.5.1 revision 138 was released on 2021-03-26 and the next rebuild as revision 141 was released on 2021-04-14, fresh installs no longer copied the settings schema file into place on first run.
I suspect there was a release of snapcraft (the tool for building snap packages) that changed something, likely security related.
I searched for anyone else having the same issue in the snapcraft forums but couldn't see anything that looked related, which made me think that it was likely then to be a problem with how I was building the Snippet Pixie snap package.
I ran a few tests, building the snap locally and installing it in the VM, sure enough it failed to install the settings schema at runtime. The only way I could get the settings schema to install at runtime was by explicitly installing a revision before 141 from the snap store.
I tried a few different things, looking to see if I could upgrade anything related to how snaps are built, but what with Snippet Pixie needing to be a "classic" confined (e.g. not confined) snap, I couldn't take advantage of some of the newer niceties such as the gnome-3-38 extension.
One thing stood out when I checked the details of that gnome-3-38 extension:
ian@ians-apollo:~ $ snapcraft extension gnome-3-38
This extension eases creation of snaps that integrate with GNOME 3.38.
At build time it ensures the right build dependencies are setup and for the
runtime it ensures the application is run in an environment catered for GNOME
applications.
It configures each application with the following plugs:
- GTK3 Themes.
- Common Icon Themes.
- Common Sound Themes.
- The GNOME runtime libraries and utilities corresponding to 3.38.
For easier desktop integration, it also configures each application entry with
these additional plugs:
- desktop (https://snapcraft.io/docs/desktop-interface)
- desktop-legacy (https://snapcraft.io/docs/desktop-legacy-interface)
- gsettings (https://snapcraft.io/docs/gsettings-interface)
- opengl (https://snapcraft.io/docs/opengl-interface)
- wayland (https://snapcraft.io/docs/wayland-interface)
- x11 (https://snapcraft.io/docs/x11-interface)
It mentions enabling the "gsettings" plug, which is exactly the same area that I was having problems with. This got me thinking about which libraries the snap used at build and runtime, which lead me to notice a peculiarity with the snapcraft.yaml. While the "libglib2.0-dev" library was being used during build, the equivalent "libglib2.0-0" runtime library was not being staged for install.
So I added that library to the stage phase of the snapcraft.yaml and built and installed a local snap package from it, and it worked! đī¸
So, long story short, there's a new build of Snippet Pixie in the snap store that should actually work!
It's a little disheartening though to think that for 6 or more weeks Snippet Pixie has not been working for new installs of the snap version, and no one either noticed it or bothered to tell me if they did. âšī¸
Ugh, it had to happen at some point, and today was the day.
I couldn't record my daily Always Developing session this morning as I had a couple of things to do before work, and my computer was acting up and needed some TLC anyway. So instead I recorded session #30 this evening.
However, after finishing up a fantastic recording of me adding terminal emulator support to Snippet Pixie, I gave the mp4 file a quick preview only to find that it had no sound! âšī¸
You can see me in the bottom right hand of the screen moving my lips and gesturing away, but alas my wonderfully eloquent commentary is unheard.
I tried checking the original mkv file, but it too has no sound.
It's a bit of a head-scratcher as I explicitly check the levels in OBS before every recording and it uses the mic directly, not the "system default". Although I do have to set the system default audio input and output devices after any reboot as otherwise it tends to pick the wrong devices, but I forgot to do that this morning when I was fixing some stuff up. I guess there's a difference between what OBS shows in the audio mixer and what is actually used for recording. đ¤ˇī¸
It's quite annoying as the session went really well, and I was quite proud to be able to get Snippet Pixie working with terminals simply by holding down the Shift key when selecting a snippet from the Search and Paste window. I even prepared the 1.5.2 release on camera, which was a nice way of showing what kind of thing you need to do to release an update to the elementary OS App Center. Although I did have a problem right at the end with getting to the developer dashboard, which of course worked straight away after I finished recording.
Once I realised that the video was duff, I decided to check all my settings and make a follow-up recording to test that my audio was working again. So in session #30.1 I briefly explain what #30 was all about and gave a quick demo of the new version. As I'd already gone ahead and started the release process of Snippet Pixie 1.5.2 to the App Center, and pushed out the snap version already, I then went on to prepare and submit the nixpkgs/NixOS PR too. So if you're at all interested in how you release an update of a simple package to nixpkgs, Always Developing #30.1 might be worth a look.
Yup, I decided to release #30 even though it has no sound, just for giggles. đī¸ This will be especially amusing to Erik, my team mate at Delicious Brains, as we have a bit of a running joke about audio problems with our daily stand-up meetings.
The good news is that Snippet Pixie's new ability to Shift-Ctrl-V paste a snippet into the command line or application like Vim running in a terminal, got lots of use while writing this little post! Simply using Shift-Return or Shift-Click in Snippet Pixie's Search and Paste window is incredibly convenient. đī¸
Last week I wrote an article about how my personal site is now a Gemini Capsule by default, and only just now remembered to post something on Twitter about it. đ¤Ļī¸
I encourage you to quickly check out that “Hello Gemini World” post to get a taste of how simple the Gemtext format is. It’s effectively a reduced line based Markdown format.
The Gemtext format is very attractive to me, its incredibly easy to write and read, not only for humans, but software too.
As noted in my previous post, I believe the format’s constraints help you concentrate on writing rather than thinking about text markup style, link placement, and images etc. With so few formatting options, the words you use have more significance.
An incredibly appealing aspect of the Gemini protocol is its compatibility with terminal based clients (browsers if you will). I’m using one that seems to be rather popular called Amfora.
Over the last few weeks I’ve been using Amfora in preference to Firefox where possible to read a bunch of articles, bookmarking them and then enjoying the distraction free reading experience while having my breakfast. I’m a big fan of Instapaper, but the formatting of articles written in Gemtext is even easier to read.
Being keyboard driven it’s very fast to navigate sites, including just hitting a number to go to visit a link. And my site’s new home page looks lovely in Amfora, especially with a slightly modified Nord theme.
This is a lovely little bit of software written in Go that takes your “.gmi” files that optionally have a little bit of extra “frontmatter” at the top, mixes them with some templates, and spits out a site with nice index pages and feed files etc.
If you look closely at the changelog for kiln you may see that the author, Adnan Maolood, was kind enough to accept a couple of bug fixes from yours’ truly.
While kiln is relatively simple, it’s very powerful, utilising Go templates for some serious flexibility of output.
The majority of the site’s content comes from the Markdown posts I had in the WordPress version of the site I’ve been running for a few years now.
I backed up the site’s database with WP Migrate DB Pro, and then tar’d up all the site’s files (including the db backup) and downloaded it.
Then I re-hydrated just the database and extracted all the posts I wanted with a simple bit of SQL.
I wrote a shell script that ran through those records to extract the fields I needed such as title, date and content, and then processed them to clean up the titles, content and file names as much as possible.
The shell script included usage of a Python script called md2gemini that did the heavy lifting when it comes to removing all the stuff Gemtext doesn’t support and moving links onto their own lines.
The result was far from perfect (mainly because of some WP encoding stuff), but helped immensely, definitely something I could work with. The shell script I wrote went through many iterations as I fine tuned the output for the different types of content I had in the WP based site, from articles to microblog posts to podcast episodes.
Eventually I had all the posts/microblogs/podcasts output to somewhat usable gmi files that were handled well by kiln, and which I could just manually clean up pretty easily (I don’t have a huge amount of content, yet).
With kiln you can naturally output a site that uses the Gemini protocol (gemini://) and Gemtext formatted text that Gemini browsers happily read. However, you can also pre or post process the output in a build task, and this means you can use a tool such as gmnitohtml to create a version of the site for the web.
That gmnitohtml application is also by Adnan, and works really well to convert Gemtext to HTML.
So I built a very simple HTML template, sprinkled in some custom CSS (Nord flavoured of course), and Bob’s your uncle, out pops a nice clean no-nonsense web site.
At some point I should probably write up a tutorial on how to use kiln, might be useful to someone.
I’ve been using sourcehut for a little over a year now, very much appreciate the simplicity and power. It’s great stuff, and I’m using git.sr.ht for the site’s repo along with builds.sr.ht to build and deploy the site every time I commit a change.
And what’s really nice is that Gemini is fully supported, so both the Gemini and web versions of the site are hosted there and deployed at the same time.
There’s a good chance that I missed something while re-building this site, so if you find any problems or just want to chat about Gemini or how I built the site, please drop me a line.
