-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review command arguments, cleanup, remove unused options, rename badly named options. #1461
Comments
I think it's probably not good to create files/directories in places that aren't explicitly stated with the parameter in the web docs, One of these parameters, probably
|
That's weird, that sounds more like uninitialized memory than anything else really. |
GitHub errors out even after I renamed it to "1.txt" and "1.log". The file is too big for the web services I tried to upload it to. Here are the first 20 lines (beware of GitHub's line wrapping): [ |
Maybe those were produced when no file name was specified with the old parsing. |
I hardly use the program so I can't comment much on what parameters should be. That said, I think As for the script parameters, I understand that exactly one script is loaded by default when the program starts. It makes sense to have a parameter to specify a different script, and perhaps some way of preventing any script from auto-loading. It should be made clear that the parameter controlling this applies to the script (singular) that is automatically run with the program. Am I correct in understanding that |
As far as I know hyphenated parameter names are standard on most operating systems. Camel case is a slight nuisance because it requires shifting and behaves differently depending on whether the host system is case sensitive. It's also harder to remember whether acronyms and such are supposed to be fully capitalised, whereas the hyphenated format would always be lower case. |
Some of these parameters might be more useful as application settings. For example, the parameter to use the system cursor. There might be some debug benefit to that but I think anyone who just prefers using their system cursor in general would prefer not having to specify the parameter every time they run the program. There may already be an application setting for this, I haven't checked. |
Kalila knows about a problem with at least one of the parameters. I asked her multiple times to comment here but she still hasn't so I'm leaving this as a reminder. |
Parameters to do with a "launcher" aren't going to be used unless it's relating to the server console. |
@digisomni Ok, then you're happy with this PR? Because I'd like to see it merged, it'll help with a PR I plan to submit soon. |
She also said that the "launcher" was not the same as the application launcher. She said it referred to some feature that was never implemented... |
On second thought, I still don't want to touch these without more information. I will add warnings to the |
Hello! Is this still an issue? |
There's a bunch of options to interface that are confusing, probably unused for our purposes, and badly named. We should do a review after PR #1428.
Here's an approximate list of the issues:
--allowMultipleInstances
. Some are hypenated, like--fast-heartbeat
.--scripts
,--overrideScriptsPath
and--defaultScriptOverride
.--scripts
option internally uses the variable_overrideDefaultScriptsLocation
, which may look like it's related to--overrideScriptsPath
or--defaultScriptOverride
.--cache
is "Set test cache".--traceFile
takes a filename, and places it in the documents directory.--avatarURL
and--replace-avatar-url
appear to be duplicated with a priority system. This might have fulfilled some purpose for HiFi.--clockSkew
.This doesn't need to be all fixed in one go, it probably makes sense to split it into multiple PRs and handle it over time.
The text was updated successfully, but these errors were encountered: