add ability to specify name for tk.OptionMenu and ttk.OptionMenu

[kurawlefaraaz]

Feature or enhancement

Proposal:

In current implementation of tk.OptionMenu and ttk.OptionMenu, we can not specify name to them since adding additional kwargs raises unknown option error

Since after initialization of widget name cannot be changed, hence we cannot specify custom name such as games_option_menu etc to the OptionMenu.

Ability to specify name to a widget is very handy, since it helps programmer to easily gain access to widget between diffrent scopes and this ability is lacking in OptionMenu widget.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-130482: Add ability to specify name for tkinter.OptionMenu and tkinter.ttk.OptionMenu #130502

[serhiy-storchaka]

This is a worthy idea.

[Xiaokang2022]

@kurawlefaraaz

I tried to implement this new feature and created a PR linking to this issue.

However, I found that the inability to use the parameter name is actually caused by missing the parameter when passing the parameters, which means that there may be other similar parameters that are missing in addition to the parameter name.

Maybe we need to think about creating a new issue to add all the missing parameters compared to other widgets. (e.g. font) Of course, it's possible that not all of the missing parameters are suitable for this widget.

[kurawlefaraaz]

@Xiaokang2022 , there is a workaround for other parameters like font that is it can be changed using .configure() method, but name option can not be changed once the widget is initialized. So name option is more serious problem here.

[serhiy-storchaka]

Initially, tkinter.OptionMenu was implemented as a thin wrapper around the tk_optionMenu command:

tk_optionMenu pathName varName value ?value value ...?

Later, it was reimplemented in Python to make the generated menu accessible as the Menu object. Later, support of the optional keyword argument command was added. This is the only difference from the original tk_optionMenu wrapper.

You can specify all arguments for tk_optionMenu, except pathName. The part of it is specified as master, but the last component is generated, and the user cannot affect this. In all other widgets the last component of the path is usually generated, but user can override this be explicitly passing the keyword argument name.

This is why I think that the proposed idea is reasonable.