GNOME Bugzilla – Bug 376101
Support pre-conditions on settings
Last modified: 2011-07-06 06:41:17 UTC
Allow a call to new* in AEState.getSettings to take a callable (lambda, function, method, whatever) which will act as a pre-condition for enabling configuration of the setting. To make this work, the pre-condition must be invoked when any of the other settings in the pre-condition change value. This requires some grouping of the setting object, the pre-condition callable, and the widget representing the setting as observers on the variables listed in the pre-condition. Sounds icky, but shouldn't be too hard.
Created attachment 77367 [details] [review] Proposed fix This patch depends upon the patch in bug 358183. It adds a 'sensitive' attribute to the SettingEvent which could be called from a Perk via Task.Tools.System.signalSetting, and have the sensitvity of a setting changed and displayed in a chooser. It also adds sensitive/insensitive information to a State object that is not persisted.
I think I'd like to hold off on a solution to this problem until we refactor how the AEState class works with respect to settings and its attributes. The more we build on top of the current structure, the more we'll have to change later. Plus, I think the solution will be much more elegant once we solve bug #381323.
Eitan, Can you set a whole group of controls in gtk to senstive=False by setting their "container" to insensitive? Can you find out for me? I'd like to know if we'll need to be registering preconditions on individual settings widgets or if can do a whole group at once.
Yes, I am pretty sure that is possible. If a container widget is insensitive, all of it's children are too.
Marking patch obsolete now that bug #381323 is complete. I think the new callback system on state changes helps us solve this bug with some additions. Here's one idea: 1) The author of a State/Style object creates settings like usual. 2) The author also defines methods in the state/style object and registers them as observers for value changes on settings that are part of the precondition for enabling user configuration of a particular setting. 3) The settings dialog registers for notification of state changes on all settings (e.g. enabled/disabled). 3) When a setting changes value, the callback method on the state object is invoked. It computes the precondition and enables/disables all affected settings. 4) Enabling/disabling generates a separate callback to observers of state changes (i.e. the settings dialog). 5) The settings dialog makes the appropriate widgets sensitive/insensitive. Extensions needed: 1) Support for state notifications in addition to value notifications. Right now, we only do value. Seems like we could extend addObserver in the Setting class to take a constant meaning "value" or "state." Alternatively, we could refactor into addValueObserver and addStateObserver. 2) Enabled/disabled attribute on all settings. 3) Settings chooser needs to register for state changes and act appropriately. I do not think that a setting in disabled state should reject programmatic value changes. If, for instance, the magnifier perk wants to change one of its settings while the magnifier enabled setting is False, it should be allowed to do so. Only the user should be prevented from playing with the configuration.
lsr (Linux Screen reader) development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.