> On Aug 14, 2015, at 7:48 AM, Terry Reedy <tjre...@udel.edu> 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.
At this point it’s not about i18n or anything ambitious, just one place to
centralize the “do I use classic- or ttk-flavoured versions of this dialog?”
for large components, not individual widgets. Plus keeping track of these
various non-editor windows, which becomes an issue as some of them change to
modeless. So rather than an EditorWindow instantiating the preferences dialog
directly, it would ask the uifactory to do so. While there will inevitably be a
bit of that "call a method to call a method to call a method to… actually get
work done", I’ll do my best to minimize that!
Moving to a central string table so the interface could be localized would be
great. Later. ;-)
> * 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.
I’m all for incorporating the optional extensions. By disabling here though I
was referring to things like a ‘Copy’ menu item being disabled (inactive) if no
text is selected in the active editor, etc.
Mark
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
