PushStyleColor and some other push/pop methods

[supudo]

Hey :)

Another batch - Includes PopStyleColor with the flags and some other push/pop utils.

Cheers,
S.

[swistakm]

Sorry, I did not notice that you have included missing flag descriptions in this PR and I have introduced a conflict by fixing this in master branch. Can you rebase your branch so I will be able to merge through GitHub UI? Also we will see if tests pass.

[supudo]

Resolved it via the web interface, let's see if i got it right.

S.

[swistakm]

Two syntax issues.

[swistakm]

broken definition (extra newline)

[swistakm]

Oh, now i see that it should be simply push_style_var

[swistakm]

missing colon

[supudo]

I'm gonna wait for any new changes until i resolve all those git issue and everything is good and merged :)

S.

[swistakm]

Additional improvement ideas

[swistakm]

We could add something that ensures variable<ImGuiCol_COUNT and raises ValueError otherwise. See: push_style_var().

[swistakm]

It is not in the core lib but we could add default alpha value for users wanting to use the rgb-only tuples.

[swistakm]

Oh, now i see that it should be simply push_style_var

[swistakm]

OK. Let's wait until you fix your git issues.

Now I have idea that we could also add some more extra context managers similar to the styled function, so we won't have to manually do color/wrapping/width pops and pushes. But maybe let's leave it as a separate issue to solve because I would like to have a consistent naming of such context managers and now I'm not sure if styled/istyled are good names. For color it is not a problem because we can have colored/icolored. Item width is more problematic. Also the i suffix may not be intuitive enough. I wonder if the following api would be better:

• style/styles,
• color/colors
• item_width

Also we may want to move all extra utility functions and context managers to the separate module. The core.pyx file is already huge.

[supudo]

Fixes are pushed.

Not sure how it will fit the general idea of the API, but we could split as you said the public functions and the utilities, so that all functions that are usable by a user like begin(), combo(), etc. are in one file and the rest of the stuff like wrappers and helper function in another. This will break a bit the ImGui general architecture and porting, but might be better when used as source code.

Cheers,
S.

[coveralls]

Coverage increased (+3.1%) to 43.375% when pulling 61d1a1c on supudo:StylesUtils into eeb616b on swistakm:master.

[swistakm]

Oh I was referring only to these functions:

styled(cimgui.ImGuiStyleVar variable, value)
istyled(*variables_and_values)
vertex_buffer_vertex_pos_offset()
vertex_buffer_vertex_uv_offset()
vertex_buffer_vertex_col_offset()
vertex_buffer_vertex_size()
index_buffer_index_size()

These functions are not the part of core C++ library. They are just some extra utilities or high level interfaces that are meant to make working with imgui easier and/or more pythonic. If we had some extra module for such utilities we could e.g. add more utilities to make some tedious C-style convetions more "pythonic".

For instance the:

if imgui.begin_menu('File', True):
    imgui.menu_item('New', 'Ctrl+N', False, True)
    imgui.menu_item('Open ...', 'Ctrl+O', False, True)

    if imgui.begin_menu('Open Recent', True):
        imgui.menu_item('doc.txt', None, False, True)
        imgui.end_menu()

    imgui.end_menu()

Could be:

with imgui.menu('File', True):
    imgui.menu_item('New', 'Ctrl+N', False, True)
    imgui.menu_item('Open ...', 'Ctrl+O', False, True)

    with imgui.menu('Open Recent', True):
        imgui.menu_item('doc.txt', None, False, True)

Such approach makes the code shorter, more readable and less error prone. I'm not a fan of complex package and module hierarchies and definitely don't want to split any of C++ mapping module. The content of such "extra" submodule would be of course imported in imgui/__init__.py so from the user's perspective nothing will change. We will at least separate the core mapping code from anything extra we would like to add.