Date: Mon, 22 Mar 2021 18:44:49 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> To: freebsd-hackers@freebsd.org, christos@christosmarg.xyz Subject: Re: [GSoC 2021] Project Proposal Message-ID: <d5924e61-842a-54d6-8a3e-1908225baeb2@quip.cz> In-Reply-To: <20210322161802.zouhvffwcuibwtmb@pleb> References: <20210322144928.ry75v5nlfhpzcfir@pleb> <93c692373cf35aae8dab4f1c63c38d08@bsdforge.com> <20210322161802.zouhvffwcuibwtmb@pleb>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22/03/2021 17:18, Christos Margiolis wrote: [...] > Interesting, I didn't really know about that, so I'll have to look more into it > for sure. In any case, I still think my main argument stands that a library > which can be used by all userland programs that might want to have access > to the mixer will be of benefit. > > I've already mentioned a few use cases in my initial email. Even in the case > that you outlined - the state already being cached in `/var/db/mixerN-state` - > I think that libmixer(3) could provide with functions that deal with those files, > instead of having the programmer find ways to deal with them. > > mixer(8) at the moment still doesn't have the option to mute/unmute the > mixer even with those files existing, so having a library handle all > that stuff, will make mixer(8) basically a frontend for the library and > will have cleaner code. And as I've already said in the previous email, other > programs such as MixerTUI could use the library too. I think that makes > things more extensible; after all, many FreeBSD programs already follow > that design (library + a frontend for it). Mute / unmute will be nice, library + frontend too. But I think there is no need to have a running daemon for it. Just my $0.02. Kind regards Miroslav Lachman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d5924e61-842a-54d6-8a3e-1908225baeb2>