Table column not resizing if adding new row on runtime

[Maurosilvestricj]

Hi all, I'm posting this here because I'm not sure if I'm missing something.
As you can see from the code below (last dpg version) if you add a column via the "press me button" the column will not resize to fit the elements inside it.
In contrast if you add the row before dearpygui is started (just uncomment the relatives lines of code), the column size will perfectly fit all elements. Is this a bug, a feature request or I'm missing something?
Thanks all for the answers

import dearpygui.dearpygui as dpg

dpg.create_context()


def cb():
    with dpg.table_row(parent = "table"):
        dpg.add_text("short")
        dpg.add_text("-long")
        dpg.add_text("-----longer")


with dpg.window(label="Tutorial", width = 500):
    dpg.add_button(label = "press me", callback = cb)

    with dpg.table(tag = "table", header_row=False, width = 200, resizable=True, policy=dpg.mvTable_SizingStretchProp,
                   borders_outerH=True, borders_innerV=True, borders_outerV=True):

        dpg.add_table_column(label="Header 1")
        dpg.add_table_column(label="Header 2")
        dpg.add_table_column(label="Header 3")
        
        with dpg.table_row():
            dpg.add_text("aaa")
            dpg.add_text("bbb")
            dpg.add_text("ccc")

        # with dpg.table_row():
            # dpg.add_text("short")
            # dpg.add_text("-long")
            # dpg.add_text("-----longer")

dpg.create_viewport(title='Custom Title', width=800, height=600)
dpg.setup_dearpygui()
dpg.show_viewport()
dpg.start_dearpygui()
dpg.destroy_context()

[iankona]

You can try it，delete "resizable=True" or modify "resizable=False"

with dpg.table(tag = "table", header_row=False, width = 200, resizable=False,

[Maurosilvestricj]

Hi and thanks for the answer!

It actually works as expected but I will obviously lose the possibility to manually resize the columns. I'd like to keep this possibility. Any other idea?

[iankona]

I usually deal with it like this：

def cb():
    dpg.configure_item("table", resizable=False)
    with dpg.table_row(parent = "table"):
        dpg.add_text("short")
        dpg.add_text("-long")
        dpg.add_text("-----longer------------")

def cc():
    dpg.configure_item("table", resizable=True, width = 300 )

with dpg.window(label="Tutorial", width = 500):
    dpg.add_button(label = "press me", callback = cb)
    dpg.add_button(label = "table resizable", callback = cc)
    with dpg.table(tag = "table", resizable=True):
        pass

[Maurosilvestricj]

Thanks! Apparently this worked for me.
Anyway I think this is some sort of bug should we signal this to developpers?

[iankona]

Google Translate

I have been thinking about this problem for a while, and I think it is not a bug.

You can check the issues to see if there are similar proposals. If not, you can create a new proposal and describe clearly the features you want.
Now the dearpygui architecture has been built, and various controls are being written.

The first UI I used is tkinter, and the commonly used control is treeview, which is object-oriented, and treeview has a function of hiding rows.
dearpygui is different, it is not object-oriented, the documentation mentions that it belongs to immediate mode.
Very early, my understanding of it was limited to dearpygui that can call the graphics card, but the details of it are actually vague.
When I used dearpygui to write my own treeview control and realized the function of hiding rows, I understood the huge difference between immediate mode and object-oriented mode.

The following is my personal understanding:
Dearpygui is data-oriented. It is expected to have a unified structure data structure, which is similar to python's attributes. At the same time, it manages thousands of structures. Managing structures through tags is the design philosophy of dearpygui.

The rendering algorithm presents different images according to the different attributes of each structure. Most of the methods for processing the attributes of the structure are hidden from python.

My understanding of dearpygui comes from 2 functions, 1 stage:

self.stage = dpg.add_stage()
self.table = dpg.add_table()
dpg.configure_item(tag=item, parent=fitem)
dpg.move_item(tag=item, parent=fitem)

To realize the function of hiding the row is actually to change the parent of the row, and the difference between them is reflected here.

dpg.configure_item(tag=row_item, parent=self.stage) # This change is very, very fast, but the display has not changed, indicating that only the structure has been changed
dpg.move_item(tag=row_item, parent=self.stage) 
dpg.move_item(tag=row_item, parent=self.table) # This change is very slow, and the corresponding interface is automatically changed, indicating that the structure is changed and the rendering algorithm is also called

Cooperate

dpg.reorder_items(self.table, slot=1, new_rows) # The order of display of sorted rows

These 3 functions are considered to be one of the few low-level functions of dearpygui, reflecting the design ideas of dearpygui.
The others are basically controls, and set the value of the structure.

So after understanding this idea, you can basically understand the various controls of dearpygui, the boundary between what can be done and what can not be done.

dearpygui also has a lower-level draw series pythonAPI, but it means that it takes a lot of time to write the calculation of the size and position algorithm of the shape, as well as the animation algorithm, so I didn’t understand it in depth.

At first, I wanted to implement the function of hiding rows by inheriting the form of the table object, and then overloading the row display algorithm, which was obviously inappropriate for dearpygui. dearpygui did not present the algorithm for displaying rows to python.

I didn't learn C++.

What I want is to speed up dpg.move_item(), which is still too slow for the parent update of thousands of dearpygui structures.
This is difficult. The simple optimization understanding is to not render first, and then render after the parent and display order list is adjusted. Optimizing the move_item() prediction for the table does not match the architecture of dearpygui. Obviously, it needs to write a special optimized dpg.move_item() function for the table, which is a biased object-oriented processing.

A first tip

Before your own control, call demo.show_demo(),
After calling your own control, call the dpg.move_item() function, and you will see changes in the details of the operation of dpg.move_item() on the display.

A second tip

The dearpygui.demo has a lot of code.

[Maurosilvestricj]

Again thanks for tour detailed answer. As a matter of fact I wasn't able to undestand the most part of It. This Is of course due to my incompetence. My basic knowledge of programming (and python) comes from the famous book "automate the Boring stuff with python" which I read about 3 years ago. Since then I sometimes programmed something and of course my practical knowledge and know-how improved a lot. Nonetheless I'm still pretty lacking from a teoretical standpoint. I'm now writing a python programm which atm counts about 2000 Lines of code, which is a big deal for me. In conclusion, I again thanks you for your answers and surely trust you when you Say it's not a bug. Also I'm adding "programming theory 101" to my to-do list.