mirror of
https://github.com/ocornut/imgui.git
synced 2026-11-10 19:03:30 +00:00
SeparatorText / TextSeparator / CenteredSeparator (which respects columns and SameLine) #1643
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#1643
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?
I wanted to write a decorative combined text and separator.
So, this TextSeparator can be used inside columns and respects SameLine().
There is a number of variations, and CenteredSeparator is the main function, which is obviously an edit of ImGui::Separator
The main difference between this and ImGui::Separator is that it is aligned centered vertically, and that it does not align to the edges of the window when used alone, since I haven't found a clean way to detect if it is the first element on a line.
Maybe someone will find it useful. I would love any feedback for how to make it cleaner.
Other issues discussing the topic is #759 #205 #697 - Probably more too
Hello @phed,
Thanks for submitting that. I probably won't be able to look at it in depth or comment on it for a bit but it's good to have those references and ideas posted.
And here's a GIF for reference of what your demo looks like:

Here's the same code with minor tweak to make it compatible with imgui's latest internals (your version of imgui is a little old I guess). Also
PushColumnClipRect()is declared in imgui_internal.h so you don't have to copy, but you are not using it in your code either way.Hello ocornut, Im very thankful for your excellent work.
In the latest version (v1.89.1) I noted that there are some changes in the code above (in the 'CenteredSeparator' function):
ColumnsSet -> CurrentColumns
CurrentLineHeight -> CurrLineSize.y
IndentX -> Indent.x
GroupStack -> ItemWidthStack (not sure)
@hebohang yes indeed the code, as-is, does not compile with the latest ImGui release.
@ocornut I wished this control was part of the standard ImGui as it is quite useful and seems basic, especially when it comes to creating section. I have been using pre-opened TreeNode to combine separation/header but this control replaces it hands-down.
I am definitely 👍 on this control.
Here is an example on how it significantly help with my popup menu.
Before:
After

The only thing I wished is that the line would be at least as long before and after the text (it looks a little too short after
CVIn1MaxMaxAutoResetorSelected Widgets (5)). But even with this minor visual glitch, it makes the popup menu so much nicer/easier to use.I'm going to focus on a
TextSeparator()function soon.I think we ought to have a simple function with only text parameters, and padding/centering are part of the Style structure.
My issue is that it would make sense to make it use its own color but that means associating more semantic to the widget, at which point the semantic may be more generic than a separator, and we need to know more about that in order to name things.
@ocornut I agree with you. It's better to follow the model already in place for other widgets
I implemented this now:
With text ellipsis:
Centering etc.
I probably didn't express myself clearly. My problem is that it's not easy to take the decision of how/what to present in Style and with which semantic, it has many ramifications and needs to be future-proof / forward-thinking. As with many of the style related issues that are still open, it may difficult to solve them without a more holistic approach of styling. Not being able to decide how to express those values in the style structure today means it is difficult for me to merge this widget in the code-base, but trivial for anyone to use the widget themselves.
e.g.
The control thickness. If we suggest the control is drawing a line (which is suggested by the name "Separator"), it makes sense for thickness to be expressed as an absolute size (e.g. 1~2 pixels). But if the look of the control because fatter it may make more sense for thickness to be expressed as a % of total height.
e.g.
If we add e.g. SeparatorThickness to the style structure that suggest that
Separator()would use it.That also suggest that they do have similar look, whereas you can imagine what we currently call TextSeparator() (and may not be a good name) to have MANY possible look & feel & shape.
Also Separator() currently wouldn't be able to honor a thicker thickness: it's been hard-coded as thickness == 1.0f because it has a ZERO Y advancement for layout (v1.70 tried to make that advancement match the thickness, but it was reverted in v1.71 because that caused issues for frequently used pattern of measuring heights ahead of time where we suggested that accounting for Separator height was not necessary).
I believe
e.g.
TextHeader("hello")Separator(). The layout issue with Separator() can then be handled separately/later.As that point we may draw inspiration from css/web headings and consider the possibility we would later provide several level of heading, where H1 to H3 are expected to be larger than current font size. So need to pick a name that will be compatible with those future extensions.
I went back on forth several times to settle on something..
Eventually settling on a hard-coded Separator semantic is currently simpler.
I could find reasonable names for style variables that are not confusing with Separator().
I have pushed a WIP branch:
https://github.com/ocornut/imgui/commits/features/separator_text
Current commit is 9670a4d
There are a few things I need to do
@ocornut Thank you for spending cycles on this.
This is my view, but consider it just as brainstorming as I clearly do not know the internals of ImGui like you do...
I actually really like the concept of header. And from you said here are some ideas:
Idea 1:
What about a ImGui::BeginHeader() / ImGui::EndHeader() so you could write something like:
Idea 2:
Like you mentioned css/websettings, you could imagine having styles associated to each "level", like ImGuiCol_H1_Text, etc... and then you could use something like:
Idea 3: How about extending the
Separatorconcept so you could write something likeI have pushed a
SeparatorText()widget based on my code above.Commit
99c0bd6I believe the sizes/distances/alignment should be standardized and not provided by finer API calls, hence a simpler design than the finer-grained functions suggested by original post, and settings in style structure.
We need to preserve some semantic in the function calls in order to allow you to improve the styling system.
I consider this solved and would encourage you to use this now :)
I updated to 1.89.3 (docking) and confirm that it works great. Thank you @ocornut