From: <tim...@en...> - 2007-03-09 00:18:50
|
> Timothée Lecomte wrote: >>>On Thursday 08 March 2007 04:53, Timothée Lecomte wrote: >>> >>> >>>>Another interesting comment was the lack of >>>>a powerful and broadly available (i.e. for many languages) plotting >>>>library. I think gnuplot could be modified to achieve this goals if its >>>>parser was written as a layer above a real API. It looks like it is >>>> what >>>>can be found in the TODO file: >>> >>>In my long-ago days, pre-gnuplot, I did a *lot* of programming with >>>graphics libraries, and to a lesser degree extending and maintaining >>>the libraries themselves. I cannot begin to tell you how much relief >>>I felt at being able to ditch all that and instead use a scriptable >>>tool like gnuplot. So my extensive experience with both approaches >>>leads me to believe that this desire for a library version is >>> mis-placed. >>>It *sounds* reasonable, but when you actually try to use it you find >>>out that from a programming perspective it is a worse alternative than >>>a scripted interface. >> >> >> You're probably right, you have much more experience than me in that >> domain. >> However, what I tend to see is that a 'libgnuplot' written in C could >> have >> bindings to whatever scripting language, including the fashioned python, >> ruby, and friends. > > Don't pipes work in all languages? Pipes are very different from bindings in my opinion. You still have to learn and use gnuplot syntax. > >>>The only possible advantage I see is the speed with which very large >>>data sets could be rendered. In the case of a library you don't have to >>>pipe the data between two separate executables. But if that were >>>sufficiently important we could implement it anyhow, admittedly in an >>>OS-specific manner, by shared memory regions. >>> >>>Furthermore, if you look at the most powerful visualization tools, >>>e.g. AVS, S+, Mathematica, you will notice they went the other direction >>>entirely. These are not libraries of routines that you call from >>>an application program. They are self-contained frameworks within >>>which you can embed your application. >> >> >> Maybe because to develop a business model around a proprietary plotting >> library. Companies tend to sell complete solutions instead. > > That's a good point, but if you think in terms of unix, the system is > designed as a bunch of utilities that intermix in various ways to suite > the user's own creative perspective on things. > > >> Also note that Mathemetica, Matlab, etc. are more for repetitive >> simulation/analysis tools. > > Same with gnuplot. Right, I was pointing out the other ones, below: > > >> What I had in mind was more the experimental >> side, with live acquisition and analysis. That's what LabView, >> LabWindows >> and other GPIB-oriented solutions (for those who don't know, GPIB is a >> standardized bus for scientific data acquisition) are written for. Those >> are basically programmation languages with graphic libraries, including >> plotting libraries. And they seem to quite popular. > > That can be done with gnuplot through a pipe, I think. True, but that's not a real binding. > > >>>So my personal evaluation of the proposal to make gnuplot a callable >>>library is that it would be a lot of work for almost no gain. >> >> >> Reusability. That would be the key word in such a project. For gnuplot >> features to be useful to more people, they have to be accessible in more >> ways that they are today. >> Currently, it's tricky to include a gnuplot graph in a data acquisition >> program (I mean in the same window, of course), > > There is a patch on SourceForge whereby the parent application need simply > pass an X window ID to gnuplot and the plot will be drawn in any window. > There is a nice demo in which all *.dem files are listed in a window, then > one clicks on the demo and it is run. There was a small hang up on moving > it into CVS; it had to do with the parent application and gnuplot both > wanting control of the mouse. That's what I call tricky. What I want is, for example, an app based on cairo, where I have a cairo context 'cr' where I could start plotting with something like: gnuplot_context * gnuplot_cairo_create_context(cr); gnuplot_set_borders(gnuplot_context,...); gnuplot_set_axis(gnuplot_context,...); gnuplot_plot(gnuplot_context, data); > >> it's unnatural to use >> gnuplot from another language than gnuplot native one (think python, >> ruby), and it's very difficult to build a useful general-purpose GUI on >> top of gnuplot (think xgfe). > > Even this I'm not so sure of. It is a matter of writing a object oriented > terminal driver. There is one based upon tkcanvas, but that was limited > by the features of tkcanvas. I think it is more a problem of the > difficulty of implementing a GUI in general. I assume you are talking > about something where one can drag titles and annotation around using the > mouse because that is the only sort of thing not really implemented. > > Dan I'm not thinking of moving things in the graph (though that's another interesting point of view), I'm thinking of a frontend to set up the plots as you want them. Something like Origin maybe. Best regards, Timothée |