Replies: 8 comments
-
|
Another change, however, is to add a tag to the struct field, e.g. whether it is a table row pattern. |
Beta Was this translation helpful? Give feedback.
-
|
I will consider this. |
Beta Was this translation helpful? Give feedback.
-
I suddenly thought of another way to implement the tree table widget: use the way of combining the left tree and the right table, but when each node of the left tree is selected, in order to make the nodes and the table rows at the same height, a tree header layout is needed to match the table header so that the rows of the left tree node and the right table are always at the same height. The horizontal layout of the tree head is as follows: global search box, expand and pinch all nodes toggle buttons. What do you think of this idea? |
Beta Was this translation helpful? Give feedback.
-
|
I tried combining the tree and table widgets, but it didn't work because it didn't provide a visual picture of what the previous and the next worked https://github.com/ddkwork/golibrary/blob/master/widget/treeTable.go#L17-L103
|
Beta Was this translation helpful? Give feedback.
-
|
Also, I've found that the appbody's global default background color should be changed to black gray instead of the dark black it is now, which will help to adjust the visual style
|
Beta Was this translation helpful? Give feedback.
-
|
Your idea seems good; I can't tell from the screenshots what isn't working. You will need to have a |
Beta Was this translation helpful? Give feedback.
-
|
You can do a PR with the basic version of |
Beta Was this translation helpful? Give feedback.
-
That's great, I'll be pr soon |
Beta Was this translation helpful? Give feedback.
-
I looked at the implementation of the table widget, is there a possibility of a redesign? At present, tables rely heavily on slice display widgets, and although slice display widgets can express complex cell types, it is not easy to make changes related to table row operations and the implementation of tree table widgets becomes more complicated. If we get rid of this, the idea becomes like this: enter the structure and mark the field formatting method, the optional field tag is the column width and the field is too long to display with "...", row height and other table characteristics, and then reflect to ki, at this time we use the number of fields in the structure to represent the number of cells in the table row, and rely on the field tag to format all as label and set the text, of course, the label must be a label with extended functions, Because in more scenarios, we need cells to display icons or other graphics, and in addition, the rows drawn in this way need to support adding contextual right-click pop-up menus, and the drawing of columns can also copy this process, so that we have the function of right-clicking to copy rows or columns like Charles. Based on this process, we get rid of the current problem of inconsistent cell heights when the table rows are single or double-clicked, and it is also conducive to setting the background color uniformly, setting zebra crossings according to odd and even rows, etc. When the drawing of rows and columns becomes like this, I think the drawing idea of the tree table widget is clear, the tree table widget is actually to draw a structure that supports nesting: according to the depth calculation of the width of the blank area displayed on the left side of the level icon position to represent the level indentation, the width of the table widget minus the indent width of the position to draw the table rows, and then according to the addition, deletion, modification and query of the n fork tree to realize the global fuzzy search of the tree table widget, expand and close the nodes and other functions
Beta Was this translation helpful? Give feedback.
All reactions