In PreferencesPage, we have this block of code that synchronizes changes on the PreferencesPage with the underlying Preferences:
|
def _anytrait_changed(self, trait_name, old, new): |
|
"""Static trait change handler. |
|
|
|
This is an important override! In the base-class when a trait is |
|
changed the preferences node is updated too. Here, we stop that from |
|
happening and just make a note of what changes have been made. The |
|
preferences node gets updated when the 'apply' method is called. |
|
|
|
""" |
|
|
|
# If the trait was a list or dict '_items' trait then just treat it as |
|
# if the entire list or dict was changed. |
|
if trait_name.endswith("_items"): |
|
trait_name = trait_name[:-6] |
|
if self._is_preference_trait(trait_name): |
|
self._changed[trait_name] = getattr(self, trait_name) |
|
|
|
elif self._is_preference_trait(trait_name): |
|
self._changed[trait_name] = new |
|
|
#196 makes the PreferencesHelper (the base class of PreferencesPage) consistent in the handling of _items trait: It is assumed to be the event trait for listening to list/dict/set mutations.
This means one cannot have a trait that is actually named *_items and have it synchronized:
class MyPreferencesPage(PreferencesPage):
name_items = Str()
If this cannot be supported, we should document it and perhaps emit a warning when the trait is skipped.
In PreferencesPage, we have this block of code that synchronizes changes on the PreferencesPage with the underlying Preferences:
apptools/apptools/preferences/ui/preferences_page.py
Lines 66 to 85 in d755bf1
#196 makes the PreferencesHelper (the base class of
PreferencesPage) consistent in the handling of_itemstrait: It is assumed to be the event trait for listening to list/dict/set mutations.This means one cannot have a trait that is actually named
*_itemsand have it synchronized:If this cannot be supported, we should document it and perhaps emit a warning when the trait is skipped.