Issue with changing menu height

dgregorius commented

2020-10-09 18:37:18 +00:00

(Migrated from github.com)

Version/Branch of Dear ImGui:

Version: 1.79
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp
Compiler: VS 2019
Operating System: Windows 10 (2004)

My Issue/Question:

I am styling my app right now and in the process I want to change the height of the main menu bar. In order to change the menu height I adjust the frame padding. The problem is that during hovering and activation the padding size is not taking into consideration. This seems inconsistent with other UI systems. Is there a way how I can have the menubar entries fill out the entire menu bar during hovering/selection?

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

Screenshots/Video

Standalone, minimal, complete and verifiable example:

This can be very easily reproduced in the demo:

static void ShowExampleAppMainMenuBar()
{
    ImGui::PushStyleVar( ImGuiStyleVar_FramePadding, ImVec2( 0, 16 ) );

   // [SNIP]

    ImGui::PopStyleVar();
}

**Version/Branch of Dear ImGui:** Version: 1.79 Branch: docking **Back-end/Renderer/Compiler/OS** Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp Compiler: VS 2019 Operating System: Windows 10 (2004) **My Issue/Question:** I am styling my app right now and in the process I want to change the height of the main menu bar. In order to change the menu height I adjust the frame padding. The problem is that during hovering and activation the padding size is not taking into consideration. This seems inconsistent with other UI systems. Is there a way how I can have the menubar entries fill out the entire menu bar during hovering/selection? BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. **Screenshots/Video** <img width="150" alt="MenuBar" src="https://user-images.githubusercontent.com/7042834/95619275-32f54500-0a23-11eb-8289-9d26dcbe5aee.PNG"> **Standalone, minimal, complete and verifiable example:** This can be very easily reproduced in the demo: ``` static void ShowExampleAppMainMenuBar() { ImGui::PushStyleVar( ImGuiStyleVar_FramePadding, ImVec2( 0, 16 ) ); // [SNIP] ImGui::PopStyleVar(); } ```

dgregorius commented

2020-10-10 15:50:24 +00:00

(Migrated from github.com)

I found a workaround for this. You can push the item spacing to counter the tight packing of the selectable before drawing each menu.

dgregorius commented

2020-10-10 15:50:24 +00:00

(Migrated from github.com)

I found a workaround for this. You can push the item spacing to counter the tight packing of the selectable before drawing each menu.

dgregorius commented

2020-10-10 15:50:24 +00:00

(Migrated from github.com)

I found a workaround for this. You can push the item spacing to counter the tight packing of the selectable before drawing each menu.

ocornut commented

2023-01-05 11:06:14 +00:00

(Migrated from github.com)

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

About this specific comment (which is a different issue than the main one):
This seems to a bug caused by specific interaction behavior required by menu items (including not but limited to: allowing navigating menu while holding mouse down and releasing mouse on any child menu).

For MenuItem(): we use ImGuiButtonFlags_PressedOnRelease behavior, which is standard and required, but I think ButtonBehavior() incorrect doesn't report the held state as this is gated by active id being taken. I think this is a bug in ButtonBehavior() and can be fixed but I need to investigate the possible side-effects.
But BeginMenu(): this is slightly different and trickier, as clicking opens a sub-menu and takes focus away.

For correctness we should fix both together (fixing only one would look widely inconsistent).

> BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. About this specific comment (which is a different issue than the main one): This seems to a bug caused by specific interaction behavior required by menu items (including not but limited to: allowing navigating menu while holding mouse down and releasing mouse on any child menu). - For `MenuItem()`: we use `ImGuiButtonFlags_PressedOnRelease` behavior, which is standard and required, but I think ButtonBehavior() incorrect doesn't report the `held` state as this is gated by active id being taken. I think this is a bug in `ButtonBehavior()` and can be fixed but I need to investigate the possible side-effects. - But `BeginMenu()`: this is slightly different and trickier, as clicking opens a sub-menu and takes focus away. For correctness we should fix both together (fixing only one would look widely inconsistent).

ocornut commented

2023-01-05 11:06:14 +00:00

(Migrated from github.com)

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

About this specific comment (which is a different issue than the main one):
This seems to a bug caused by specific interaction behavior required by menu items (including not but limited to: allowing navigating menu while holding mouse down and releasing mouse on any child menu).

