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@trinitydesktop.org