Re: Library version of gnuplot [was: gnuplot projects, terminal modules]

[Daniel J S. <dan...@ie...>]

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?


>>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.


> 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.


>>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.

> 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