Modal Dialogs

Pagghiu commented

2015-06-23 10:21:18 +00:00

(Migrated from github.com)

It would be nice to add an begin/end api pair to allow for Modal Dialogs that block inputs to anything else, waiting for and answer.
A gif is worth a thousand words ;)

I think this can be implemented with minor modifications to current functionality in many ways, but I'm not sure what's the best one (tooltips? Begin/EndPopup? Fullscreen window?).
This test gif has been done creating a fullscreen window (to mask the background AND block inputs to windows below) and a child window that contains the text+yes/no controls.
I've also done some hacks to calculate child windows minimum Y size.
Maybe I should use a second window with autosize for the actual dialog content instead of a child win.

Thoughts?

It would be nice to add an begin/end api pair to allow for Modal Dialogs that block inputs to anything else, waiting for and answer. A gif is worth a thousand words ;) ![imguimodaldialog](https://cloud.githubusercontent.com/assets/5406873/8303817/03ddb9dc-19a1-11e5-94b6-e60e5299398e.gif) I think this can be implemented with minor modifications to current functionality in many ways, but I'm not sure what's the best one (tooltips? Begin/EndPopup? Fullscreen window?). This test gif has been done creating a fullscreen window (to mask the background AND block inputs to windows below) and a child window that contains the text+yes/no controls. I've also done some hacks to calculate child windows minimum Y size. Maybe I should use a second window with autosize for the actual dialog content instead of a child win. Thoughts?

👍 3 😆 1

extrawurst commented

2015-06-23 11:02:50 +00:00

(Migrated from github.com)

OT: this looks great !!!!

emoon commented

2015-06-23 12:50:26 +00:00

(Migrated from github.com)

+1 for Modal Dialogs

extrawurst commented

2015-06-23 12:53:41 +00:00

(Migrated from github.com)

+1 Yeah Modal Dialogs are a great addition!

ocornut commented

2015-06-23 12:57:22 +00:00

(Migrated from github.com)

Seems reasonably easy to implement.

Add modal dialogs e.g. BeginModal() they would basically be popups with an additional flag to remove the ability to click elsewhere.
The darkening could be a style property, ImGuiCol_ModalDarkening default to ImColor(0, 0, 0, 0.3f) and handled by the library.
Then we need a way to automatically center the window, there's currently no way to do it automatically on the first frame the window appears but it should be a simple thing to add as well.

(Nice colors, could you post your styke & font settings somewhere?)

Seems reasonably easy to implement. - Add modal dialogs e.g. BeginModal() they would basically be popups with an additional flag to remove the ability to click elsewhere. - The darkening could be a style property, ImGuiCol_ModalDarkening default to ImColor(0, 0, 0, 0.3f) and handled by the library. - Then we need a way to automatically center the window, there's currently no way to do it automatically on the first frame the window appears but it should be a simple thing to add as well. (Nice colors, could you post your styke & font settings somewhere?)

Pagghiu commented

2015-06-23 17:16:01 +00:00

(Migrated from github.com)

Thanks @everyone for joining the discussion!

The way I've been drafting the api is very close to the popup.
I really think that the closing EndDialog should give a few common presets (YesNo, OkCancel etc.) or a NoButtons if the user really wants to draw/handle the buttons him/herself.
In the last case he will signal the closing of dialog by setting selection var to 1 or some other known value.

 if(ImGui::CollapsingHeaderIcon("Images", ImGui_fa_camera))
    {
        if (ImGui::ButtonIcon("Live Image", ImGui_fa_camera))
            ImGui::OpenDialog("test dialog");

        if (ImGui::BeginDialog("test dialog", ImVec2((float)view->getWidth(), (float)view->getHeight())))
        {
            ImGui::TextWrapped("Are you sure you want to do this and this and that?");
            ImGui::TextWrapped("Are you sure you want to do this and this and that?");
            ImGui::TextWrapped("Are you sure you want to do this and this and that?");
            static int currentItem = 0;
            ImGui::Combo("Your choice", &currentItem, "Item 1\0Item 2\0Item 3\0Item 4\0\0");
            if (currentItem == 1)
            {
                ImGui::TextWrapped("Good choice!!");
                ImGui::TextWrapped("Good choice!!");
                ImGui::TextWrapped("Good choice!!");
            }

            int selection;
            if (ImGui::EndDialog(ImGui::Dialog_YesNo, &selection))
            {
                if (selection == 0)
                {
                    // Dialog Dismissed with YES (first item)
                }
                else
                {
                    // Dialog Dismissed with NO (second item)
                }
            }           
        }
    // other stuff
    }

ImGuiCol_ModalDarkening 👍 animating the alpha value makes it very nice looking!
The centring was my issue as well...I've done it so that during first frame I render with alpha ~ 0, just to calculate the dialog size, and from the next frame than I use it to center the child window.
I re-compute the Y size so in case something gets added (like shown in the gif) it will be adjusted in next frame (it's almost not noticeable at 60 fps...)
Some consideration goes for the centring of the buttons.

Regarding my settings:
Font is DroidSans from extra_fonts.
I'm using ttf icon fonts from http://fortawesome.github.io/Font-Awesome/icons/ and a couple of custom Button/CollapsingHeader functions that render the icon to left/right of text like described in #232

    style.Colors[ImGuiCol_Text] = ImVec4(0.31f, 0.25f, 0.24f, 1.00f);
    style.Colors[ImGuiCol_WindowBg] = ImVec4(0.94f, 0.94f, 0.94f, 1.00f);
    style.Colors[ImGuiCol_ChildWindowBg] = ImVec4(0.68f, 0.68f, 0.68f, 0.00f);
    style.Colors[ImGuiCol_Border] = ImVec4(0.70f, 0.70f, 0.70f, 0.19f);
    style.Colors[ImGuiCol_BorderShadow] = ImVec4(0.00f, 0.00f, 0.00f, 0.00f);
    style.Colors[ImGuiCol_FrameBg] = ImVec4(0.62f, 0.70f, 0.72f, 0.56f);
    style.Colors[ImGuiCol_FrameBgHovered] = ImVec4(0.95f, 0.33f, 0.14f, 0.47f);
    style.Colors[ImGuiCol_FrameBgActive] = ImVec4(0.97f, 0.31f, 0.13f, 0.81f);
    style.Colors[ImGuiCol_TitleBg] = ImVec4(0.42f, 0.75f, 1.00f, 0.53f);
    style.Colors[ImGuiCol_TitleBgCollapsed] = ImVec4(0.40f, 0.65f, 0.80f, 0.20f);
    style.Colors[ImGuiCol_ScrollbarBg] = ImVec4(0.40f, 0.62f, 0.80f, 0.15f);
    style.Colors[ImGuiCol_ScrollbarGrab] = ImVec4(0.39f, 0.64f, 0.80f, 0.30f);
    style.Colors[ImGuiCol_ScrollbarGrabHovered] = ImVec4(0.28f, 0.67f, 0.80f, 0.59f);
    style.Colors[ImGuiCol_ScrollbarGrabActive] = ImVec4(0.25f, 0.48f, 0.53f, 0.67f);
    style.Colors[ImGuiCol_ComboBg] = ImVec4(0.89f, 0.98f, 1.00f, 0.99f);
    style.Colors[ImGuiCol_CheckMark] = ImVec4(0.38f, 0.37f, 0.37f, 0.91f);
    style.Colors[ImGuiCol_SliderGrabActive] = ImVec4(0.31f, 0.47f, 0.99f, 1.00f);
    style.Colors[ImGuiCol_Button] = ImVec4(1.00f, 0.79f, 0.18f, 0.78f);
    style.Colors[ImGuiCol_ButtonHovered] = ImVec4(0.42f, 0.82f, 1.00f, 0.81f);
    style.Colors[ImGuiCol_ButtonActive] = ImVec4(1.00f, 1.00f, 1.00f, 0.86f);
    style.Colors[ImGuiCol_Header] = ImVec4(0.73f, 0.80f, 0.86f, 0.45f);
    style.Colors[ImGuiCol_HeaderHovered] = ImVec4(0.75f, 0.88f, 0.94f, 0.80f);
    style.Colors[ImGuiCol_HeaderActive] = ImVec4(0.46f, 0.84f, 0.90f, 1.00f);
    style.Colors[ImGuiCol_CloseButton] = ImVec4(0.41f, 0.75f, 0.98f, 0.50f);
    style.Colors[ImGuiCol_CloseButtonHovered] = ImVec4(1.00f, 0.47f, 0.41f, 0.60f);
    style.Colors[ImGuiCol_CloseButtonActive] = ImVec4(1.00f, 0.16f, 0.00f, 1.00f);
    style.Colors[ImGuiCol_TextSelectedBg] = ImVec4(1.00f, 0.99f, 0.54f, 0.43f);
    style.Colors[ImGuiCol_TooltipBg] = ImVec4(0.82f, 0.92f, 1.00f, 0.90f);
    style.Alpha = 1.0f;
    style.WindowFillAlphaDefault = 1.0f;
    style.FrameRounding = 4;

Thanks @everyone for joining the discussion! 1) The way I've been drafting the api is very close to the popup. I really think that the closing EndDialog should give a few common presets (YesNo, OkCancel etc.) or a NoButtons if the user really wants to draw/handle the buttons him/herself. In the last case he will signal the closing of dialog by setting selection var to 1 or some other known value. ``` cpp if(ImGui::CollapsingHeaderIcon("Images", ImGui_fa_camera)) { if (ImGui::ButtonIcon("Live Image", ImGui_fa_camera)) ImGui::OpenDialog("test dialog"); if (ImGui::BeginDialog("test dialog", ImVec2((float)view->getWidth(), (float)view->getHeight()))) { ImGui::TextWrapped("Are you sure you want to do this and this and that?"); ImGui::TextWrapped("Are you sure you want to do this and this and that?"); ImGui::TextWrapped("Are you sure you want to do this and this and that?"); static int currentItem = 0; ImGui::Combo("Your choice", &currentItem, "Item 1\0Item 2\0Item 3\0Item 4\0\0"); if (currentItem == 1) { ImGui::TextWrapped("Good choice!!"); ImGui::TextWrapped("Good choice!!"); ImGui::TextWrapped("Good choice!!"); } int selection; if (ImGui::EndDialog(ImGui::Dialog_YesNo, &selection)) { if (selection == 0) { // Dialog Dismissed with YES (first item) } else { // Dialog Dismissed with NO (second item) } } } // other stuff } ``` 2) ImGuiCol_ModalDarkening :+1: animating the alpha value makes it very nice looking! 3) The centring was my issue as well...I've done it so that during first frame I render with alpha ~ 0, just to calculate the dialog size, and from the next frame than I use it to center the child window. I re-compute the Y size so in case something gets added (like shown in the gif) it will be adjusted in next frame (it's almost not noticeable at 60 fps...) Some consideration goes for the centring of the buttons. Regarding my settings: Font is DroidSans from extra_fonts. I'm using ttf icon fonts from http://fortawesome.github.io/Font-Awesome/icons/ and a couple of custom Button/CollapsingHeader functions that render the icon to left/right of text like described in #232 ``` cpp style.Colors[ImGuiCol_Text] = ImVec4(0.31f, 0.25f, 0.24f, 1.00f); style.Colors[ImGuiCol_WindowBg] = ImVec4(0.94f, 0.94f, 0.94f, 1.00f); style.Colors[ImGuiCol_ChildWindowBg] = ImVec4(0.68f, 0.68f, 0.68f, 0.00f); style.Colors[ImGuiCol_Border] = ImVec4(0.70f, 0.70f, 0.70f, 0.19f); style.Colors[ImGuiCol_BorderShadow] = ImVec4(0.00f, 0.00f, 0.00f, 0.00f); style.Colors[ImGuiCol_FrameBg] = ImVec4(0.62f, 0.70f, 0.72f, 0.56f); style.Colors[ImGuiCol_FrameBgHovered] = ImVec4(0.95f, 0.33f, 0.14f, 0.47f); style.Colors[ImGuiCol_FrameBgActive] = ImVec4(0.97f, 0.31f, 0.13f, 0.81f); style.Colors[ImGuiCol_TitleBg] = ImVec4(0.42f, 0.75f, 1.00f, 0.53f); style.Colors[ImGuiCol_TitleBgCollapsed] = ImVec4(0.40f, 0.65f, 0.80f, 0.20f); style.Colors[ImGuiCol_ScrollbarBg] = ImVec4(0.40f, 0.62f, 0.80f, 0.15f); style.Colors[ImGuiCol_ScrollbarGrab] = ImVec4(0.39f, 0.64f, 0.80f, 0.30f); style.Colors[ImGuiCol_ScrollbarGrabHovered] = ImVec4(0.28f, 0.67f, 0.80f, 0.59f); style.Colors[ImGuiCol_ScrollbarGrabActive] = ImVec4(0.25f, 0.48f, 0.53f, 0.67f); style.Colors[ImGuiCol_ComboBg] = ImVec4(0.89f, 0.98f, 1.00f, 0.99f); style.Colors[ImGuiCol_CheckMark] = ImVec4(0.38f, 0.37f, 0.37f, 0.91f); style.Colors[ImGuiCol_SliderGrabActive] = ImVec4(0.31f, 0.47f, 0.99f, 1.00f); style.Colors[ImGuiCol_Button] = ImVec4(1.00f, 0.79f, 0.18f, 0.78f); style.Colors[ImGuiCol_ButtonHovered] = ImVec4(0.42f, 0.82f, 1.00f, 0.81f); style.Colors[ImGuiCol_ButtonActive] = ImVec4(1.00f, 1.00f, 1.00f, 0.86f); style.Colors[ImGuiCol_Header] = ImVec4(0.73f, 0.80f, 0.86f, 0.45f); style.Colors[ImGuiCol_HeaderHovered] = ImVec4(0.75f, 0.88f, 0.94f, 0.80f); style.Colors[ImGuiCol_HeaderActive] = ImVec4(0.46f, 0.84f, 0.90f, 1.00f); style.Colors[ImGuiCol_CloseButton] = ImVec4(0.41f, 0.75f, 0.98f, 0.50f); style.Colors[ImGuiCol_CloseButtonHovered] = ImVec4(1.00f, 0.47f, 0.41f, 0.60f); style.Colors[ImGuiCol_CloseButtonActive] = ImVec4(1.00f, 0.16f, 0.00f, 1.00f); style.Colors[ImGuiCol_TextSelectedBg] = ImVec4(1.00f, 0.99f, 0.54f, 0.43f); style.Colors[ImGuiCol_TooltipBg] = ImVec4(0.82f, 0.92f, 1.00f, 0.90f); style.Alpha = 1.0f; style.WindowFillAlphaDefault = 1.0f; style.FrameRounding = 4; ```

ocornut commented

2015-06-23 18:15:30 +00:00

(Migrated from github.com)

Thanks for the detail. I am working of it (the basic behaviour work but there's no darkening now so it can be confusing).

I called the main function BeginPopupModal() and not just BeginModal() to clarify that it is using the popup system and related popup functions are available.

            if (ImGui::Button("Modal"))
                ImGui::OpenPopup("Modal window");

            bool open = true;
            if (ImGui::BeginPopupModal("Modal window", &open))
            {
                ImGui::Text("Hello dsjfhds fhjs hfj dshfj hds");
                if (ImGui::Button("Close"))
                    ImGui::CloseCurrentPopup();
                ImGui::EndPopup();
            }

It would be possible to pass a flag to EndPopup() to close it as you suggested but I don't think it is necessary with the availability of CloseCurrentPopup().
I could make buttons close modal dialog by default but I think it would be introduce a rather big inconsistency so I'd rather not.
I am not sure the YesNo, OkCancel part is really helpful here, considering it is so easy to create buttons (centered ones less so). Apart from the demo windows ImGui also doesn't assume any English in string literal so that would be a first. And you yourself wouldn't be able to use it considering you have custom buttons. What we should do is to work on better layout helpers and/or add helpers for the specific case of creating a few buttons. It's quite open-ended at this stage and not specifically related to dialogs.
basic modal behavior
darkening
initial position and centering of window (not like normal popups)
stacked modal windows
demo

Thanks for the detail. I am working of it (the basic behaviour work but there's no darkening now so it can be confusing). I called the main function BeginPopupModal() and not just BeginModal() to clarify that it is using the popup system and related popup functions are available. ``` if (ImGui::Button("Modal")) ImGui::OpenPopup("Modal window"); bool open = true; if (ImGui::BeginPopupModal("Modal window", &open)) { ImGui::Text("Hello dsjfhds fhjs hfj dshfj hds"); if (ImGui::Button("Close")) ImGui::CloseCurrentPopup(); ImGui::EndPopup(); } ``` - It would be possible to pass a flag to EndPopup() to close it as you suggested but I don't think it is necessary with the availability of CloseCurrentPopup(). - I could make buttons close modal dialog by default but I think it would be introduce a rather big inconsistency so I'd rather not. - I am not sure the YesNo, OkCancel part is really helpful here, considering it is so easy to create buttons (centered ones less so). Apart from the demo windows ImGui also doesn't assume any English in string literal so that would be a first. And you yourself wouldn't be able to use it considering you have custom buttons. What we should do is to work on better layout helpers and/or add helpers for the specific case of creating a few buttons. It's quite open-ended at this stage and not specifically related to dialogs. - [x] basic modal behavior - [x] darkening - [x] initial position and centering of window (not like normal popups) - [x] stacked modal windows - [x] demo

ocornut commented

2015-06-23 19:24:08 +00:00

(Migrated from github.com)

Added darkening, added demo

Added darkening, added demo ![modal dialog](https://cloud.githubusercontent.com/assets/8225057/8315071/1b46320c-19ab-11e5-86aa-d0de03e3d227.png)

❤️ 3

ocornut commented

2015-06-23 20:33:23 +00:00

(Migrated from github.com)

Not sure what to do with the centering here. I made the modal windows center on screen at the time they first appear.

I tried to make them always recenter but it's particularly odd if you click somewhere and your mouse cursor is not over the same widgets as a result of the window moving.
You can still use SetNextWindowPos() to enforce a position.
One question left is should I recenter them on subsequent apparition or keep the last position? (if you allowed the window to be moved).
I should add the end-user calls perhaps via SetNextWindowPos() to center any window, either an alternative call, or using a magic value (unfortunately negative values are useful..) or an extra parameter.

Not sure what to do with the centering here. I made the modal windows center on screen at the time they first appear. - I tried to make them always recenter but it's particularly odd if you click somewhere and your mouse cursor is not over the same widgets as a result of the window moving. - You can still use SetNextWindowPos() to enforce a position. - One question left is should I recenter them on subsequent apparition or keep the last position? (if you allowed the window to be moved). - I should add the end-user calls perhaps via SetNextWindowPos() to center any window, either an alternative call, or using a magic value (unfortunately negative values are useful..) or an extra parameter.

adam4813 commented

2015-06-23 21:22:46 +00:00

(Migrated from github.com)

Is there a GetLastWindowWidth like method that could be used in a call to a
method like SetLastWindowPosition?
On Jun 23, 2015 3:33 PM, "omar" notifications@github.com wrote:

Not sure what to do with the centering here. I made the modal windows
center on screen at the time they first appear.

I tried to make them always recenter but it's particularly odd if you
click somewhere and your mouse cursor is not over the same widgets as a
result of the window moving.

One question left is should I recenter them on subsequent apparition
or keep the last position? (if you allowed the window to be moved).

I should add the end-user calls perhaps via SetNextWindowPos() to
center any window.

—
Reply to this email directly or view it on GitHub
https://github.com/ocornut/imgui/issues/249#issuecomment-114633869.

Is there a GetLastWindowWidth like method that could be used in a call to a method like SetLastWindowPosition? On Jun 23, 2015 3:33 PM, "omar" notifications@github.com wrote: > Not sure what to do with the centering here. I made the modal windows > center on screen at the time they first appear. > > - > > I tried to make them always recenter but it's particularly odd if you > click somewhere and your mouse cursor is not over the same widgets as a > result of the window moving. > - > > One question left is should I recenter them on subsequent apparition > or keep the last position? (if you allowed the window to be moved). > - > > I should add the end-user calls perhaps via SetNextWindowPos() to > center any window. > > — > Reply to this email directly or view it on GitHub > https://github.com/ocornut/imgui/issues/249#issuecomment-114633869.

ocornut commented

2015-06-23 21:36:52 +00:00

(Migrated from github.com)

@adam4813 What are you trying to do exactly ?

You can use:
GetWindowWidth(); // current window
SetNextWindowPos/Size(); // set pos/size of upcoming window

@adam4813 What are you trying to do exactly ? You can use: GetWindowWidth(); // current window SetNextWindowPos/Size(); // set pos/size of upcoming window

adam4813 commented

2015-06-23 23:10:03 +00:00

(Migrated from github.com)

I was throwing out a suggestion for centering.
On Jun 23, 2015 4:37 PM, "omar" notifications@github.com wrote:

@adam4813 https://github.com/adam4813 What are you trying to do exactly
?

You can use:
GetWindowWidth(); // current window
SetNextWindowPos/Size(); // set pos/size of upcoming window

—
Reply to this email directly or view it on GitHub
https://github.com/ocornut/imgui/issues/249#issuecomment-114648683.

I was throwing out a suggestion for centering. On Jun 23, 2015 4:37 PM, "omar" notifications@github.com wrote: > @adam4813 https://github.com/adam4813 What are you trying to do exactly > ? > > You can use: > GetWindowWidth(); // current window > SetNextWindowPos/Size(); // set pos/size of upcoming window > > — > Reply to this email directly or view it on GitHub > https://github.com/ocornut/imgui/issues/249#issuecomment-114648683.

ocornut commented

2015-06-24 00:41:49 +00:00

(Migrated from github.com)

You are right that it is missing some api to do it without juggling awkwardly with 'next window pos' and 'current window size'.
I will add optional name to the GetWindowPos/Size functions that would cover some more cases.

You are right that it is missing some api to do it without juggling awkwardly with 'next window pos' and 'current window size'. I will add optional name to the GetWindowPos/Size functions that would cover some more cases.

Pagghiu commented

2015-06-24 10:48:21 +00:00

(Migrated from github.com)

I like your api a lot more than my proposal, I will test it soon and reporting any inconsistency I may eventually found.
@ocornut your speed in implementing this one has been awesome 👍

I like your api a lot more than my proposal, I will test it soon and reporting any inconsistency I may eventually found. @ocornut your speed in implementing this one has been awesome :+1:

emoon commented

2015-06-24 11:13:26 +00:00

(Migrated from github.com)

+1 I will try out this very soonish :)

Pagghiu commented

2015-06-24 11:43:43 +00:00

(Migrated from github.com)

Not sure if it's a bug or wrong usage, posting here anyway.

The following code will cause a wrong Y centering.

        if (ImGui::BeginPopupModal("Load Image?", nullptr, ImGuiWindowFlags_AlwaysAutoResize))
        {
            static int currentItem = 0;
            ImGui::Combo("Your choice", &currentItem, "Item 1\0Item 2\0Item 3\0Item 4\0\0");
            if (currentItem == 1)
            {
                ImGui::TextWrapped("Good choice!!");
            }
            ImGui::Text("This line is a regular text line and works fine");
            ImGui::TextWrapped("This is a wrapped line and will cause a wrong Y centering");

            if (ImGui::ButtonIcon("OK", ImGui_fa_check, ImVec2(120, 40))) { ImGui::CloseCurrentPopup(); }
            ImGui::SameLine();
            if (ImGui::ButtonIcon("Cancel", ImGui_fa_close, ImVec2(120, 40))) { ImGui::CloseCurrentPopup(); }
            ImGui::EndPopup();
        }

Commenting the ImGui::TextWrapped solves the problem.

Not sure if it's a bug or wrong usage, posting here anyway. The following code will cause a wrong Y centering. ``` cpp if (ImGui::BeginPopupModal("Load Image?", nullptr, ImGuiWindowFlags_AlwaysAutoResize)) { static int currentItem = 0; ImGui::Combo("Your choice", &currentItem, "Item 1\0Item 2\0Item 3\0Item 4\0\0"); if (currentItem == 1) { ImGui::TextWrapped("Good choice!!"); } ImGui::Text("This line is a regular text line and works fine"); ImGui::TextWrapped("This is a wrapped line and will cause a wrong Y centering"); if (ImGui::ButtonIcon("OK", ImGui_fa_check, ImVec2(120, 40))) { ImGui::CloseCurrentPopup(); } ImGui::SameLine(); if (ImGui::ButtonIcon("Cancel", ImGui_fa_close, ImVec2(120, 40))) { ImGui::CloseCurrentPopup(); } ImGui::EndPopup(); } ``` Commenting the ImGui::TextWrapped solves the problem. ![modalcenteringbug](https://cloud.githubusercontent.com/assets/5406873/8329092/e52dfac0-1a76-11e5-8a41-65e0f9f3e8b4.png) ![modalcenteringok](https://cloud.githubusercontent.com/assets/5406873/8329093/e54f2cc2-1a76-11e5-840f-533704b94f1c.png)

ocornut commented

2015-06-24 12:15:40 +00:00

(Migrated from github.com)

Yes it's an issue with TextWrapped it doesn't really work with always auto-resizing windows at the moment.

On frame 0 which isnt displayed, while the initial size is being calculated the window is still zero width so wrapped text takes lots of vertical place. Because the modal is centered only once it stays there. There's way around the issue with TextWrapped but not that I'm satisfied with yet. I can probably at least mitigate the problem.

Note that if you call SetNextWindowSize(400,0) prior to opening the dialog to enforce a width it should remove the issue.

Yes it's an issue with TextWrapped it doesn't really work with always auto-resizing windows at the moment. On frame 0 which isnt displayed, while the initial size is being calculated the window is still zero width so wrapped text takes lots of vertical place. Because the modal is centered only once it stays there. There's way around the issue with TextWrapped but not that I'm satisfied with yet. I can probably at least mitigate the problem. Note that if you call SetNextWindowSize(400,0) prior to opening the dialog to enforce a width it should remove the issue.

Pagghiu commented

2015-06-24 13:09:32 +00:00

(Migrated from github.com)

Ok, I understand, not a big deal actually, it's just important to know, I can skip the wrapped text calls for the first frame if needed.

ocornut commented

2015-06-24 14:22:56 +00:00

(Migrated from github.com)

If you push an explicit width to wrap, e.g. PushTextWrapPos(400); Text(...)
it'll also work.

If you push an explicit width to wrap, e.g. PushTextWrapPos(400); Text(...) it'll also work.

ocornut commented

2015-06-25 00:36:14 +00:00

(Migrated from github.com)

If anybody else tries the dialog let me know. I would like to package 1.41 shortly if possible.

I'm not sure yet what to do with TextWrapped() (it's a known problem for always-auto-resizing window) but I'll handle that separately.

If anybody else tries the dialog let me know. I would like to package 1.41 shortly if possible. I'm not sure yet what to do with TextWrapped() (it's a known problem for always-auto-resizing window) but I'll handle that separately.

ocornut commented

2015-06-25 02:59:25 +00:00

(Migrated from github.com)

@adam4813 I just remembered why functions like GetWindowPos/GetWindowSize etc. didn't allow to pass in a name. The reason is that I didn't know how to handle errors properly if the given name didn't match an existing window.
It's ok to assert on incorrect code but I don't really want to assert on incorrect data (or very rarely), especially here it's easy to imagine cases where a window doesn't already exist. I could return a default value for position/size (e.g. zero) but I don't fancy silent errors either. So I left that unsolved and didn't add this parameter to the functions even though as you pointed you it would be useful e.g. to manual center a window, without juggling with next/current window functions.

If I get to implement the ID collision mechanism I envision in the future perhaps imgui will have a non intrusive way to signal errors to the programmer and then it might be a good place to log in a warning in those cases.

@adam4813 I just remembered why functions like GetWindowPos/GetWindowSize etc. didn't allow to pass in a name. The reason is that I didn't know how to handle errors properly if the given name didn't match an existing window. It's ok to assert on incorrect code but I don't really want to assert on incorrect data (or very rarely), especially here it's easy to imagine cases where a window doesn't already exist. I could return a default value for position/size (e.g. zero) but I don't fancy silent errors either. So I left that unsolved and didn't add this parameter to the functions even though as you pointed you it would be useful e.g. to manual center a window, without juggling with next/current window functions. If I get to implement the ID collision mechanism I envision in the future perhaps imgui will have a non intrusive way to signal errors to the programmer and then it might be a good place to log in a warning in those cases.

adam4813 commented

2015-06-25 03:24:33 +00:00

(Migrated from github.com)

It isn't a silent error if it is well documented that passing in a window
name that doesn't exist will result in a size of 0 or -1 or similar default
value.
On Jun 24, 2015 9:59 PM, "omar" notifications@github.com wrote:

@adam4813 https://github.com/adam4813 I just remembered why functions
like GetWindowPos/GetWindowSize etc. didn't allow to pass in a name. The
reason is that I didn't know how to handle errors properly if the given
name didn't match an existing window.
It's ok to assert on incorrect code but I don't really want to assert on
incorrect data (or very rarely), especially here it's easy to imagine cases
where a window doesn't already exist. I could return a default value for
position/size (e.g. zero) but I don't fancy silent errors either. So I left
that unsolved and didn't add this parameter to the functions even though as
you pointed you it would be useful e.g. to manual center a window, without
juggling with next/current window functions.

If I get to implement the ID collision mechanism I envision in the future
perhaps imgui will have a non intrusive way to signal errors to the
programmer and then it might be a good place to log in a warning in those
cases.

—
Reply to this email directly or view it on GitHub
https://github.com/ocornut/imgui/issues/249#issuecomment-115085272.

It isn't a silent error if it is well documented that passing in a window name that doesn't exist will result in a size of 0 or -1 or similar default value. On Jun 24, 2015 9:59 PM, "omar" notifications@github.com wrote: > @adam4813 https://github.com/adam4813 I just remembered why functions > like GetWindowPos/GetWindowSize etc. didn't allow to pass in a name. The > reason is that I didn't know how to handle errors properly if the given > name didn't match an existing window. > It's ok to assert on incorrect code but I don't really want to assert on > incorrect data (or very rarely), especially here it's easy to imagine cases > where a window doesn't already exist. I could return a default value for > position/size (e.g. zero) but I don't fancy silent errors either. So I left > that unsolved and didn't add this parameter to the functions even though as > you pointed you it would be useful e.g. to manual center a window, without > juggling with next/current window functions. > > If I get to implement the ID collision mechanism I envision in the future > perhaps imgui will have a non intrusive way to signal errors to the > programmer and then it might be a good place to log in a warning in those > cases. > > — > Reply to this email directly or view it on GitHub > https://github.com/ocornut/imgui/issues/249#issuecomment-115085272.

ocornut commented

2015-06-25 03:49:42 +00:00

(Migrated from github.com)

That would be acceptable I suppose.
However just noticed that for pattern I was trying to cater for (GetWindowSize(name) followed by SetNextWindowPos) the named-get would necessarily fail on the first time the function is called (assuming the Begin is after SetNextWindowPos which makes sense). I think the named get are probably useful but I would like to identify a pattern where they are before just adding them, because right now we've got a functional SetPosCenter already.
A possibility left to do it without SetPosCenter (just because it is healthy to see if we can do it ourselves) is Begin, GetWindowSize (current), SetWindowPos() and that already works but it has a frame of lag hmm. Tricky. I'll put that aside and open a topic later if necessary. I know there's something fishy here but I don't have an immediate blocker to solve.

That would be acceptable I suppose. However just noticed that for pattern I was trying to cater for (GetWindowSize(name) followed by SetNextWindowPos) the named-get would necessarily fail on the first time the function is called (assuming the Begin is after SetNextWindowPos which makes sense). I think the named get are probably useful but I would like to identify a pattern where they are before just adding them, because right now we've got a functional SetPosCenter already. A possibility left to do it without SetPosCenter (just because it is healthy to see if we can do it ourselves) is Begin, GetWindowSize (current), SetWindowPos() and that already works but it has a frame of lag hmm. Tricky. I'll put that aside and open a topic later if necessary. I know there's something fishy here but I don't have an immediate blocker to solve.

ocornut commented

2015-06-27 02:43:04 +00:00

(Migrated from github.com)

Closing this. Note about TextWrapped and name-based Get Pos/Size helpers added in todo list.

Rows
Columns

Modal Dialogs #249

I tried to make them always recenter but it's particularly odd if you click somewhere and your mouse cursor is not over the same widgets as a result of the window moving.

One question left is should I recenter them on subsequent apparition or keep the last position? (if you allowed the window to be moved).

I tried to make them always recenter but it's particularly odd if you
click somewhere and your mouse cursor is not over the same widgets as a
result of the window moving.

One question left is should I recenter them on subsequent apparition
or keep the last position? (if you allowed the window to be moved).