Dear all, the main reason I liked the "foreign block" approach suggested by Jack is that, if it is coupled with the right documentation (with neat examples showing clearly gretl users what they must do in practice to produce fancy graphs), it can actually improve a lot the interaction between gnuplot and gretl in a rather simple way, cause it can give the right incentives to users to improve their knowledge of gnuplot.
This is my own experience on the "graphics" issue. As it is now, the relation between gretl and gnuplot is a "secret marriage" (well, not even a marriage. It is like the little Gretl is having sex with Gnuplot while the giant is sleeping and do not even care of what is going on...). As said by Jack, most of the users, thanks to Allin, do not even know that their plots in gretl are produced by gnuplot. Yes, the guide tells you that gretl uses gnuplot to draw graphs and you can always produce fancier stuffs using your data directly in gnuplot and the interested reader is referred to the gnuplot documentation... And the interested reader is left alone in the dark ;-) Well, actually so far what I have done is simply exporting my results in R, Stata or Matlab to draw my graphs. Why? Basically, cause if I need to take my data out of gretl, I naturally tend to rely on what I already know... According to me, the best way is: - leave the "gnuplot" command as it is know to the simpler stuffs; - create a foreign block to fully use the potential of gnuplot (by the way, if something is there it does not mean that you can explain it to your colleagues...). Instead, I do not like too much the idea of the plot environment cause it seems half in between the full control given by the foreign block and the clean and simple control for ready-to-use plots given by the gnuplot command. Bye Giuseppe On Fri, 2014-10-10 at 11:11 +0200, Riccardo (Jack) Lucchetti wrote: > On Fri, 10 Oct 2014, Sven Schreiber wrote: > > >> After all, if you really really want to do > >> really really complex things, you'd probably want to export your data > >> and start from scratch with something else. And besides, you can always > >> use the --input switch. > > > > Again, I agree in principle. OTOH I think many people (including me) > > like the inline way of controlling everything from a single script file. > > So it was good to be able to supply literal gnuplot commands inline > > inside curly braces. > > That's a matter of taste. If I had to produce some very complex output, > I'd rather write a function for producing the corresponding gnuplot > script, save it into a temporary location, and then invoke gnuplot with > the --input option. This can be done from a single script, without having > to issue a monster-like, 20-lines literal appenidx to the gnuplot command. > > >> So that would leave the stripped-dow version of the gnuplot command and > >> the new "plot" environment. > > > > I'm now thinking, why actually stripping down the gnuplot command? This > > would mean to scrap stuff which is working nicely, mostly. Of course the > > way that the command is described in the docs could be adjusted in order > > to encourage other usage. But stripping down the functionality would > > seem to have no real benefit. > > Well, for cleanliness, mostly; code maintainability etc. > > > ------------------------------------------------------- > Riccardo (Jack) Lucchetti > Dipartimento di Scienze Economiche e Sociali (DiSES) > > Università Politecnica delle Marche > (formerly known as Università di Ancona) > > r.lucchetti(a)univpm.it > http://www2.econ.univpm.it/servizi/hpp/lucchetti > ------------------------------------------------------- > _______________________________________________ Gretl-devel mailing list > Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel
