For completeness I added ALSA support and OSS support. I think OSS support would be most likely used by FreeBSD.
I tested alsa pretty thoroughly by turning off pulse and testing out ALSA over the weekend.
The OSS support was very lightly tested because I don't have FreeBSD access so i am using the alsa oss emulation module.
I have two branches out there
alsa-wip and-the-oss-you-rode-in-on
overall it adds complexity to support multiple backends, but if we support these 3 there are probably pretty few complaints about making it a full replacement.
Anyway, if someone has FreeBSD on the desktop with real audio cards that would be interesting to me - though the /dev/mixer and /dev/dsp interfaces are pretty simple themselves, I don't have complex real cards to test with.
I also have concerns around packaging; if I compile this with libpulse and those libraries arent available on a users server, it won't run the program... but I imagine some users won't have pulse installed. I don't know how packagers typically approach this. I'd prefer it be an optional dependnecy, but to manage that at runtime I would have to do runtime loading with dlopen.
Looking for feedback on the above sections
Thanks, Calvin
On Sun, May 17, 2026, at 7:12 PM, David C Rankin via tde-devels wrote:
On 5/17/26 7:30 AM, Calvin Morrison via tde-devels wrote:
Well done Calvin!
This is also a great example for use of ksystemtray.h which I had searched the old kde docs and not been able to find anything other than the class reference and its "very terse" set of notes on implementation.
one of the harder parts of the interface I felt to 'get right' went through about 4 or 5 iterations. the pulse stuff was working in my kmix branch, but to get tmix to 'work', and for something as important as a systray for volume it needs to 'just work' intutively... it was hard to get right. for example, i think the balance widget is intuitive but was not immediately obvious how to make it so.
This is where I got stuck with my display backlight program for integrated displays (laptops/all-in-one boxes). I had the dbus implementation done. I could use it from the command line or a small window with integrated slider/spinbox but wanted the kmix type implementation in systray so all you needed to do was roll the middle-mousewheel over the systray icon to alter backlight like you can do with volume in kmix.
Did you find any other docs that helped or did you use kmix or knemo or some similar app to sort this out?
The entire thing started as a fork of kmix but it got basically 'stuck'. KMix was designed in a way that i couldnt move past from, especially in regard to how available streams change so frequently with pulse having to reload / redraw the interface was funky.
Yep, been there. I used both kmix and knemo as examples that I worked to dissect, but pulling the basic ksystray implementation out of the set of split files and classes did not end well :)
I'll give it another go using tmix as a go-by and will hopefully have better luck. Thanks!
-- David C. Rankin, J.D.,P.E. ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...