Replies: 8 comments 4 replies
-
My only concern is related to #126, so that variadic arguments in C cant be given as a variadic in C++ without |
Beta Was this translation helpful? Give feedback.
-
I would like to have struct variant available as I want to remember all the styling info in ONE variable and be able to shove it into any plot. It's nice If that struct has a fancy constructor with variadic template but only if it doesn't introduce hit on the build times. |
Beta Was this translation helpful? Give feedback.
-
I feel like the proposed API is really good: on one hand, it finally adds the struct parameter that many users were asking for so long. This simple addition might allow some users to cache or reuse a However I'd like to propose making all the |
Beta Was this translation helpful? Give feedback.
-
Variadic template arguments hide types. IDEs are unable to provide contextual information in these cases. It would force users unfamiliar with codebase to visit a documentation site to get information that normally would be available in auto-complete. I personally would just use |
Beta Was this translation helpful? Give feedback.
-
I like the c++ api and think it would map well to python, but requires a struct api to do so because I can't instantiate all the template combinations 🙈. But I can parse the python argument list and build up a struct. I partially agree with @rokups but that is a general c++ template problem. C++ beginners struggle with templates but with good annotation/comments in source/headers its easy to use for intermediates and up |
Beta Was this translation helpful? Give feedback.
-
I bumped into a vaguely relevant issue just now. I am working on a thing written in python so i wrapped implot with SWIG. Everything seemed to work initially, but eventually application started crashing for no apparent reason. Edit: |
Beta Was this translation helpful? Give feedback.
-
I have implemented this functionality in #519. Would appreciate some eyes on this before landing (@PeterJohnson, @sergeyn, @sonoro1234, @rokups, @marcizhu , @ocornut) Cheers! |
Beta Was this translation helpful? Give feedback.
-
A bit late to the party, but what might be nicer would be to use types rather than an enum to distinguish between the parameters. This avoid having to ensure we have only pairs of parameters. It also explicitly links the type and the value, which simplifies the error if they don't match, and I think make the code more readable. It should also help the IDE with auto-completion. The drawback is that the implot code itself is more complicated (need to define the types and possibly their constructors, need one function per parameter rather than a single struct ImPlotSpec_LineColor {
constexpr ImPlotSpec_LineColor() {}
constexpr ImPlotSpec_LineColor(float _x, float _y, float _z, float _w): color{_x,_y,_z,_w} {}
const ImVec4 color{IMPLOT_AUTO_COL};
};
struct ImPlotSpec_LineWeight {
const float weight;
};
struct ImPlotSpec_Size {
const float size;
};
struct ImPlotSpec {
ImVec4 LineColor{IMPLOT_AUTO_COL};
float LineWeight{1.0f};
float Size{4.0f};
template <typename ...Args>
constexpr ImPlotSpec(Args ...args) {
SetProps(args...);
}
constexpr void SetProps() {}
template <typename Arg, typename ...Args>
constexpr void SetProps(Arg arg, Args ...args) {
SetProp(arg);
SetProps(args...);
}
constexpr void SetProp(const ImPlotSpec_LineColor &v)
{
LineColor = v.color;
}
constexpr void SetProp(ImPlotSpec_LineWeight v)
{
LineWeight = v.weight;
}
constexpr void SetProp(ImPlotSpec_Size v)
{
Size = v.size;
}
};
void PlotLine(..., const ImPlotSpec &spec) {
...
}
PlotLine(..., {ImPlotSpec_LineWeight{100}, ImPlotSpec_Size{1000}, ImPlotSpec_LineColor{1,2,3,4}}); |
Beta Was this translation helpful? Give feedback.
-
ImPlot has always attempted to mimic ImGui's API design as much as possible. I generally think that's been a good decision, but one area where I feel we may have taken this too far is in styling plot items. We currently offer two patterns lifted from ImGui:
or
Not only is that a bit verbose and strange if you're coming from other plotting libraries, but it is currently limiting the extent to which items can be customized with additional arguments (see #298, #321, #185, #248). In particular, there are some cases where item styling should be based on buffers of data (e.g. marker sizes or colors #298), and I don't think either API above lends itself well to that need (e.g.
ImPlot::SetNextMarkerStyle(const float* sizes, const ImVec4* colors)
is a bit smelly).I would love to just put all styling arguments in the function call to
PlotX
, but having a bunch of default args or overloads isn't very attractive either. Passing a styling struct is of course an easy solution, but like I noted in the Setup API proposal (#272), this is IMHO not the ImGui way.I think the best design would be one that directly mimics
MATLAB
and/ormatplotlib
, where styling arguments can be passed in any order or quantity:MATLAB's style can be emulated in C++ using varadic template args and recursion:
Finally, we can do the following:
And with a little bit more effort using compile time string hashing, we could even do the following wihtout any runtime cost:
You may notice we needed a struct argument in the end after all. That's not necessarily bad, since it enables those who prefer it and would be needed for C binding generators.
I'm not 100% sold on this idea yet, but perhaps somewhere in all this is a better solution than what we currently have. I'd love to get the community's feedback on this, or hear other ideas.
Cheers!
Looping in the usual suspects: @marcizhu @ocornut @rokups @bear24rw @PeterJohnson @hoffstadt @ozlb @sergeyn @mindv0rtex @JoelLinn @sonoro1234 @JaapSuter @ChiefyChief23 @leeoniya
Beta Was this translation helpful? Give feedback.
All reactions