22 Nov
2015
22 Nov
'15
3:27 p.m.
On 11/07/2015 11:49 AM, Fons Adriaensen wrote:
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).
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
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. 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.