The tasks PreferencesDialog should support disabling the 'OK' button

[itziakos]

The PreferencesDialog will call apply on all the preference panes when 'OK" is pressed. However some times it is useful to be able to veto closing the dialog because the current settings in a pane are invalid or partial

I think that one way of having this behavior is if each PreferencePane has a veto_apply Boolean trait that the PreferencesDialog can monitor to make a decision on closing the window and enabling/disabling the 'OK' button.

[pankajp]

I don't think this is a good feature to encourage. Many preference systems (notably on Mac and Gnome) do not have "Apply/OK" action, and the preferences are live and the ui (preference panes) is expected to not let the user enter an invalid state (or indicate it as such - for example proxy setting won't be used because port number is not specified).

[itziakos]

Many preference systems (notably on Mac and Gnome) do not have "Apply/OK" action, and the preferences are live and the ui (preference panes) is expected to not let the user enter an invalid state (or indicate it as such - for example proxy setting won't be used because port number is not specified).

I think that this generally depends on the application. For example on Mac the network setting will show Revert and Apply buttons which will be enabled/disabled based on the settings that the user has used (e.g. Revert will be disabled if the user has not changed any settings). Specifically for the proxy settings there are 'OK' and 'Cancel' buttons.

The PreferencePanes in the tasks sub-package are designed to keep a temporary copy of the preferences which can be discarded or applied (become permanent). The current implementation of the PreferencesDialog will show 'OK' and 'Cancel' in all platforms. 'OK' will call apply on all the managed preference panes.

I agree that in general all settings should be validated automatically however it is not always possible for the validation to be instant. In some cases the application needs to perform a number of tasks and checks to validate the provided settings (e.g. network settings). Given the current implementation of the PreferencesDialog, the user is able to close the dialog and force the un-validated settings to become permenent. I think it is better UX experience to have a simple way to tell the user that the changes have not been validated yet and give the opportunity to correct if necessary.