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

Unselecting "Use system proxy settings" in Preferences provides no user interface for application-specific proxy settings #9018

Closed
cyberduck opened this issue Sep 17, 2015 · 6 comments

Comments

@cyberduck
Copy link
Collaborator

a4e743b created the issue

If you select "Use system proxy settings" in Cyberduck preferences, and then click the "Change settings..." button, System Preferences is opened to the Network preferences panel, to the Proxies tab in the Advanced settings for the default adapter. This behavior makes sense.

But if you unselect "Use system proxy settings" in Cyberduck preferences, and then click the "Change settings..." button, the button event handler does the same thing. I would have expected a Cyberduck provided UI for making Cyberduck-specific proxy settings, or perhaps unselecting the checkbox would replace the button with a bunch of text fields similar to what the System Prefs' NPP Proxies tab presents.

(This seems to be a defect insofar as the expected behavior seems absent. But I suppose this could be an enhancement.)

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Duplicate for #5815. We are very reluctant to duplicate functionality already provided by the system thus duplicating efforts and bugs. Also, proxy settings should affect all installed applications and not to be configured separately in every application.

@cyberduck
Copy link
Collaborator Author

a4e743b commented

I think the UI needs to be redesigned in that area of the Preferences window, because it is misleading. Disable the button if the checkbox is unchecked. Or at least provide a label or tool tip to explain the semantics of the controls, which are not consistent with the way that most browsers work.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:2 ducklips]:

I think the UI needs to be redesigned in that area of the Preferences window, because it is misleading. Disable the button if the checkbox is unchecked.

Disabling the button would certainly make sense.

@cyberduck
Copy link
Collaborator Author

a4e743b commented

Thinking about this a bit more this morning, the user expectation problem stems from the ambiguity of what the unchecked state actually maps to. This could be resolved by replacing the checkbox with a radio button group (which is much more congruent with the way these options are presented in Seamonkey / Firefox / etc.) so that the states are clear. I would think the labels would be:

  • Use system proxy settings (and put the button next to or under this radio button label, and disable it if this radio button wasn't selected)
  • Direct Connection

Just a thought...

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:4 ducklips]:

Thinking about this a bit more this morning, the user expectation problem stems from the ambiguity of what the unchecked state actually maps to. This could be resolved by replacing the checkbox with a radio button group (which is much more congruent with the way these options are presented in Seamonkey / Firefox / etc.) so that the states are clear. I would think the labels would be:

  • Use system proxy settings (and put the button next to or under this radio button label, and disable it if this radio button wasn't selected)
  • Direct Connection

Just a thought...

We use the same semantics as in Safari to change proxy settings in the network pane of System Preferences with the only difference that you can uncheck the option to ignore these settings and use a direct connection instead. A radio button would only make sense if the options are not boolean but more numerous.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 18184.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant