mvStyleVar_ItemSpacing shows results that exceed expectations

[nehonpa]

Dear PyGui version:

2.3.1

Python version:

3.10.8

Operating system:

windows 11

My issue/question:

When adjusting the spacing of the sub-window, I found that, in addition to adjusting the styles within the sub-controls, it even pulled apart from the next control at the same level, which seemed unreasonable to me. My expected idea is that it will only apply to subclass controls.

Steps to reproduce:

1.run code
2.see child_window

Expected behavior:

I think it should only apply to subclasses.

Screenshots:

Standalone, minimal, complete and verifiable example:

import time

import dearpygui.dearpygui as dpg

dpg.create_context()

with dpg.theme(tag="theme_子窗口"):
    with dpg.theme_component(dpg.mvAll):
        dpg.add_theme_style(dpg.mvStyleVar_ItemSpacing, 8, 72, category=0)


with dpg.window(tag='窗口', width=793, height=500):
    with dpg.child_window(label='1', tag='子窗口', height=223):
        dpg.add_text(default_value='123', tag='纯文本')

        dpg.add_text(default_value='123', tag='纯文本_(1)')

        dpg.add_text(default_value='123', tag='纯文本_(2)')

        dpg.add_text(default_value='123', tag='纯文本_(3)')

        dpg.add_text(default_value='123', tag='纯文本_(4)')

        dpg.add_text(default_value='123', tag='纯文本_(5)')

        dpg.add_text(default_value='123', tag='纯文本_(6)')

    dpg.bind_item_theme('子窗口', 'theme_子窗口')
    dpg.add_input_text(tag='文本输入框')

    dpg.add_button(tag='copy_普通按钮(1)')

    dpg.add_button(tag='普通按钮')

dpg.create_viewport(title='main_UI', width=819, height=555,vsync=False)
dpg.setup_dearpygui()

dpg.show_viewport()
while dpg.is_dearpygui_running():
    interval = 1 / 600
    time.sleep(interval)
    dpg.render_dearpygui_frame()

dpg.destroy_context()

[v-ein]

Good catch! While this behavior really looks unexpected, it is actually a natural side effect of how styles are applied in DPG.

Let's dig into it a bit deeper.

• You can apply styles to any widget, say, a button.
• When you bind a theme to a button, the button is colored with colors from the theme (if any), and paddings and spacing on the button are also changed by values from the theme.
  • Yep, you can say both "this button should have a frame padding of (8, 4)" (which is expected) and "this button should have a spacing to the next item of (20, 4)". The latter might be counter-intuitive as the button is not a container, but that's how styles work: padding and spacing "live at the same level".
  • As a side effect, you can change frame size on add_selectable by changing item spacing individually on that selectable - unlike buttons, selectable items render their frame with (item spacing / 2) worth of padding on top and botton (i.e. not FramePaddingY; the reason for this is that selectables often compose menus and lists and must not have highlighting gaps between them). Comes handy when you're using selectables to highlight table rows on mouse hover.
• When you bind a theme to a container, say, a child window, it also applies colors from the theme directly to the window... and paddings and spacings as well. That's why you see that large padding between the child window and the next widget (the input_text), but not between subsequent widgets (buttons).

In plain vanilla Dear ImGui, it's possible to change styles within the child window, not affecting the child window itself (as well as separately apply styles to the child window itself). In DPG, this is not supported and would actually be a non-trivial fix, not worth the effort. Styles in DPG affect the widget they are bound to. To change styles on child items only, bind the theme to a sub-container, say, a group.