On 11/07/2015 11:49 AM, Fons Adriaensen wrote: > On Thu, Nov 05, 2015 at 04:09:43PM -0500, Paul Davis wrote: > >>> The clean solution to that would be to remove testing that >>> env variable. In other words, *if* you want a non-default >>> server, you (the app) has to specify it. Much less confusing. >>> Then every jack app would need to implement this. More replicated code with more potential bugs. IMHO a cleaner solution would be to remove the option from jack_client_open() and always force the use of the env variable and let libjack deal with it. If a client really needs to set the server-name it can use setenv() before calling jack_client_open(). Anyway, it's too late now to change the semantics of the API. >> this doesn't address what happens when someone has started the *server* >> with a name (because they didn't understand the significance of doing so). > > How would anyone start the server with a non-default name and > not know what he/she is doing ? Looks like a documentation > problem in that case. You don't know newbies: "Oh, a 'Name' field, nice I'll name my server before reading any documentation." And no, telling a casual musician to read the jack documentation first is not the way to go, either. Old qjackctl was partly responsible. The server-name field was very prominent top-middle of the settings dialog and also the only centered item which made it stick out visually. This has meanwhile been addressed (not removed, but simply moved to an "advanced" pane). >> i want to support corner case use cases only to the extent that they do not >> pollute/confuse the workflow for the common case. > > It's easy enough to do that without making things impossible. Did someone suggest to remove features or make things impossible? I was under the impression that this is about clarifying and simplifying issues that are too complex or confusing for their own good. 2c, robin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
