Updating backend ImGui/ImPlot/ImNodes to latest versions

[SamuMazzi]

---

name: Updating backend ImGui/ImPlot/ImNodes
about: Updated backends
title: Updating backend ImGui/ImPlot/ImNodes
assignees: ''

---

Description

This PR aims to update the Im* backends of DPG to way more recent versions.
Currently DPG relies on ImGui 1.83 (last commit around May 2021), ImPlot 0.11 (always around that date) and ImNodes (which is the less updated). With this PR we'll have ImGui 1.90.6 and ImPlot 0.17 (for the major updates see below).

Background: ImGui is currently sponsored by big tech companies like Adobe, Blizzard, Activision, etc. so we can expect a lot of improvements with the update (there are already ton of them) and we can expect a lot of people working on the really ugly/hard things like graphical backend libraries.

Why?

In my workplace we are about to ship a product based on DPG. Because of my job, I had to edit the backend and then I found out that what I edited was already modified in the new ImGui and then I also found out that the ImGui version we were relying on in DPG was really old.
We want to stick with this library but I honestly told them that I don't see the point of relying on an almost dead (okay, no, maintenance mode) library, so we decided to either upgrade it or drop it and replace it with something else.

I know that this is quite a huge change, and that several problems can arise but I also think that it can be definitely worth it. Also with this huge community all of these changes can be "easily" tested.

Changes

If you want to take a look to the original releases you can find them here for ImGui and here for ImPlot
You'll probably find better explanations (and images/videos) of what I'm gonna tell you below.
(Keep in mind that many other improvements have been made, but these are the most important ones in my opinion)

OpenGL

(This has been on of the hardest problem to solve actually)
Currently, for the build, DPG relies on gl3w in the examples folder of ImGui. This doesn't sound like a really stable thing and indeed a couple of releases later, that's been removed, so I added gl3w directly in the thirdparty folder.
Also ImGui decided to make some heavy changings in order to be more cross-platform. One of these, which is also my biggest concern about all of this work, is about the buttons of the keyboard. These are now less than before, and they have been all mapped to predefined values in ImGui. So if someone used them heavily now they could have some problem.

Issues solved (afaik)

• Fix destroy_context doesn't clean up the window #2173, Window freezes when using stop_dearpygui #2013, Viewport stuck after closing when executing blocking instructions afterwards on MacOS #1593 (last 2 issues are closed but not solved, but they are all related)
• Fix add_text_point raises exceptions even when used with only required inputs #2108
• Fix dpg.set_axis_limits just lock the axis min limit and let the max limit be free (+vice versa) #2016

New Features

• For all the Drag* widgets there are new parameters delayed, no_cursor, no_fit, no_inputs
• Now there can be 3 X axes other than the currently supported 3 Y axes
• Plots: now you can decide a _mod button to enable certain actions only when that button is pressed (i.e. select, zoom, override, etc...) and you can also decide the zoom rate
• New StackToolWindow
• Plots: many parameters have been added to each kind of plot
• Plots: new series like Infinite line series (just a wrapper for Vertical and Horizontal line series), Digital Series, Group Bar Series
• Plots: New way to query the plots (take a look at the demo)
• Plots: new functions set_axis_limits_constraints() and set_axis_zoom_constraints()
• Plots scale: there are currently four scales for the axes' plots, but more will be added and in the roadmap there's the goal to implement, like in ImGui, a custom callback scale.
• dpg.add_plot_tag(): now there can be tags attached to the axes
• New widget: SeparatorText()
• Several updates to tables (some of them still have to been implemented)
• CTRL + Tab navigation across windows
• New params for InputText
• New params for dpg.add_window()
• New params to dpg.add_legend()
• More params for ColorMapScale
• Add recursive mode to filter_set (beta)
• New param "disabled" for dpg.add_group() (equivalent of new feature ImGui::BeginDisabled())

Breaking changes

• get_plot_query_area() deprecated in favour of get_plot_query_rects()
• New mvStyleVar options
• When adding new axes now you need to specify which ones (i.e. dpg.add_plot_axis(mvXAxis2))
• Now all the lines will automatically have AA
• Added several params to dpg.add_child_window()
• mvVLineSeries and mvHLineSeries are deprecated in favour of mvInfLineSeries

Changes expected in the future from ImGui

• Test engine
• Window shadows
• Shortcuts API

Major concerns

