mirror of
https://github.com/ocornut/imgui.git
synced 2026-11-10 19:03:30 +00:00
Column headers #513
Labels
No labels
accidentally closed
android
backends
bug
building
clipper
coloredit
color spaces
cplusplus
data types
demo
disabled
doc
docking
dpi
drag drop
drawing/drawlist
dropped
dx12
enhancement
focus
font/text
gallery
help wanted
idle/power saving
ime
in progress
inputs
inputtext
internals
label/id and id stack
language bindings
layout
linux/bsd
menus
multi-contexts
multi-threading
multi-viewports
nav
news/info
opengl
optimization
osx/ios
overlap
plot/graph
popups
question
scrolling
selection
settings
sliders/drags
style
tables/columns
tabs
test wanted
tools
tooltips
tree
tricks & tips
useful widgets
vulkan
web
window pos/depth
window sizing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ocornut/imgui#513
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello,
In case you are creating tables with lot of columns, here is a short code snippet to quickly manage the column headers :
I'm wondering if there is a simple way to make the headers "fixed", like in Excel when the top row is fixed ?
Because you obviously want to see the headers while scrolling in your table.
Thx
A more elaborate code snippet for headers.
If you put a negative column-width, the width is calculated according to the column's label.
There is a flag (makeColumsWidthFixed) to set column widths every frames or only the first time.
Ok, after 1 coffee (I'm sick today...), here is a cleaner helper for column headers.
Considering you have two user files imgui_user.h and imgui_user.inl, here is the code for the helper :
In imgui_user.h :
In imgui_user.inl :
And the code you put in your GUI :
Ok, the "s_firstTime" flag could be handled internally the same way it is done for window's sizing... But I'm sick today...
I'm still wondering how to make the column-headers fixed (like a top row in excel).
Anyone has an idea ?
Thanks. We may want to use that for inspiration as the columns API develops.
Linking to https://github.com/ocornut/imgui/issues/125 where older columns discussions happened.
My feeling is that we should introduce full-featured BeginColumns() / EndColumns() - (old Api Columns() can stay) so it is good to identify the different needs it may have and how those parameters would fit.
To answer your question, it can be done by duplicating the column set outside and inside a child window, but the columns offset needs to be synchronized across two sets. It's possible right now but a bit messy - figuring out minor offsetting issues due to child window padding and the presence of a scrollbar. That's the sort of thing that once we figure out we should include as part of a helper, maybe BeginColumns()/EndColumns(), so it's good to experiment with it.
Some other consideration: (some of them are discussed in #125)
We don't need all those features ready but I want to be confident that we can tackle all of them properly before introducing a new BeginColumns() api. So any research in those area is useful.
PS: You don't have to user imgui_user files anyway since you can include
imgui_internal.hand have access to the most of the no-warantee-given innards there.Ok, I followed your advice, and it works pretty well when syncing both set of columns.
imgui_user.h :
imgui_user.inl :
And the usage becomes a lot easier :
Here is a capture of a test :

The only 2 things I still dislike is :
But these artefacts are acceptable.
Ok.
Next, I would like to handle the double-click on a column-bar in order to resize the column to come back to its original size (same than Excel).
Any ideas about that ? (I'm not very familiar with ImGUI inputs... sorry)
That fix is definitively desirable. We should definitively find a way to fix that. However, when using headers it may also be acceptable to restrict resizing to the headers section only and then it's easy to solve.
That's also something that could be considered as part of the "how do we express the column width". Your current system has width values (or -1) only, perhaps columns can be marked as "use remaining space" or have a finer way to express the constraints. Again this needs a little research. Note that I currently store width as % of the total width to handle this sort of thing in the basic.
That interaction is currently handled in Columns()
This ties with my earlier comment "allowing the user to create finer interaction with columns header, perhaps add a context menu, might lead to an api more consistent with other ImGui where headers are declared one by one instead of packed into a table.". We either need to code in this feature in that code, either expose the interaction somehow. If we have an api were columns are declared separately, it'd be easier to allow for the user to handle custom interactions.
Lots of open problems, thanks for trying those things. It is worth pushing those problems for now, and then we can design better api that would handle all/most of them properly.
Minor tips:
Disabling the sync from bottom to top Columns solves both issues : no more lag (obviously), and when resizing the window all the columns follow the sizes of the top ones.
So, everything is quite good.
But, there is a new behaviour not really appealing : the bottom columns are still draggable, and when I drag one of them it takes back its place when drag-event ends (same place than the top-column).
I'll look at a way to disable dragging for bottom-columns only.
Thanks for the AlignFirstTextHeightToWidgets() tip ! I didn't see the misalignment at all, too much focused on the columns !
I had to put this call before every text fields of a single line to make them Venter-aligned, as if the NextColumn() is resetting the context.
Great that you gave me the tip for clipping, because that would have been my next question :)
Mmmh... The clipper has side effects : the first line is not correctly detected, and when I scroll by dragging the scrollbar it is flickering. I'll look at what is wrong with it..
Edit : I found that issue #512 may be related.
You probably aren't passing the right height for your items. There is a helper that gives you
FontSize + ItemSpacing.y + FramePadding.y*2If you aren't sure of your height try seeking position +1 manually (using SetCursorPosY()) when eg. io.KeyCtrl is held for an easy comparison.
Here are the sources from yesterday evening (yes, I discovered Gist... ah ah) :
imgui_column_headers.h : https://gist.github.com/itamago/27f09c429d625a0d31ec
imgui_column_headers.cpp : https://gist.github.com/itamago/f297dee5788c4d9b9441
imgui_column_headers_usage.cpp : https://gist.github.com/itamago/7b305ee9aaf31843b8d1
Works quite well.
In the following capture, you will recognise the wip color-picker :

Having ideas lot more clear than yesterday (no more fever), I have some questions which may be totally newbie ones...
Sorry if they are newbie question, and I would totally understand that I should more carefully RTFM, but I'm still sick lol :)
Thanks. We should aim to make all this code invisible eventually.
I am wondering if the performances are holding up with so much columns switches. In particular NextColumn() does a PopClipRect()/PushColumnClipRect() which will always end up in a merged command, I think with recent changes to ImDrawList I should be able to remove those calls and only do them once at the begining/end of the set. Same for PushItemWidth which ideally should be preserved on a per-column basis. It's all fairly small/fast stuff but it may add up when you are drawing thousands of calls. Hope to remove those 4 calls from NextColumns() at least.
Typically I wouldn't even use so many columns, note how most of your elements don't really need to be resized. I'm always a little concerned when people try to push ImGui in a direction of trying to mimic well known UI systems and losing on the usage simplicity benefits of ImGui.. You can't turn a blind eye on the core design/benefits/limitations of ImGui and expect mimic to happen. You may end up disappointed!
I am not sure I want to turn ImGui into pretty-face options because that would defeat lots of its benefits. And frankly I don't have sufficient bandwidth to handle it, every micro visual decision has side-effects on code and performance (if I had the time I would consider finding the best spot between those two opposites).
You can't, or you set the position yourself.
You can't, and yes it'd be pretty simple to change. Probably best set within the Style?
Adding the flag to ButtonEx() would also work but maybe give too much importance to that feature.
I plan to try to finish it and get it working first, I haven't figured out how to parametrize it yet.
There is a font scale but the best way is to bake a smaller font and call PushFont.
You're right, I need only 4 columns (and 2 resizable only).
I created so much columns to benchmark the API, and ImGui is pretty fast :)
Thanks for your advices, I will implement that tomorrow !
I did a test by reducing from 13 columns to only 4. The widgets were the same, and I kept row-clipping disabled in order to maximise the number of vertices.
The gain is negligible :
It means that Columns have a very low overhead, that's great :)
Updated source code for column-headers, making them more configurable and easier to manage :
imgui_column_headers.h : https://gist.github.com/itamago/27f09c429d625a0d31ec
imgui_column_headers.cpp : https://gist.github.com/itamago/f297dee5788c4d9b9441
imgui_column_headers_usage.cpp : https://gist.github.com/itamago/7b305ee9aaf31843b8d1
Nothing new on this topic, so I close it.
Lots of ideas to filter and process. We still need official columns headers, etc. I'd rather keep topics open when they talk about stuff that I intend to do!
Hey there, simplified header-only snippet because I wanted it shorter and more ImGui styled.
Thank you very much to both of you :)
Hello, there is a severe bug when the window hosting the control is resized, the columns lose spacing and its not possibile to reset to their original size.
@v71
With which code? Please provide a repro.
With the code from r-lyeh , i basically copy pasted into a plain window and it showed the problem as soon as i resized the window, it takes 30 seconds to reproduce, i do not have a gif encoder in this computer right now.
This code doesn't seem to work with latest ImGUI. In the case of the header-only snippet I can use
ImGui::BeginColumns(str_id,count,ImGuiColumnsFlags_NoPreserveWidths)but that keeps it to header-only resizing.Hello @itamago and all,
As the official Tables API is looming in, I'm closing this old topic about recreating headers with the Columns API.
Thanks for the idea and suggestion discussed here :)
Tables API now merged in master.