Otherise, the list of charts is fairly impressive. I don't know if you mean that you are supposed to get the bytes from IPC, then render those oneself. You mentioned the gnuplot pipe, but I've not heard of it. I have a few features where the user can click on the legend to toggle charts, or hover points to get extra info.Įven if I would not have the UI interactivity over the displayed graph, I don't get how one is supposed to integrate it. I'm using QtCharts, and it's fine, and even has fancy animations for free, but I'm also looking for alternatives. My use case: I've done a GUI app with Qt, and has a few charts. How does one integrate it with a GUI toolkit? You meention Qt in your references, but I don't know why.Or allowing to click a line to highlight it. Care to elaborate? What I'm thinking is interacting with the graphic by allowing the user to hover a point and get a tooltip with details of a point, for example. What do you mean by interactive? I searched the docs for "mouse" or "click" and there is nothing.I've skimmed through the docs, and read the answers here, but I don't get a few things: It's going to take years to do what matplotlib does. My library has been there for less than 24 hours. It's an amazing library that's been there for 15 years. I strongly recommend using matplotlib (and matlab, and octave). No more, no less.Īs a side note, I have absolutely no intention to say this library competes with matplotlib at all as it is. Maybe you would take another direction with the library, but the whole document, including this section, discusses what the library does and doesn't without relying on gnuplot. In any case, there's a discussion about that in the documentation. For now, I'm mostly worried about making these plots show up as if you were working on matlab or matplotlib. It's only used by the stub OpenGL backend included as an example. In any case, these functions in the interface are mostly meant to indicate that that's the direction in which future backends should probably go. The main obstacle is that it takes years to write lots of backends that know what to do with those objects. It's actually easier than producing Gnuplot code. The part of feeding lines and polygons to OpenGL, Agg, or whatever, is not the main obstacle. And that implied I had to depend on commands, etc, rather than vertices. That's why I moved to a gnuplot pipe as a default backend, at least for now. These kinds of libraries need to run outside the main thread to make sense and some systems don't like that. The problem is OpenGL involved lots of problems I had not foreseen. Had I gone that path, then the interface would have these proper functions for vertices, etc. I considered making openGL the default backend at first. The interface is open to change, and these functions will certainly have to change in that direction. The backend interface does not work the way you mention. I think most people are being able to understand how the library works and what it does. This kind of feedback is very valuable because other people can only read the documentation for the first time once. I'll continue to adjust that little by little. I probably didn't express myself well enough. And if you consider the backends then, of course, there are dependencies and these might depend on the platform. Maybe it would be clearer to say it depends on backends more than it supports backends. You have a good understanding of how things are working. I hope it will get there eventually, but in it's current state it's still just Ke this as overly critical as this is a nice project and looks promising, but I think it's a bit disingenuous to say that Matplot++ supports generic backends and doesn't depend on any specific platform. Your README.md on the homepage doesn't mention gnuplot at all. I think you should make it more clear that at least in the current state, this is just a gnuplot wrapper. A truly generic and platform-independent plotting framework needs to have a lower-level abstraction like figure.py in Matplotlib, so backend developers can do device-independent rendering directly to a pixel buffer or canvas with e.g. The axes_objects are just constructing gnuplot commands and don't do any actual painting. Unless a generic backend implements the gnuplot language, backend_interface.h only handles vertices - it doesn't provide any interface for color, lineweight, text size, etc. I hope it will get there eventually, but in it's current state it's still just an interface to gnuplot. I hope you don't take this as overly critical as this is a nice project and looks promising, but I think it's a bit disingenuous to say that Matplot++ supports generic backends and doesn't depend on any specific platform.
0 kommentar(er)
