Since I wrote the announcement of Boatswain, things have progressed quite a lot. As I prepare for the 1.0 release, more features and bugfixes get in, and it’s getting dangerously close to achieving all features I personally want from it.

Stream Deck Mini & Original (v1)

Thanks to a generous Stream Deck Mini donation, I managed to fix a couple of bugs in the HID code that controls is. It is now able to upload icons to buttons, and properly fetch the serial number of the device.

Later on, a kind individual helped testing and debugging the Stream Deck Original (v1) code. I only have a 2nd generation Original, and the HID protocol changed significantly between them, so this testing was invaluable. There were another couple of bugs specific to Original v1 fixed in no time after they were reported.

Because Stream Deck Original (v2), XL, and MK.2 seem to share the same HID protocol, I’m cautiously confident that they all should be fine.

MPRIS

Something that has been quite high on my list was to integrate Boatswain with media players. I originally thought about adding media player capabilities to Boatswain, but the moment I returned to a sane state, I realized I really did not want to get in the media players business. Let’s leave media players to the people who know how to write media players 🙂

The alternative to writing my own media player inside Boatswain was to integrate it with existing ones. Fortunately for us, people solved this integration problem 16 years ago, and it’s called MPRIS. The MPRIS API is absolutely insane, and it makes me want to retire, but it is what it is, and it was the shortest path between me and my goals.

As far as I could test, it works with GNOME Music, Rhythmbox, Spotify, and Totem. There’s no reason to think it won’t work with other MPRIS media players.

Cross-device Profile Switching

Now that I have two Stream Decks, one nice little feature I thought would be nice to have is the ability for one device to change the profile of the other. This is not rocket science, neither it is a breakthrough in user experience, but it does allow using e.g. the Mini as toplevel controller, and the Original as the actual holder of buttons.

This was by far not a priority for the 1.0, but one of my goals with Boatswain is to have fun, which is something I barely have with coding these days, and implementing this definitely sounded like fun! I’m happy I did this, because it did allow me to find other bugs in unrelated parts of the codebase, all of which are fixed.

Assets & Hardware Simulator

Part of the beauty of Boatswain is that my goal with it is to make it pretty, easy to use, obvious, and most importantly, the app must Just Work. To have the latter, Boatswain is forcing me to work on various parts of the stack (systemd, portals, etc) to actually ensure everything is in place for it. But to make it pretty, obvious, and aesthetically pleasing, Boatswain requires assets.

Lots of assets.

And it is in times like this that I bother the GNOME design team. Jakub and Sam have been producing these assets, and let me tell you, they are truly outstanding at their work. I am so happy that these visual craftsmen are part of the community! Good, well rendered icons are single handedly the most important part of what makes Stream Deck buttons look sophisticated.

Boatswain in fact now has a small library of custom icons. I’ll grow it over time, adding more icons from the GNOME icon library as needed, but it already is rather nice:

Icon library in Boatswain

In particular, in order to test how these icons would look without having a real Stream Deck to use, Jakub did what anyone would do in this situation: a photorealistic 3D modelling of Stream Deck Original, with camera work, lighting, diffusion, and motion for button pressed. To test these icons. Have a look:

If anyone wants to play with this, the Blender file can be found in Boatswain’s repository.

More OBS Studio

By the time I announced the project, Boatswain already had some integration with OBS Studio through obs-websockets. I’ve added more actions to it, and now it feels pretty complete in terms of regular features – I have been using it to drive my own streams now, and if it’s enough to me, I’m happy already.

The OBS Studio plugin now is able to mute and unmute audio sources (including global audio sources), and show and hide other sources. I think this should cover most cases already. I don’t plan on implementing every single request that obs-websockets expose, so this is probably as far as I will go with the OBS Studio plugin for now. (Of course, if anyone wants anything else and is up to write the code and maintain it, I’ll happily accept the contribution.)

So, What’s Next Now?

As Boatswain continues to grow, it’s only natural to ask when it will be published on Flathub. The Boatswain release is currently blocked on systemd 251, which is the first version that will contain the udev rules that allow Stream Deck devices to be accessible from regular user sessions.

I’m waiting for this systemd release because I want to be able to at least point people to a systemd release they should have if they want a smooth, zero setting up process. Without this release, every single one who tries to use Boatswain would have to add a custom udev rule under /etc, which is of course awful and I can’t provide any support for.

Once systemd 251 is out, I’ll roll a release, publish on Flathub, and submit it to the GNOME Circle. Flathub will be the only distribution method I am willing to support, any other packaging form should be considered unofficial and unsupported.

Buy Me a Coffee at ko-fi.com

7 responses to “Updates on Boatswain”

  1. Is it possible to get the systemd patches backported to systemd-stable? If so, that could help fedora 36 and Ubuntu LTS

    1. This is up to distros, you should ask Fedora to backport that. I don’t think I want to deal with distros for that.

  2. […] Updates on Boatswain – Georges Stavracas […]

  3. Patrick Avatar

    Looks cool. Could this also work with the simple switches for nob?
    https://www.nobcontrol.com/nac

    1. If someone writes the code, and is willing to maintain it, then sure.

  4. Why are the udev rules bundled with systemd anyway? Wouldn’t it make sense to put them in a separate repository?

    1. You’re gonna have to ask systemd and udev developers

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.