drew Roberts wrote: > Doesn't my idea of having the new way check for the old way on start and > translate between the two solve this issue? (And write the old way file on > new way changes.
This would be unnecessarily complicated. End result: extra time spent writing conversion code, bugs causing incomplete conversion, two config files constantly out of sync, people complaining about MIDI disappearing or devices switching randomly. A better way: allow only JACK-legacy or JACK-DBUS to be installed at the same time. Situations where both jackd and jackdbus need to be used on the same system are rare enough to ignore them. The people who are, for any reasons, preferring the old "fork and spam" launching interface would use legacy jackd with legacy libjack that starts the legacy jackd via fork-and-exec and parses the command line switches out of the .jackdrc file. Then, they can use qjackctl, ardour's JACK configuration dialog and other legacy control tools. The remaining people would use DBUS-aware libjack with DBUS-aware jackd and DBUS-aware control/monitoring tools (jack_control, ladiconf, laditray, lpatchage). This would definitely work better if the usability of those tools was improved. Potentially much better than what "fork and spam" version can ever achieve, due to inherent limitations of that model. Mixing those two models on one system is more trouble than it's worth - there are no benefits whatsoever, and any extra code to convert settings from one version to another is only adding to bloat and resulting bugginess. I don't even know why is it possible to install both versions of jackd at the same time, while client library only supports starting one of them. Ideally, jackdbus shouldn't even allow jackd binary to exist in $PATH (and vice versa), to prevent the exact kind of situation that Fons is experiencing. Krzysztof _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
