Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2007-06-19 18:24:21
|
I'll be tuning out from the list for now... My thoughts are that gnuplot development could use some fresh people to keep it going. The summers used to be fairly productive, but now not much happens even then. Should open an invitation for a few more administrators or whomever's role it is to sort through patches and chart a course for what needs attention. One or two people doing that isn't enough on a voluntary basis. There are plenty of ideas for new stuff (multiple keys, better 3D/2D layout and use of margins, etc.). My sense is that people are willing to contribute but become discouraged when patches sit on SourceForge indefinitely. Also, it might be good to review this kind of thing after each release, i.e., Will another release be warranted? What new features, if any, should be in a future release? Are there enough active contributors and administrators to get there in the course of a year or two? Regards, Daniel |
|
From: <tim...@en...> - 2007-06-19 19:52:30
|
Daniel J Sebald wrote: > I'll be tuning out from the list for now... My thoughts are that gnupl= ot development could use some fresh people to keep it going. The summers= used to be fairly productive, but now not much happens even then. Shoul= d open an invitation for a few more administrators or whomever's role it = is to sort through patches and chart a course for what needs attention. = One or two people doing that isn't enough on a voluntary basis. There ar= e plenty of ideas for new stuff (multiple keys, better 3D/2D layout and u= se of margins, etc.). My sense is that people are willing to contribute = but become discouraged when patches sit on SourceForge indefinitely. Als= o, it might be good to review this kind of thing after each release, i.e.= , Will another release be warranted? What new features, if any, should be= in a future release? Are there enough active contributors and administra= tors to get there in the course of a year or two? > > Regards, > > Daniel > =20 Hi Daniel, For what is worth, I don't think the situation is hopeless, but I=20 understand how you feel. The same happens for many open-source projects, = apart from the most trendy ones, and it heavily depends on the history=20 of the project. For one thing, gnuplot being very old, some parts have=20 not been touched for long. gnuplot is highly portable, which is a good=20 thing but also a thing to take care of. Anyway, that's not what you=20 express here. I would personally love to review your patches if I had=20 more time, and it will hopefully happen after my examinations, i.e. next = week. I can for sure review the history ones, but I'm afraid I won't be=20 able to understand much of the hidden3d one unless I devote a lot of=20 time to it... until now I've carefully stayed away from the graphic core = functions in gnuplot. As far as contributions and administration is concerned, my feeling is=20 that Ethan has been doing a great job lately. Of course, this doesn't=20 mean that he can be everywhere every time. To me, the biggest differences between trendy projects that seem to be=20 very dynamic and gnuplot today are: -few people have CVS commit rights, whereas the politic for kde (for=20 example) is to give commit access almost immediately after the first=20 patch. Other projects work like gnuplot, with a very small group of=20 commiters, like compiz, but the latter also has a plugin architecture,=20 and those plugins are written and modified by lots of people. Should=20 more people get CVS access to gnuplot ? Why not. Apart from you, Daniel, = I don't see major and regular contributors that don't have CVS access.=20 Anyway, having the right to commit doesn't mean that one should commit=20 immediately anything. Staying a while on Sourceforge is a good thing, at = least it gives the time to think about the best solution. So the real=20 question is : why aren't there more contributors ? -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The target = audience is quite heavily restricted to scientists, programmers and=20 system administrators. In the scientists part, those who may be=20 interested in gnuplot are those who aren't afraid of the command-line,=20 those who are used to program or to use a shell, and those who are not=20 addicted to Matlab but to LateX. Programmers and sysadmins tend to use=20 gnuplot to plot stats and profiles, gnuplot is probably well suited for=20 those people. All in all, I think gnuplot has a small target audience,=20 and only a small subset of this audience tend to contribute. -there are a few alternatives to gnuplot (python, ...) so not all of the = target audience ends up using gnuplot. And that's fortunate, diversity=20 is good. -apart from the regular command-line use case, gnuplot architecture=20 isn't that flexible. Most works to use gnuplot from another application=20 are either hacks or are not well integrated, so it's not satisfying for=20 other projects that need a plotting engine. -gnuplot license discourages new contributors. This license obviously=20 doesn't help in protecting gnuplot today. It prevents from sharing=20 precious code with others. It results in doubt about the future of=20 gnuplot, since because of this license, gnuplot is tied to its original=20 authors, who are now completely out of the development process. To address these problems and improve the situation, few but radical=20 changes are needed: -make gnuplot core available as a library (including all its=20 file/printers terminals, and adapted screen terminals, so that they can=20 be used as widgets inside other apps). It implies to disentangle the command-line parser from the routines, and = identify a sensible API. It's a lot of work. -contact identified contributors/rewrite parts of gnuplot to change the=20 license, to something reasonable (core LGPL, frontend GPL). This is a=20 huge lot of work, but that would definitely worth it. As far as=20 rewriting parts, it could a good time to think about external=20 libraries/tools. I'm thinking of doxygen for the help formatting,=20 flex/bison for the parser. I think we would need to distribute the jobs=20 between several of us, and slowly get them done. I hope one day those two points will be marked as done. Most of the=20 time, this kind of threads end up being unproductive, but I hope your=20 mail and this one can help to start the process. Best regards, Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2007-06-21 22:04:32
|
Yes, here it works in such a way that someone wishing to push his feature into gnuplot is becoming a developer... and that one with many patches has a right to cvs ... Daniel, just you haven't wished so. > -few people have CVS commit rights For pushing a feature, from time to time we "ask" on this mailing list what to submit now from the Patches. So someone must be active to push... > -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The target > audience is quite heavily restricted to scientists, programmers and > system administrators. In the scientists part, those who may be > interested in gnuplot are those who aren't afraid of the command-line, > those who are used to program or to use a shell, and those who are not > addicted to Matlab but to LateX. Programmers and sysadmins tend to use > gnuplot to plot stats and profiles, gnuplot is probably well suited for > those people. All in all, I think gnuplot has a small target audience, I've just came from a crystallography workshop ... there I was surprised by an acknowledgment to gnuplot by one speaker. When asked, she said her boss convinced her to use gnuplot and he was right :-) > -apart from the regular command-line use case, gnuplot architecture gnuplot is just for fast drawing > -gnuplot license discourages new contributors some people don't care too much -- if they like the project, they help > -contact identified contributors/rewrite parts of gnuplot to change the > license, to something reasonable (core LGPL, frontend GPL). This is a > huge lot of work, but that would definitely worth it. As far as I don't see any benefit of rewriting gnuplot. BTW, what could be done, is to write down a project subject, and submit it for a bachelor thesis for an informatics student. (Well, most of them have never drawn any graph from data...) --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-21 23:45:27
|
On Thursday 21 June 2007 15:04, Petr Mikulik wrote: > I've just came from a crystallography workshop ... there I was surprised by > an acknowledgment to gnuplot by one speaker. When asked, she said her boss > convinced her to use gnuplot and he was right :-) Heh. I also saw gnuplot used in a crystallography presentation recently, in a totally unexpected way. The presenter had recorded diffraction images from a non-monochromatic X-ray beam on a CCD detector. Successive images were separated by a very small angular rotation of the crystal. The CCD images were plotted in gnuplot using some variant of "plot with image" and output as an animated gif. This made a nice movie showing the displacement of individual Bragg reflections on the detector surface as the crystal rotation gradually shifted the wavelength accepted by Bragg's Law. -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-06-22 08:34:24
|
> I also saw gnuplot used in a crystallography presentation recently, > in a totally unexpected way. The presenter had recorded diffraction > images from a non-monochromatic X-ray beam on a CCD detector. > Successive images were separated by a very small angular rotation of > the crystal. The CCD images were plotted in gnuplot using some variant > of "plot with image" and output as an animated gif. This made > a nice movie showing the displacement of individual Bragg reflections > on the detector surface as the crystal rotation gradually shifted the > wavelength accepted by Bragg's Law. Yes, I did something similar for a rocking imaging. Usually with zimg + convert/gifsiecle. With gnuplot the image processing is slower, but needed when real axes around the image were necessary. --- PM |
|
From: Dr. J. Z. <joh...@ze...> - 2007-06-27 20:09:21
|
Hi, seems that gnuplot is heavily used by crystallographers. I just thought I'll let you know that me too worked in crystallography some years ago ... ;-) -- Dr. Johannes Zellner <joh...@ze...> 2007/6/22, Ethan Merritt <merritt@u.washington.edu>: > On Thursday 21 June 2007 15:04, Petr Mikulik wrote: > > I've just came from a crystallography workshop ... there I was surprised by > > an acknowledgment to gnuplot by one speaker. When asked, she said her boss > > convinced her to use gnuplot and he was right :-) > > Heh. > I also saw gnuplot used in a crystallography presentation recently, > in a totally unexpected way. The presenter had recorded diffraction > images from a non-monochromatic X-ray beam on a CCD detector. > Successive images were separated by a very small angular rotation of > the crystal. The CCD images were plotted in gnuplot using some variant > of "plot with image" and output as an animated gif. This made > a nice movie showing the displacement of individual Bragg reflections > on the detector surface as the crystal rotation gradually shifted the > wavelength accepted by Bragg's Law. > > -- > Ethan A Merritt > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Daniel J F. <dan...@im...> - 2007-06-19 21:59:07
|
Hi, I would be interested in started developing for gnuplot, but find =20 where to start a bit daunting. Maybe some mentoring of new developers =20= with simple targets might be a good idea. Is there some sort of =20 'introduction to gnuplot dev' docs? Dan. On 19 Jun 2007, at 20:45, Timoth=E9e Lecomte wrote: > Daniel J Sebald wrote: >> I'll be tuning out from the list for now... My thoughts are that =20 >> gnuplot development could use some fresh people to keep it going. =20= >> The summers used to be fairly productive, but now not much happens =20= >> even then. Should open an invitation for a few more =20 >> administrators or whomever's role it is to sort through patches =20 >> and chart a course for what needs attention. One or two people =20 >> doing that isn't enough on a voluntary basis. There are plenty of =20= >> ideas for new stuff (multiple keys, better 3D/2D layout and use of =20= >> margins, etc.). My sense is that people are willing to contribute =20= >> but become discouraged when patches sit on SourceForge =20 >> indefinitely. Also, it might be good to review this kind of thing =20= >> after each release, i.e., Will another release be warranted? What =20 >> new features, if any, should be in a future release? Are there =20 >> enough active contributors and administrators to get there in the =20 >> course of a year or two? >> >> Regards, >> >> Daniel >> > > Hi Daniel, > > For what is worth, I don't think the situation is hopeless, but I > understand how you feel. The same happens for many open-source =20 > projects, > apart from the most trendy ones, and it heavily depends on the history > of the project. For one thing, gnuplot being very old, some parts have > not been touched for long. gnuplot is highly portable, which is a good > thing but also a thing to take care of. Anyway, that's not what you > express here. I would personally love to review your patches if I had > more time, and it will hopefully happen after my examinations, i.e. =20= > next > week. I can for sure review the history ones, but I'm afraid I =20 > won't be > able to understand much of the hidden3d one unless I devote a lot of > time to it... until now I've carefully stayed away from the graphic =20= > core > functions in gnuplot. > > As far as contributions and administration is concerned, my feeling is > that Ethan has been doing a great job lately. Of course, this doesn't > mean that he can be everywhere every time. > > To me, the biggest differences between trendy projects that seem to be > very dynamic and gnuplot today are: > > -few people have CVS commit rights, whereas the politic for kde (for > example) is to give commit access almost immediately after the first > patch. Other projects work like gnuplot, with a very small group of > commiters, like compiz, but the latter also has a plugin architecture, > and those plugins are written and modified by lots of people. Should > more people get CVS access to gnuplot ? Why not. Apart from you, =20 > Daniel, > I don't see major and regular contributors that don't have CVS access. > Anyway, having the right to commit doesn't mean that one should commit > immediately anything. Staying a while on Sourceforge is a good =20 > thing, at > least it gives the time to think about the best solution. So the real > question is : why aren't there more contributors ? > > -gnuplot isn't eye-candy, so it doesn't make the crowd crazy. The =20 > target > audience is quite heavily restricted to scientists, programmers and > system administrators. In the scientists part, those who may be > interested in gnuplot are those who aren't afraid of the command-line, > those who are used to program or to use a shell, and those who are not > addicted to Matlab but to LateX. Programmers and sysadmins tend to use > gnuplot to plot stats and profiles, gnuplot is probably well suited =20= > for > those people. All in all, I think gnuplot has a small target audience, > and only a small subset of this audience tend to contribute. > > -there are a few alternatives to gnuplot (python, ...) so not all =20 > of the > target audience ends up using gnuplot. And that's fortunate, diversity > is good. > > -apart from the regular command-line use case, gnuplot architecture > isn't that flexible. Most works to use gnuplot from another =20 > application > are either hacks or are not well integrated, so it's not satisfying =20= > for > other projects that need a plotting engine. > > -gnuplot license discourages new contributors. This license obviously > doesn't help in protecting gnuplot today. It prevents from sharing > precious code with others. It results in doubt about the future of > gnuplot, since because of this license, gnuplot is tied to its =20 > original > authors, who are now completely out of the development process. > > To address these problems and improve the situation, few but radical > changes are needed: > > -make gnuplot core available as a library (including all its > file/printers terminals, and adapted screen terminals, so that they =20= > can > be used as widgets inside other apps). > It implies to disentangle the command-line parser from the =20 > routines, and > identify a sensible API. It's a lot of work. > > -contact identified contributors/rewrite parts of gnuplot to change =20= > the > license, to something reasonable (core LGPL, frontend GPL). This is a > huge lot of work, but that would definitely worth it. As far as > rewriting parts, it could a good time to think about external > libraries/tools. I'm thinking of doxygen for the help formatting, > flex/bison for the parser. I think we would need to distribute the =20 > jobs > between several of us, and slowly get them done. > > I hope one day those two points will be marked as done. Most of the > time, this kind of threads end up being unproductive, but I hope your > mail and this one can help to start the process. > > Best regards, > > Timoth=E9e > > > ----------------------------------------------------------------------=20= > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-06-23 22:43:57
|
On Tuesday 19 June 2007 14:58, Daniel J Farrell wrote: >=20 > I would be interested in started developing for gnuplot, but find =20 > where to start a bit daunting. Maybe some mentoring of new developers =20 > with simple targets might be a good idea. Looking back on who has joined the project over the past several years, it seems that a common path into gnuplot development has been through improvement of specific terminal drivers, or contribution of new drivers. Each terminal is largely self-contained, the API is described in=20 =2E./term/README, and existing terminals serve as example code. Drivers currently under development: wxt - marked EXPERIMENTAL in 4.2 (lead developer: Timoth=E9e Lecomte) cairopdf - likely to go into CVS soon, but still could use a lot of testing and additional features (lead developer: Timoth=E9e Lecomte) aquaterm - in 4.2, but doesn't fully support recent features added to CVS such as transparency, image clipping, ... (lead developer: Per Persson) tikz - brand new, prototype circulated to mailing list but first version not yet on SourceForge. This looks to be the way forward towards supporting pdflatex. (lead developer: Mojca Miklavec) svg - I'd really like to see someone take on the task of adding mousing support to the svg driver. This would permit=20 server-side interactive graphs, which would be a totally new capability. No one is working on this that I know of, but see the contact info attached to Feature Request #1523116 "Allow mousing and zoom of embedded SVG plots" (lead developer: me I guess, although mostly I'm just fielding bug reports and suggested fixes from users) Old drivers that could use some updating, bug fixes, or extension: fig - see various bug reports on SourceForge (lead developer: none that I know of) win - probably needs updating for Vista, also needs updating to support recent features like transparency (lead developer: none that I know of) linux - this is a console-mode terminal driver, i.e. it can be used even if you are not running x11. It has two main drawbacks. (1) it uses libsvga, which requires root permission and in general is not very nice. (2) I've never managed to get it to work, although I see reports that other people use it. Other possible projects: Pick a bug from the SourceForge collection, and submit a patch that fixes it. Pick a patchset submitted to SourceForge by someone else, and test it thoroughly. Patches tested and endorsed by multiple people are much more likely to get moved into CVS. If the only one advocating for a patch is the person who wrote it, and it's not an obvious bug fix, then it may sit there for a long time before another champion comes along. Look through the feature requests on SourceForge, and re-start=20 discussion on the mailing list about whether we could or should implement it. Many of these are IMHO not worth pursuing, but some of them are simply waiting for a clever idea on how to implement it. Examples of the latter are 1506495 Parallel coordinate plot type 1359667 Make clickable graphics possible My personal list of things it would be nice to see added for an eventual version 4.4 or 5.0 includes =2D better internationalization support =2D uniform scaling of plot elements (e.g. font size, linewidth)=20 independent of the canvas size. Discussion of this has been scattered across the mailing list and comments on various bug reports and feature requests. I think implementation would be fairly easy; it just requires agreeing on the desired API and then working through the whole set of terminal drivers to hook up the new API to existing capabilities. =2D Modify term->image() code to pass a transformation matrix to the driver. Some terminals (post pdf svg wxt) can use the matrix to modify the image, which is a much better option than having the core code do it pixel by pixel. Your primary resource here for the core code would be Dan Sebald, plus whoever has the best handle on individual terminal capabilities. =2D additional demo files illustrating features that generate frequent questions on the newsgroup or elsewhere =2D modify the various interactive terminals (x11, wxt, win, aqua) to allow mousing of subplots within a multiplot figure =2D new plot types, but only if there is a scientific community that uses them already. Someone should look through the catalogs of plot types available in S+, R, matlab, etc to see if there are some obvious ones that are missing in gnuplot. =2D-=20 Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-06-25 18:22:44
|
> I would be interested in started developing for gnuplot, but find > where to start a bit daunting. Maybe some mentoring of new developers > with simple targets might be a good idea. I would see the most urgent patch to finish [ 1723715 ] Refresh plot or zoom without re-reading data because this it is required by the Octave community. If you push it into cvs, that would be a great start-up. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-25 18:43:46
|
On Monday 25 June 2007 11:22, Petr Mikulik wrote: > > I would be interested in started developing for gnuplot, but find > > where to start a bit daunting. Maybe some mentoring of new developers > > with simple targets might be a good idea. > > I would see the most urgent patch to finish > > [ 1723715 ] Refresh plot or zoom without re-reading data > > because this it is required by the Octave community. > > If you push it into cvs, that would be a great start-up. It would be, but this is not the simplest entry point into gnuplot development! But yes, I certainly welcome any help with testing or improving this patch. I have had virtually no feedback on how well it actually works in practice, and I am not an Octave user so I don't have a good feel for what is needed there. -- Ethan A Merritt |
|
From: Dr. J. Z. <joh...@ze...> - 2007-06-27 20:02:27
|
I'd also vote strongly for this patch. I'ts useful for all apps which write via a pipe to gnuplot both gnuplot commands and inline data. -- Dr. Johannes Zellner <joh...@ze...> 2007/6/25, Petr Mikulik <mi...@ph...>: > > I would be interested in started developing for gnuplot, but find > > where to start a bit daunting. Maybe some mentoring of new developers > > with simple targets might be a good idea. > > I would see the most urgent patch to finish > > [ 1723715 ] Refresh plot or zoom without re-reading data > > because this it is required by the Octave community. > > If you push it into cvs, that would be a great start-up. > > > --- > PM > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-27 21:15:08
|
On Wednesday 27 June 2007 13:02, Dr. Johannes Zellner wrote:
> I'd also vote strongly for this patch. I'ts useful for all apps which
> write via a pipe to gnuplot both gnuplot commands and inline data.
>=20
> 2007/6/25, Petr Mikulik <mi...@ph...>:
> >
> > I would see the most urgent patch to finish
> >
> > =A0 =A0 =A0 =A0 [ 1723715 ] Refresh plot or zoom without re-reading data
> >
> > because this it is required by the Octave community.
I've uploaded to SourceForge a second-generation version of=20
patch 1723715 "Refresh plot or zoom without re-reading data"
In default mode, it uses the new "refresh" mechanism if and only if
it is a 2D plot containing data flagged "volatile". That means either
data read from pseudodevice '-' or from a file with the the keyword
"volatile".
If the data is not volatile, or if there is some change in state that
requires re-reading the data, then it falls back to calling "replot"
instead. To test the mechanism without having to type data in by hand,
try
plot 'silver.dat' volatile with linespoints
Improvements since previous version:
=2D the code has been simplified a bit
=2D 'r' 'a' 'g' 'e' hotkeys tested and working
=2D autoscaling after zooming now works (except for image data)
=2D documentation
Known problems. Please help!
=2D I can't figure out how/where plots "with image" contribute to=20
autoscaling. Where in the existing code does this happen?
=2D Reversed axes are not handled correctly. The existing code for
reversed axes is a horrible tangle, which doesn't help any.
=2D My first attempts to implement refresh for 3D plots (set view map)
were a failure. More thought will be required. In principle
it should be sufficient to modify the code in plot3d.c and graph3d.c
in parallel to the already working changes in plot.c and graphics.c.
Note: We only need to support the subset of 3D plots with
"set view map". It turns out that these always use a reversed y axis.
So maybe I just need to get reversed axes working properly, and then
the 3D case will also start working.
=2D-=20
Ethan A Merritt
|
|
From: <HBB...@t-...> - 2007-06-27 22:34:59
|
Ethan Merritt wrote: > - I can't figure out how/where plots "with image" contribute to > autoscaling. Where in the existing code does this happen? AFAICS, it does it roughly the usual way, via macro axis.h:STORE_WITH_LOG_AND_UPDATE_RANGE(). Follow the 'update_axes' argument to plot_image_or_update_axes() to find it. > Note: We only need to support the subset of 3D plots with > "set view map". It turns out that these always use a reversed y axis. Well, it feels like I've preached against the way 'map' was implemented since day one. Nobody listened. Reversed axes were tricky, but still basically sane until the waters were muddied further by inventing another reason why some axis would be reverted, supposedly without the majority of the code noticing. But then it turned some parts of the code did have to notice. It took years to sort out that mess. Sort of. |
|
From: Petr M. <mi...@ph...> - 2007-06-28 07:22:58
|
> AFAICS, it does it roughly the usual way, via macro > axis.h:STORE_WITH_LOG_AND_UPDATE_RANGE(). Follow the 'update_axes' argument > to plot_image_or_update_axes() to find it. I remember, from the time of adding the "GPVAL_MIN_*" functionality, that the axis structure would deserve a min/max value as of time of plotting the graph, not mixed with "set range". Hans-Bernhard, haven't you thought of adding it? > > Note: We only need to support the subset of 3D plots with > > "set view map". It turns out that these always use a reversed y axis. > > Well, it feels like I've preached against the way 'map' was implemented since > day one. Nobody listened. I coded the "set view map", I've listened to your comments, but I had fear to hit your axes module. So the status is as is. > it took years to sort out that mess yes; and I was glad when it finally worked for all cases --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-28 19:57:17
|
On Thursday 28 June 2007 00:22, Hans-Bernhard Br=F6ker wrote: > > Well, it feels like I've preached against the way 'map' was implemented= since > > day one. Nobody listened. >=20 > I coded the "set view map", I've listened to your comments, but I had fea= r=20 > to hit your axes module. So the status is as is. >=20 > > it took years to sort out that mess >=20 > yes; and I was glad when it finally worked for all cases I was not around at that time, and don't know the history or intent of the axis.range_is_reverted flag. =20 Could someone enlighten me on how this is supposed to work? The current behaviour seems inconsistent, so I am having trouble trying to make the "refresh" code to behave equivalently. =46or example, the following pair of commands produce a mirror pair of plots: set yrange [-300:300] noreverse; plot 'silver.dat' set yrange [-300:300] reverse; plot 'silver.dat' But the following pair produce identical plots: set yrange [300:-300] noreverse; plot 'silver.dat' set yrange [300:-300] reverse; plot 'silver.dat' So I am confused. =20 Does "reverse" mean "interchange the requested min/max"? Or does it mean "force the min to be greater than the max"? The latter appears to be true, but in this case the flag seems very much mis-named. =46urthermore, some plot/replot/zoom operations appear to clear this flag; others do not. So I cannot count on the current state of the flag being the same as it was originally. This again poses a problem for "refresh". And that's before I even get to splot_map... =2D-=20 Ethan A Merritt |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-28 16:40:29
|
Petr Mikulik commented: >> (*) There is a strange thing/bug: >> unset grid >> plot ... volatile >> Now zoom several times, hit "g" for grid on, then hit "u" for >> unzoom => grid is lost. This does not happen with "u" in the >> other usage of the plot command. >> Yes. This is because the grid settings are stored as part of the individual axis structures. In the new "refresh" mode, when you "unzoom" the original axis settings are restored, which includes the old grid settings. By contrast, when you do a full "replot" command the axis structures are filled in all over again rather than being re-used. If this is a problem, I suggest that the proper answer is to move the grid settings out of (struct axis) into a new self-contained structure. I may be overlooking something, but I don't see why the grid needs to be a property of the axis at all. It should be sufficient to define two bitfields for toggling axis tics on/off. For example: extern int grid_majortics, grid_minortics; /* Set major but not minor tics for the y2 axis */ grid_majortics &= 1 << SECOND_Y_AXIS; grid_minortics |= ~(1 << SECOND_Y_AXIS); On Tuesday 19 June 2007 14:58, Daniel J Farrell wrote: > I would be interested in started developing for gnuplot, but find > where to start a bit daunting. Maybe some mentoring of new developers > with simple targets might be a good idea. Is there some sort of > 'introduction to gnuplot dev' docs? So here is a nice self-contained project you could start off with. - Remove the TBOOLEANs gridmajor and gridminor from the definition of struct axis in axis.h - Define the new bitfields, also in axis.h - Convert existing references from the old mechanism to the new - Check whether initialization of the new bitfields needs to be done in places like "reset". -- Ethan A Merritt |
|
From: <HBB...@t-...> - 2007-06-28 19:32:20
|
Ethan Merritt wrote: > If this is a problem, I suggest that the proper answer is to move the grid > settings out of (struct axis) into a new self-contained structure. I may > be overlooking something, but I don't see why the grid needs to be a > property of the axis at all. The grid effectively is a property of the axis, as can clearly be seen by the way we control it: the majority of grid options have a reference to some axis in their command syntax. We grid based on tics, which are elements obviously linked to an axis. As it is, drawing the grid needs a reference to the axis' tic definitions, its terminal mapping and lots of other things. In other words, it needs almost the entire axis struct. The axis struct is designed around the existing usage. Redraw is new, and poses new requirements. The axis struct will have to learn new tricks. Splitting it up into separate sub-structs for range, tics and grid options would be the right step to start with. That way, 'zoom' and friend can save/restore just the range, but leave grid settings alone. |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-06-28 19:55:22
|
On Thursday 28 June 2007 12:32, Hans-Bernhard Br=F6ker wrote: > Ethan Merritt wrote: >=20 > > If this is a problem, I suggest that the proper answer is to move the g= rid > > settings out of (struct axis) into a new self-contained structure. I m= ay > > be overlooking something, but I don't see why the grid needs to be a > > property of the axis at all. >=20 > The grid effectively is a property of the axis, as can clearly be seen=20 > by the way we control it: the majority of grid options have a reference=20 > to some axis in their command syntax. >=20 > We grid based on tics, which are elements obviously linked to an axis.=20 > As it is, drawing the grid needs a reference to the axis' tic=20 > definitions, its terminal mapping and lots of other things. In other=20 > words, it needs almost the entire axis struct. Clearly one needs to refer to the axis structure in order to know _where_ to draw the grid lines. But the issue Petr raised is the simpler question of whether to draw the grid lines at all. One doesn't need to know anything about the axis or tics in order to track that requirement. =46rom a user perspective, toggling the grid on/off from an interactive display seems much more akin to toggling the ruler than to changing the axis or tic properties. > The axis struct is designed around the existing usage. Redraw is new,=20 > and poses new requirements. The axis struct will have to learn new=20 > tricks. Splitting it up into separate sub-structs for range, tics and=20 > grid options would be the right step to start with. That way, 'zoom'=20 > and friend can save/restore just the range, but leave grid settings alone. I take your point, but I am not sure I follow what issue you are trying address. Are you thinking that a change to, say, the minitic spacing while zoomed should, or should not, be retained after unzoom? I have no objection to such sub-structures. But before carving the axis structure into pieces, we would need to decide which pieces are to persist across zooming and which ones are not. Anyhow, these issues are relatively minor compared to getting the refresh mechanism to work at all. Let me finish getting a working prototyp= e; then we can decide what aspects may need to be tweaked. =2D-=20 Ethan A Merritt |
