You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good point - I'll definitely make a strong justification for any UI changes I propose.... and then see what others think.
For this button, I would say leaving it as a command line option in 3.8.1 would give a nice chance for technical users to test the functionality thoroughly, before the more 'casual' users see it in the UI in 3.8.2
Looking at the existing start up code (I've started on a rewrite of how settings are handled), it would currently need a restart of the application to get this working, as the socket is created and bound once when the Client or Server start up.
You wouldn't want to do it in the middle of a jam, either. Doing the network renegotiation would break things up.
So even if it were in the GUI, it wouldn't have any noticeable effect until the application was restarted. That could be confusing for people.
(Currently, each "connection" (a Channel) gets passed the same Socket instance to use. The Server must have the Socket without any connections, in order to work at all, of course.)
OK, my rewrite of the start up will help, anyway. Currently, reading Settings requires the Client or Server to have been created, which means the Socket has been created and it's too late to use whatever was in the Settings. I'm hoping to get all the defaults, settings and command line processing done before creating the Client or Server...
I have some rework on commandline options and settings handling in progress that would allow you to store most commandline parameters in the ini file. I think that that would also solve this problem.
In this case the general idea would be to run Jamulus with a --store parameter once. i.e.: Jamulus --inifile <pathtomyini> --port 50001 --enableipv6 --clientname Guitar --store
In which case Jamulus will immediately return with:
Now each time you just run Jamulus with: Jamulus --inifile <pathtomyini>
Jamulus will use the stored commandline parameters as if they where given on the commandline.
To clear the stored parameters again just run Jamulus with --store and no other parameters: Jamulus --inifile <pathtomyini> --store
Which will return with: Jamulus: Stored commandline options cleared.
P.S.:
Only valid parameters can be stored. (Jamulus will exit with an error on invalid parameters.)
The only parameters that won't be stored (long or short names of coarse) are: --help --version (On which Jamulus will exit immediately with the info anyway.) --inifile (Since this one is needed to know where to store/recall.) --server --nogui (Since these define the startup mode of Jamulus and so also the valid parameters.) --store (obvious.)
I will open a issue or PR for this as soon as my other PR's on messages, commandline options and exception handling are merged, since this new settings and commandline implementation depends on all of them.
Yeah, there has been a lot of discussion about the ini file writing feature. Volker disliked headless servers having a config file while I think pljones was supporting them. I think it's a step in the right direction.
Activity
jp8 commentedon Aug 27, 2021
The IPv6 pull request is #1938.
I plan to propose a re-arrangement of the settings dialog, splitting the controls into the following 3 tabs:
I could add the button during that effort, but I wasn't planning to look at it until after 3.8.1
ann0see commentedon Aug 31, 2021
I assume that's up to others (= separate issue). Please keep #1343 (reply in thread) in mind!
jp8 commentedon Sep 1, 2021
Good point - I'll definitely make a strong justification for any UI changes I propose.... and then see what others think.
For this button, I would say leaving it as a command line option in 3.8.1 would give a nice chance for technical users to test the functionality thoroughly, before the more 'casual' users see it in the UI in 3.8.2
ann0see commentedon Sep 1, 2021
Ok. So un-tagging this for the next release.
gilgongo commentedon Nov 7, 2021
Minor point, but rather than a button, I would think this would be a checkbox to toggle IPv6 on or off (so
[ ] IPv6
basically)pljones commentedon Nov 7, 2021
Looking at the existing start up code (I've started on a rewrite of how settings are handled), it would currently need a restart of the application to get this working, as the socket is created and bound once when the Client or Server start up.
You wouldn't want to do it in the middle of a jam, either. Doing the network renegotiation would break things up.
So even if it were in the GUI, it wouldn't have any noticeable effect until the application was restarted. That could be confusing for people.
(Currently, each "connection" (a Channel) gets passed the same Socket instance to use. The Server must have the Socket without any connections, in order to work at all, of course.)
gilgongo commentedon Nov 7, 2021
@pljones I think the convention there is usually to have some text next to the checkbox control. So:
[ ] IPv6 (requires restart)
And leave the user to take the action as they see fit.
pljones commentedon Nov 7, 2021
OK, my rewrite of the start up will help, anyway. Currently, reading Settings requires the Client or Server to have been created, which means the Socket has been created and it's too late to use whatever was in the Settings. I'm hoping to get all the defaults, settings and command line processing done before creating the Client or Server...
ann0see commentedon Apr 23, 2022
Un-Tagged since I don't think the redesign is finished for the upcoming release.
pgScorpio commentedon May 6, 2022
@ann0see
I have some rework on commandline options and settings handling in progress that would allow you to store most commandline parameters in the ini file. I think that that would also solve this problem.
In this case the general idea would be to run Jamulus with a
--store
parameter once. i.e.:Jamulus --inifile <pathtomyini> --port 50001 --enableipv6 --clientname Guitar --store
In which case Jamulus will immediately return with:
Now each time you just run Jamulus with:
Jamulus --inifile <pathtomyini>
Jamulus will use the stored commandline parameters as if they where given on the commandline.
To clear the stored parameters again just run Jamulus with
--store
and no other parameters:Jamulus --inifile <pathtomyini> --store
Which will return with:
Jamulus: Stored commandline options cleared.
P.S.:
Only valid parameters can be stored. (Jamulus will exit with an error on invalid parameters.)
The only parameters that won't be stored (long or short names of coarse) are:
--help --version
(On which Jamulus will exit immediately with the info anyway.)--inifile
(Since this one is needed to know where to store/recall.)--server --nogui
(Since these define the startup mode of Jamulus and so also the valid parameters.)--store
(obvious.)I will open a issue or PR for this as soon as my other PR's on messages, commandline options and exception handling are merged, since this new settings and commandline implementation depends on all of them.
ann0see commentedon May 6, 2022
Yeah, there has been a lot of discussion about the ini file writing feature. Volker disliked headless servers having a config file while I think pljones was supporting them. I think it's a step in the right direction.
pljones commentedon Aug 29, 2022
Moving as notabug.
pljones commentedon Apr 19, 2023
Dropping milestone and back to Triage until someone picks the work up.