For MenuItem(): we use ImGuiButtonFlags_PressedOnRelease behavior, which is standard and required, but I think ButtonBehavior() incorrect doesn't report the held state as this is gated by active id being taken. I think this is a bug in ButtonBehavior() and can be fixed but I need to investigate the possible side-effects.
But BeginMenu(): this is slightly different and trickier, as clicking opens a sub-menu and takes focus away.

For correctness we should fix both together (fixing only one would look widely inconsistent).

> BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. About this specific comment (which is a different issue than the main one): This seems to a bug caused by specific interaction behavior required by menu items (including not but limited to: allowing navigating menu while holding mouse down and releasing mouse on any child menu). - For `MenuItem()`: we use `ImGuiButtonFlags_PressedOnRelease` behavior, which is standard and required, but I think ButtonBehavior() incorrect doesn't report the `held` state as this is gated by active id being taken. I think this is a bug in `ButtonBehavior()` and can be fixed but I need to investigate the possible side-effects. - But `BeginMenu()`: this is slightly different and trickier, as clicking opens a sub-menu and takes focus away. For correctness we should fix both together (fixing only one would look widely inconsistent).

ocornut commented

2023-01-05 11:06:14 +00:00

(Migrated from github.com)

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

About this specific comment (which is a different issue than the main one):
This seems to a bug caused by specific interaction behavior required by menu items (including not but limited to: allowing navigating menu while holding mouse down and releasing mouse on any child menu).

For MenuItem(): we use ImGuiButtonFlags_PressedOnRelease behavior, which is standard and required, but I think ButtonBehavior() incorrect doesn't report the held state as this is gated by active id being taken. I think this is a bug in ButtonBehavior() and can be fixed but I need to investigate the possible side-effects.
But BeginMenu(): this is slightly different and trickier, as clicking opens a sub-menu and takes focus away.

For correctness we should fix both together (fixing only one would look widely inconsistent).

> BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. About this specific comment (which is a different issue than the main one): This seems to a bug caused by specific interaction behavior required by menu items (including not but limited to: allowing navigating menu while holding mouse down and releasing mouse on any child menu). - For `MenuItem()`: we use `ImGuiButtonFlags_PressedOnRelease` behavior, which is standard and required, but I think ButtonBehavior() incorrect doesn't report the `held` state as this is gated by active id being taken. I think this is a bug in `ButtonBehavior()` and can be fixed but I need to investigate the possible side-effects. - But `BeginMenu()`: this is slightly different and trickier, as clicking opens a sub-menu and takes focus away. For correctness we should fix both together (fixing only one would look widely inconsistent).

ocornut commented

2023-01-05 11:26:41 +00:00

(Migrated from github.com)

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

Following this small shuffling 83429ab
It is possible to fix this "bug" with this additional patch:
imgui-05d8995-ButtonBehavior() fix not reporting held state when using ImGuiButtonFlags_NoHoldingActiveId or ImGuiButtonFlags_PressedOnRelease which are used by MenuItem() and BeginMenu().patch

However this makes the navigating-menu-while-holding-mouse-button way of interacting menus look a little odd IHMO.
While comparing with others app (tried Firefox, VS2022, Win11 Explorer, SublimeText) I noticed that none of them use an 'Active' color for menu items, maybe for this exact reason.

In theory even we decided to not change it, it may be correct to apply patch then have MenuItem/BeginMenu intentionally override colors to counteract the fix, but that would prevent your workaround at well as making a rather side-effectey change to ButtonBehavior() for no visible reason, so may not be a good trade-off.

> BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. Following this small shuffling 83429ab It is possible to fix this "bug" with this additional patch: [imgui-05d8995-ButtonBehavior() fix not reporting held state when using ImGuiButtonFlags_NoHoldingActiveId or ImGuiButtonFlags_PressedOnRelease which are used by MenuItem() and BeginMenu().patch](https://github.com/ocornut/imgui/files/10351665/imgui-05d8995-ButtonBehavior.fix.not.reporting.held.state.when.using.ImGuiButtonFlags_NoHoldingActiveId.or.ImGuiButtonFlags_PressedOnRelease.which.are.used.by.MenuItem.and.BeginMenu.patch) However this makes the navigating-menu-while-holding-mouse-button way of interacting menus look a little odd IHMO. While comparing with others app (tried Firefox, VS2022, Win11 Explorer, SublimeText) I noticed that none of them use an 'Active' color for menu items, maybe for this exact reason. In theory even we decided to not change it, it may be correct to apply patch then have MenuItem/BeginMenu intentionally override colors to counteract the fix, but that would prevent your workaround at well as making a rather side-effectey change to `ButtonBehavior()` for no visible reason, so may not be a good trade-off.

ocornut commented

2023-01-05 11:26:41 +00:00

(Migrated from github.com)

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

Following this small shuffling 83429ab
It is possible to fix this "bug" with this additional patch:
imgui-05d8995-ButtonBehavior() fix not reporting held state when using ImGuiButtonFlags_NoHoldingActiveId or ImGuiButtonFlags_PressedOnRelease which are used by MenuItem() and BeginMenu().patch

However this makes the navigating-menu-while-holding-mouse-button way of interacting menus look a little odd IHMO.
While comparing with others app (tried Firefox, VS2022, Win11 Explorer, SublimeText) I noticed that none of them use an 'Active' color for menu items, maybe for this exact reason.

In theory even we decided to not change it, it may be correct to apply patch then have MenuItem/BeginMenu intentionally override colors to counteract the fix, but that would prevent your workaround at well as making a rather side-effectey change to ButtonBehavior() for no visible reason, so may not be a good trade-off.

> BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. Following this small shuffling 83429ab It is possible to fix this "bug" with this additional patch: [imgui-05d8995-ButtonBehavior() fix not reporting held state when using ImGuiButtonFlags_NoHoldingActiveId or ImGuiButtonFlags_PressedOnRelease which are used by MenuItem() and BeginMenu().patch](https://github.com/ocornut/imgui/files/10351665/imgui-05d8995-ButtonBehavior.fix.not.reporting.held.state.when.using.ImGuiButtonFlags_NoHoldingActiveId.or.ImGuiButtonFlags_PressedOnRelease.which.are.used.by.MenuItem.and.BeginMenu.patch) However this makes the navigating-menu-while-holding-mouse-button way of interacting menus look a little odd IHMO. While comparing with others app (tried Firefox, VS2022, Win11 Explorer, SublimeText) I noticed that none of them use an 'Active' color for menu items, maybe for this exact reason. In theory even we decided to not change it, it may be correct to apply patch then have MenuItem/BeginMenu intentionally override colors to counteract the fix, but that would prevent your workaround at well as making a rather side-effectey change to `ButtonBehavior()` for no visible reason, so may not be a good trade-off.

ocornut commented

2023-01-05 11:26:41 +00:00

(Migrated from github.com)

BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this.

Following this small shuffling 83429ab
It is possible to fix this "bug" with this additional patch:
imgui-05d8995-ButtonBehavior() fix not reporting held state when using ImGuiButtonFlags_NoHoldingActiveId or ImGuiButtonFlags_PressedOnRelease which are used by MenuItem() and BeginMenu().patch

However this makes the navigating-menu-while-holding-mouse-button way of interacting menus look a little odd IHMO.
While comparing with others app (tried Firefox, VS2022, Win11 Explorer, SublimeText) I noticed that none of them use an 'Active' color for menu items, maybe for this exact reason.

In theory even we decided to not change it, it may be correct to apply patch then have MenuItem/BeginMenu intentionally override colors to counteract the fix, but that would prevent your workaround at well as making a rather side-effectey change to ButtonBehavior() for no visible reason, so may not be a good trade-off.

> BTW: In this context - I find it counter intuitive that hovering supersedes activation. If an item is hovered and active the hovered color is chosen. I find myself often fiddling unnecessarily with style variables to work around this. Following this small shuffling 83429ab It is possible to fix this "bug" with this additional patch: [imgui-05d8995-ButtonBehavior() fix not reporting held state when using ImGuiButtonFlags_NoHoldingActiveId or ImGuiButtonFlags_PressedOnRelease which are used by MenuItem() and BeginMenu().patch](https://github.com/ocornut/imgui/files/10351665/imgui-05d8995-ButtonBehavior.fix.not.reporting.held.state.when.using.ImGuiButtonFlags_NoHoldingActiveId.or.ImGuiButtonFlags_PressedOnRelease.which.are.used.by.MenuItem.and.BeginMenu.patch) However this makes the navigating-menu-while-holding-mouse-button way of interacting menus look a little odd IHMO. While comparing with others app (tried Firefox, VS2022, Win11 Explorer, SublimeText) I noticed that none of them use an 'Active' color for menu items, maybe for this exact reason. In theory even we decided to not change it, it may be correct to apply patch then have MenuItem/BeginMenu intentionally override colors to counteract the fix, but that would prevent your workaround at well as making a rather side-effectey change to `ButtonBehavior()` for no visible reason, so may not be a good trade-off.

ocornut commented

2026-02-17 16:19:03 +00:00

(Migrated from github.com)

Linking to #6134 for related issue.

I was toying with something related today:

if (ImGui::BeginMainMenuBar())
{
    if (ImGui::BeginMenu("File")) { ImGui::EndMenu(); }
    if (ImGui::BeginMenu("Edit")) { ImGui::EndMenu(); }
    ImGui::Separator();
    if (ImGui::BeginTabBar("##TabBar"))
    {
        if (ImGui::BeginTabItem("Blah"))
            ImGui::EndTabItem();
        if (ImGui::BeginTabItem("Blih"))
            ImGui::EndTabItem();
        if (ImGui::BeginTabItem("Blou"))
            ImGui::EndTabItem();
        ImGui::EndTabBar();
    }
    ImGui::EndMainMenuBar();
}

And noticed both the issue with menu highlight height, and potentially with wanting to add a bit of padding at the top of the tab-bar.

I'll try to come to back to this.

Linking to #6134 for related issue. I was toying with something related today: ```cpp if (ImGui::BeginMainMenuBar()) { if (ImGui::BeginMenu("File")) { ImGui::EndMenu(); } if (ImGui::BeginMenu("Edit")) { ImGui::EndMenu(); } ImGui::Separator(); if (ImGui::BeginTabBar("##TabBar")) { if (ImGui::BeginTabItem("Blah")) ImGui::EndTabItem(); if (ImGui::BeginTabItem("Blih")) ImGui::EndTabItem(); if (ImGui::BeginTabItem("Blou")) ImGui::EndTabItem(); ImGui::EndTabBar(); } ImGui::EndMainMenuBar(); } ``` And noticed both the issue with menu highlight height, and potentially with wanting to add a bit of padding at the top of the tab-bar. <img width="667" height="105" alt="Image" src="https://github.com/user-attachments/assets/7da14b64-ead8-4e9e-a81c-3732f289ca16" /> I'll try to come to back to this.

ocornut commented

2026-02-17 16:19:03 +00:00

(Migrated from github.com)

Linking to #6134 for related issue.

I was toying with something related today:

if (ImGui::BeginMainMenuBar())
{
    if (ImGui::BeginMenu("File")) { ImGui::EndMenu(); }
    if (ImGui::BeginMenu("Edit")) { ImGui::EndMenu(); }
    ImGui::Separator();
    if (ImGui::BeginTabBar("##TabBar"))
    {
        if (ImGui::BeginTabItem("Blah"))
            ImGui::EndTabItem();
        if (ImGui::BeginTabItem("Blih"))
            ImGui::EndTabItem();
        if (ImGui::BeginTabItem("Blou"))
            ImGui::EndTabItem();
        ImGui::EndTabBar();
    }
    ImGui::EndMainMenuBar();
}

And noticed both the issue with menu highlight height, and potentially with wanting to add a bit of padding at the top of the tab-bar.

I'll try to come to back to this.

Linking to #6134 for related issue. I was toying with something related today: ```cpp if (ImGui::BeginMainMenuBar()) { if (ImGui::BeginMenu("File")) { ImGui::EndMenu(); } if (ImGui::BeginMenu("Edit")) { ImGui::EndMenu(); } ImGui::Separator(); if (ImGui::BeginTabBar("##TabBar")) { if (ImGui::BeginTabItem("Blah")) ImGui::EndTabItem(); if (ImGui::BeginTabItem("Blih")) ImGui::EndTabItem(); if (ImGui::BeginTabItem("Blou")) ImGui::EndTabItem(); ImGui::EndTabBar(); } ImGui::EndMainMenuBar(); } ``` And noticed both the issue with menu highlight height, and potentially with wanting to add a bit of padding at the top of the tab-bar. <img width="667" height="105" alt="Image" src="https://github.com/user-attachments/assets/7da14b64-ead8-4e9e-a81c-3732f289ca16" /> I'll try to come to back to this.

memononen commented

2026-02-27 19:27:14 +00:00

(Migrated from github.com)

Having TabTopPadding would help dock tabs a lot too. Currently things get very busy (depends on color scheme too, though).

Rows
Columns

Issue with changing menu height #3516