darkhz @ darkhz @lemm.ee

Posts

18

Comments

8

Joined

2 yr. ago

Yes, I am already considering it, but it has various limitations, which I would like to avoid.

It's not about the size of the stacks IMO, the Bluetooth stack is notoriously difficult to interact with since the implementation varies wildly across different platforms and maybe architectures, and communicating with those different stacks is difficult, in a way. And within each stack you may find many features that are sparsely or not documented at all.

Just saying, but if it were easy, cross-platform libraries would have been developed long ago, but to this day most libraries have implementations where some functions are either finicky or not implemented. In no way am I trying to criticize the authors of those libraries, IMO it is a commendable achievement that they have understood the standard and the different stacks and have attempted make it cross-platform friendly and easy-to-use, but that's just the state of Bluetooth these days.

I would like to be involved in the development as much as I can, but I cannot work on rust since I have no experience with it, unlike with Go and Java (a little). Also, cross-platform libraries tend to have more limitations and caveats as to what is implemented and usable. But please, do link the rust library here so I can check it out.

I think platform specific binaries is the way due to more flexibility, although we can debate about that. My objectives are to provide a standard API for any bluetooth client to use, and to retain bluetuith's existing features. If you are willing to contribute to the MacOS part of it, it would be great, and we can have further discussions via DM.

Windows is indeed a different beast, which is why I am looking for contributors. For Linux it can be done, but since I don't have a macOS based device, I cannot work on a macOS based implementation.

Haha, I noticed that and edited it out. I had posted this to Reddit as well, and I copy-pasted it here.

You have quite an interesting situation here. You could use a good Bluetooth adapter, pair all your devices to it, and maybe use pulseaudio/pipewire (depending on what your system uses) to manage audio inputs/outputs?

Very interesting. This looks fine on my Firefox Nightly for Android application. I wonder why it renders differently on different versions of Firefox alone.

Ah, I apologize for not documenting the quit key correctly.

The quit keybinding has been an issue (albeit a very silly one), which could be easily corrected, but somehow escapes my attention during the release phase. I will correct the documentation.

Do note that since the keybindings are customisable, you can modify the quit behavior to a keybinding of your choice. See the "Configuration" section of the documentation for more details.