Skip to content
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

Normal shell for --no-gui mode? #637

Open
ghost opened this issue Oct 14, 2023 · 4 comments
Open

Normal shell for --no-gui mode? #637

ghost opened this issue Oct 14, 2023 · 4 comments
Assignees

Comments

@ghost
Copy link

ghost commented Oct 14, 2023

No description provided.

@Et0h
Copy link
Contributor

Et0h commented Oct 14, 2023

What is the difference between a normal shell and the shell used for SyncplayConsole.exe in Syncplay 1.7.1 RC1?

@ghost
Copy link
Author

ghost commented Oct 14, 2023

What is the difference between a normal shell and the shell used for SyncplayConsole.exe in Syncplay 1.7.1 RC1?

So, I'm using syncplay-1.7.0-1 on ArchLinux and offer the following notes:

  1. Separate activity log and shell prompt as this interrupts command input.
  2. Make a "/" prefix for commands, as is implemented in other applications: weechat, profanity, gajim, etc.
  3. Following point 2, the "ch" command is not needed, since the commands begin with a prefix.
  4. And autocomplete commands using TAB as is done in Bash.

@daniel-123
Copy link
Contributor

To me this looks like a feature request and a significant change to how the interactive console UI works. Personally I'm not convinced this is particularly useful outside of TAB completion, but I also don't use the console UI on regular basis. So I'd probably want to see some information gathered from people who actually do and what they would think about this.

If we were to ignore forcing an UI change on everybody using console, I think the above suggestions are quite reasonable.

@Et0h
Copy link
Contributor

Et0h commented Oct 20, 2023

Separate activity log and shell prompt as this interrupts command input.
Make a "/" prefix for commands, as is implemented in other applications: weechat, profanity, gajim, etc.
Following point 2, the "ch" command is not needed, since the commands begin with a prefix.
And autocomplete commands using TAB as is done in Bash.

What is the difference between a normal shell and the shell used for SyncplayConsole.exe in Syncplay 1.7.1 RC1?

So, I'm using syncplay-1.7.0-1 on ArchLinux and offer the following notes:

  1. Separate activity log and shell prompt as this interrupts command input.

Is this accomplished by #638 ?

  1. Make a "/" prefix for commands, as is implemented in other applications: weechat, profanity, gajim, etc.

Using / is how it works for doing commands from within the Syncplay UI chat window and within mpv.
As such, there could be something to be said to change this for consistency with other Syncplay behaviour.

HOWEVER, I don't use the console UI and so wouldn't want to make a change to what has been established behaviour since Syncplay launched in 2012. Not everyone uses chat, and those that do can just use the built-in chat for mpv. As such, there could be a sizable number of people who like the current behaviour, and we would then need to educate them in the change as well.

Maybe a compromise would be to have a command line switch to make it chat by default and require / for commands. If there was a strong demand for such a feature then I wouldn't personally have anything against someone volunteering to develop and maintain that command line switch and its functionality.

  1. Following point 2, the "ch" command is not needed, since the commands begin with a prefix.
  2. And autocomplete commands using TAB as is done in Bash.

Autocomplete sounds like it could be a pain to implement/maintain and would add to the complexity of the Syncplay software, and again it would be a change of behaviour (that might not work on all operating systems). Those who want a convenient UI can just use the GUI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants