I've picked up my Xperia again, and have been giving Sailfish a fair shake. This involved writing code to replace the apps I left behind on Android, and looking at code I wrote around 2013.
Setting up the SDK
Setting up the SDK was a ball-ache, that's the main note.
- The SDK's online installer depends on OpensSSL 1.1. Which isn't packaged in Ubuntu 22.04 (KDE Neon).
- I tried it on Ubuntu 20.04, but ended up with confusing VirtualBox issues.
- The offline installer worked on Ubuntu 22.04, as did the VirtualBox side of the SDK.
- I'd rather use the docker build environment, as I don't need the emulator. But podman-docker is incompatible.
Getting the phone into development mode was straight forward, and the build/install process is done with well-tested tools. That is to say, QtCreator uses qmake to build the project as an RPM, which is then copied to the phone over SSH, and installed with a sensible package manager that pulls down dependencies.
Sailfish is on an old version of Qt, and that doesn't seem to be changing.
QtCreator is just fine. It works.
Icinga
Icinga has a well-documented JSON API, so it's a natural first application to write. On Android I've made us of anag, which is proprietary software, so the issues I have with it are (practically) unfixable. Here's my notes on the development process and the app:
- The default QML template is perfect for a small application. One cover, two pages.
- QML is very simple. There's some poking and prodding to figure out things like aligning two labels in a column into the column's vertical-centre. But it's easy to get a feel for development.
- The Nemo QML plugins for configuration storage and background work are dead-straight-forward. Drop in the import and use the component as in the documentation.
- Complex code can be offloaded into a WorkerScript, and the onMessage signal makes it fit nicely into a QML-only application.
- Icons are (strangely) low-resolution. Given Sailfish is targetting devices with high-PPI screens, you'd think the recommended icon size would be larger.
Misskey
Rather than implement everything Misskey needs (the API is, again, well-documented) - I instead leveraged Sailfish's 'WebView', and only used the API for fetching information for the Cover page.
- WebView is based on Mozilla technology, which is odd, but welcome.
- It's enough to drop a component on a page, and you have your embedded web content.
- Adding controls is a case of creating those components and then setting anchors appropriately.
- Misskey's mobile UI (like many projects these days), makes native-UI controls redundant anyway. I can just embed the page and be done.
- Again, the WorkerScript system works really well with the BackgroundJob system.
- Credentials are shared with the Sailfish browser's store, so I don't need to handle those either.
Music
I wrote a music player named 'Shanty' back in 2013-ish. The stock music player depended on indexing metadata, and my collection was well-enough organised to not need that. On top of this, album art in my collection is stored as 'folder.jpg'. Usually around 1400x1400 pixels in size. Indexers tend not to handle album-art-as-individual-files well.
Shanty was okay. It had some obvious problems, both in terms of code and functionality. But for a first-attempt at developing any sort of application, it would have been a passing grade (without merit).
Porting shanty was difficult. I'd made design decisions at the time that worked, given how Sailfish worked (for example, triggering cover actions by pressing on the cover and swiping). I'd also (seemingly) implemented a convoluted signal-passing system that would propagate state down the page-stack. Understanding the UI code was easy, understanding the long series of conditions I'd written to handle shuffle, replay (track/album) - was not. Some code ended up being redundant (as the QML Audio component has improved over time).
Having written the two small apps above, I took to writing Shanty again from scratch. This time calling it 'Music'.
Depending on a very specific library hierarchy made it incredibly easy. I've used the same
\~/music/genre/album/01.234. title.extfor over a decade now - why support anything else?The Qt 5.6 Audio component still doesn't support flac metadata, seemingly. So the path is used instead. This means no artist, album artist, composer, or year. But I have nowhere to display them anyway.
There is no seeking. Or previous track. Previous might be implemented - the requirements are already there. Seeking likely wont, as I don't think I've ever used it.
I'm not depending on the Nemo Thumbnail component for the album view. Instead I have a 172x172
folder.jpg.thumbfor each album. I might explore that at some point.Pause-on-headphone-removal works without any code. Which is a nice improvement.