On 8/13/2015 2:21 PM, Mark Roseman wrote:
* (patch done) centralize creation of ui components in a new ‘uifactory’ module. This is now used by about/prefs (#24760), and soon others. This module will also be in charge of choosing to use ‘ttk’ or ‘non-ttk’ based components (#24759)
Because menu creation is mostly 'data' driven, with a hierarchical structure, it will be relatively easy to collect and translate the strings in the menu ('File', 'Open', etc) for i18n without wrapping each literal string with _(...). If other UIs were similarly data driven, rather than code-driven as now, i18n for other UIs would be similarly easy. So I am curious as to your approach.
* menu handling, in particular enabling/disabling items according to app state (#24814 etc.)
I think most of the features currently implemented as 'optional extensions' should be incorporated as always present features and the disable option removed. Their menu entries would then be moved into the main menudefs in bindings.py. If it becomes easy to disable or even remove menu entries for disabled features, then we could move *all* main menu menudefs into bindings.menudefs.
-- Terry Jan Reedy _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
