> 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
>>>>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
>>>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
>> However, what I tend to see is that a 'libgnuplot' written in C could
>> 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,
>> 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);
>> 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.
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.