Package request: implot

[hmaarrfk]

Package name

implot

Package version

Newest

Package website

https://github.com/epezent/implot

Package availability

Source only

Additional comments

Similar to imgui, but helps with plots.

However, the recipe from for imgui scares me @Tobias-Fischer @traversaro. Do you two have any interest in packaging implot?

as well as the extremely important note from implot
https://github.com/epezent/implot

Extremely Important Note

Dear ImGui uses 16-bit indexing by default, so high-density ImPlot widgets like ImPlot::PlotHeatmap() may produce too many vertices into ImDrawList, which causes an assertion failure and will result in data truncation and/or visual glitches. Therefore, it is HIGHLY recommended that you EITHER:

Option 1: Enable 32-bit indices by uncommenting #define ImDrawIdx unsigned int in your ImGui [imconfig.h](https://github.com/ocornut/imgui/blob/master/imconfig.h#L89) file.
Option 2: Handle the ImGuiBackendFlags_RendererHasVtxOffset flag in your renderer if you must use 16-bit indices. Many of the default ImGui rendering backends already support ImGuiBackendFlags_RendererHasVtxOffset. Refer to https://github.com/ocornut/imgui/issues/2591 for more information.

Package is not available

• The package is not available on conda-forge.

No previous issues or open PRs

• No previous issue exists and no PR has been opened.

[traversaro]

However, the recipe from for imgui scares me @Tobias-Fischer @traversaro. Do you two have any interest in packaging implot?

I have no immediate interest in packaging implot directly, but what (in particular) is scary about imgui recipe? While I understand that the CMakeList.txt maintained in the recipe is a bit unusual, let me give a bit of context (from what I remember/understood). imgui upstream is not interested in mantaining CMake/shared library/packaging/ABI stability themself for various reasons (see ocornut/imgui#1469 (comment) and ocornut/imgui#7881 (comment)), so the CMake part is up to packagers/distro mantainers
, and also the ABI stability part (in conda-forge I think we can deal with it with the usual run_exports pinned to patch version).

For the imgui CMake recipe I think we took heavy inspiration from vcpkg (https://github.com/microsoft/vcpkg/tree/b4624c3a701b11248d88aab08744a37ee7aea1cc/ports/imgui). I guess we can do this also for implot: https://github.com/microsoft/vcpkg/tree/b4624c3a701b11248d88aab08744a37ee7aea1cc/ports/implot , that apparently links to vcpkg in its README: https://github.com/epezent/implot/blame/f156599faefe316f7dd20fe6c783bf87c8bb6fd9/README.md#L83, so I think we can say that upstream thinks that is a a sound approach.

I did not look into the ImDrawIdx thing, I need to understand if we can deal with that on the imgui conda package side.

[hmaarrfk]

Having compile time defines change the size of variables is scary to me aa it leads to binary incompatibility.

[traversaro]

Having compile time defines change the size of variables is scary to me aa it leads to binary incompatibility.

Sure, the nice thing in this case is that defines are defined by the imconfig.h file, so it is less probably that something goes wrong then if the build system is involved.

[hmaarrfk]

It also means to me that you can get incompatible requirements from downstream packages. In either case. You are correct, it is surmountable