• As I said earlier, now there are less keyboard buttons than before, I think that they'll add more in the future, but I don't know how to solve this problem.
• In my workplace we have never used ImNodes so we haven't tested that a lot. There haven't been any huge updates during these years so there shouldn't be a lot (or any) problems. If someone's willing to help and take a look, they'd be welcome.

Notes

Everything was tested with Valgrind in order to be sure that there wasn't any kind of accidental memory leak (or at least not more than those who were already there).

Don't look at the README.md and TODO.md, it's nothing but development garbage, it'll be removed when merged. In case you'll read the TODO you'll see that there are still many (not too many) things to do. These are all new features and I'd say, almost all little ones, or difficult to implement, so they can actually be implemented later in the future.

My main goal here was to have a real feedback from the most expert users on this work.

I hope I was clear enough!
I'd like to improve this library because I think it's really great, so any kind of suggestion will be well accepted.

[v-ein]

wouldn't make it more sense to delete the first rect, like in a FIFO queue, when max_query_rects is reached?

I also considered this approach but it's probably less obvious for the user when he draws one rect, two, three, a dozen and then the first one disappears. The user's attention will probably be on the last rectangle and not on the first one (the first one might already be scrolled away). But, well... who knows :). We could even add an option to control the behavior of the query when the max is reached, but won't that be an overkill?..

[SamuMazzi]

Yes but then the user won't be able, in any way, to delete all the other rects... anyway no I wouldn't add another option so I'll stick to your version

[SamuMazzi]

@v-ein I should have also found a way to fix issues #1847 #2363 and others related similar to those.
It seems to work for what's concerning my tests, but I don't know if it should go inside another PR

[v-ein]

but I don't know if it should go inside another PR

Let's do it in a separate PR. This one is close to completion, let's not add any more stuff.

[v-ein]

Not sure what to do with the commit 1e99e3f... Can you try the following sequence?

1. In your repo, add a tag to the current head of the porting branch (or add another temporary branch, just to keep that chain of commits in the repo). Make sure that this tag/branch gets pushed to GitHub (or you can create it right there on GitHub).
2. In your local copy, delete the local porting branch (do not delete the remote branch).
3. Re-create the local porting branch on commit 1c3db32. GitHub will still have remote porting branch pointing to 1e99e3f at that moment.
4. Try to push your local porting branch. If needed, use --force (I'm sure it will be needed). If it works, this will move porting on GitHub to 1c3db32. Most probably it won't work though.

I'd recommend to do all that on a separate clone of your repo (not on the copy you use for bugfixing). Technically, steps 1-3 are absolutely safe for your GitHub repo. Step 4 is more of an experiment, but since the branch or tag added in step 1 holds a reference to 1e99e3f, the current chain of commits will not be lost. Worst case you'll get another series of commits (a duplicate) in your fork; best case porting will just jump back to 1c3db32.

[SamuMazzi]

It didn't work even if I managed to create the tag... can I actually just try to delete the modification (some kind of git reset) and keep the modifications locally? Then when the PR will be accepted I'll create another one with this one!

[v-ein]

You mean, add another commit that rolls back the changes? Yes, that's one of the ways to do it. Least preferrable, but if other ways don't work... well.

some kind of git reset

That's exactly what I wanted to do: to move the porting branch back by 1 commit so that it doesn't include these changes. Or did you mean git revert?

[SamuMazzi]

Did it! I had to force-push but I have the changes locally so no problem I'd say

[v-ein]

Replying to an earlier comment that I only now got a chance to check:

This one seems to always evaluate to true that hovered variable and so it deletes the last rect. Try and tell me pls.

With the latest commit, seems to be working fine for me. Whichever query rect I double click, that rect gets deleted, not the last rect.

[v-ein]

Would you please also look at this comment - it's feeling a bit forlorn:
#2275 (comment)

[v-ein]

I'm done with my final pass of code review. Several things (mentioned in recent comments) still need to be fixed. Also, we need to make sure that the PR description contains some text to be used as Release Notes.

One more thing that bothers me is that there's going to be a merge conflict when the PR gets closed. To prevent it (or, better, to help Jonathan and relieve him from the need to resolve that conflict 😂), we can merge current master into the porting branch (resolving the conflict at this point). This guarantees that there won't be a conflict when porting gets merged back to master.

The conflict is trivial and is caused by changes to draw_rect arguments in dearpygui.py; we need to accept the version from this PR and ignore the version from master (since the PR provides a correct and up-to-date solution based on DEPRECATE_KEYWORD option).