Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2007-03-08 12:53:13
|
Dear gnuplot enthusiasts, Since 4.2 is out, I would like to start discussing some things I have in mind for 4.3/4.4. First, I'd like to see the terminal module architecture that I proposed as a patch in sourceforge to settle: https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1571443&group_id=2055 There is a preliminary step chich is the acceptance of the first two patches (plugin1.diff and plugin2.diff) which rework the interactive commands of the terminal structure in order to make it more extensible. Currently, we have: term->waitforinput term->put_tmptext term->set_ruler term->set_cursor term->set_clipboard This is a nice interface for mousing-related commands, but as it was pointed out earlier, it is not easily extensible to new commands, since new entries have to be addded at the end of the term structure, and this can painful to maintain with the large amount of terminals that we have. Petr (if I remember correctly) proposed to add something like: term->interactive("some command") and it was objected that it adds another parsing layer... What I implement in the plugin1.diff and plugin2.diff is the an in-between interactive structure: term->inter->waitforinput term->inter->put_tmptext term->inter->set_ruler term->inter->set_cursor term->inter->set_clipboard so that non-interactive terminals just have term->inter = 0, making it easier to extend the terminal API for interactive commands. And in plugin2.diff, I move the ugly terminal-specific code in raise_lower_command() (command.c) to where it belongs, in the terminals. This is done by introducing: term->inter->raise_term_window I'd really like to commit this code, not to have to maintain it for too long. Then there is the modular terminal architecture that may deserve some more discussion. It's implemented in plugin5.diff and I'd be pleased to listen to your comments. See the patch page for details. What are my other short-term projects ? - commit the cairopdf terminal, eventually replacing the current pdf terminal. It is really working nicely. - after the modular terminal architecture has settled, I'd like to finish the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c". Instead of moving the "raise console" code into the core, it could be moved to a dummy terminal (like estimate.trm), which would be built as a module. Voilà! No more code duplication without adding a Xlib dependency on the core ! What are my long-term projects ? In a release article for 4.2 that was published in a french web site (http://linuxfr.org/2007/03/07/22168.html), the most frequent comment was that a GUI would be appreciated as an alternative to the script/command-line interface. 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: "longer term - break it into four layers: : low level graphics (some of term.c) : plotting code, reading the setshow.h global variables : parsing code - read a string, and parse and execute it : front end, interact with terminal / gui" So, I think I'll try to work on this. I have a couple of milestones in mind, starting from the rewrite of the term->options functions so that the parser is not called from the terminals. Then maybe extract an API for the set/show functions to separate them from the parsing code. Well, that's it. Don't forget to comment on the modular architecture, and thanks for reading. Best regards, Timothée |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-08 18:15:50
|
On Thursday 08 March 2007 04:53, Timoth=E9e Lecomte wrote: > Another interesting comment was the lack of=20 > 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. 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=20 sufficiently important we could implement it anyhow, admittedly in an OS-specific manner, by shared memory regions. =46urthermore, if you look at the most powerful visualization tools,=20 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. 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. =20 I would be much more interested in proposals to extend gnuplot in the other direction, allowing it to call user-provided application code. One example of this kind of thinking is patchset #588805 (the oldest patch still active on our tracker).=20 Ethan >=20 > "longer term >=20 > - break it into four layers: > : low level graphics (some of term.c) > : plotting code, reading the setshow.h global variables > : parsing code - read a string, and parse and execute it > : front end, interact with terminal / gui" >=20 > So, I think I'll try to work on this. I have a couple of milestones in > mind, starting from the rewrite of the term->options functions so that the > parser is not called from the terminals. Then maybe extract an API for the > set/show functions to separate them from the parsing code. >=20 > Well, that's it. Don't forget to comment on the modular architecture, and > thanks for reading. >=20 > Best regards, >=20 > Timoth=E9e =2D-=20 Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2007-03-08 23:40:50
|
I too had once imagined a library, mostly on the suggestion from someone else. But as time goes by the more I think gnuplot is fine the way it is as a script interpretter. Ethan mentioned the data/speed thing, which is true for large data sets. I mean, I'm not against the idea of a library, header files, etc. (have to figure out how header files will be organized and where to break up routines), but I think it would be wiser to add/fix features to the point of having a very mature, robust system. The combination of the two (scriptable and compilable library) is just too much to deal with on a part time basis. Dan Ethan Merritt 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. > > 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. > > 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. > > I would be much more interested in proposals to extend gnuplot in > the other direction, allowing it to call user-provided application > code. One example of this kind of thinking is patchset #588805 > (the oldest patch still active on our tracker). > > Ethan > > > > > > >>"longer term >> >>- break it into four layers: >> : low level graphics (some of term.c) >> : plotting code, reading the setshow.h global variables >> : parsing code - read a string, and parse and execute it >> : front end, interact with terminal / gui" >> >>So, I think I'll try to work on this. I have a couple of milestones in >>mind, starting from the rewrite of the term->options functions so that the >>parser is not called from the terminals. Then maybe extract an API for the >>set/show functions to separate them from the parsing code. >> >>Well, that's it. Don't forget to comment on the modular architecture, and >>thanks for reading. >> >>Best regards, >> >>Timothée > > -- Dan Sebald phone: 608 256 7718 email: daniel DOT sebald AT ieee DOT org URL: http://webpages DOT charter DOT net/dsebald/ |
|
From: Daniel J S. <dan...@ie...> - 2007-03-08 23:55:13
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-08 20:09:14
|
On Thursday 08 March 2007 04:53, Timoth=E9e Lecomte wrote: > Dear gnuplot enthusiasts, >=20 > Since 4.2 is out, I would like to start discussing some things I have in > mind for 4.3/4.4. My list (in no particular order): 1) Continued work on internationalization - better use and documentation of LOCALE settings - support UTF-8 in as many terminal types as possible - better mechanism for integrating and maintaining localized documentation 2) Transparency - mostly done, but needs to be implemented in win, aqua, [others?] 3) Mousing support for SVG 4) Mousing support for multiplot mode 5) generate and plot 3D isosurface from 4D data color-mapping a 5th value onto that surface gets us up to 5D data - splot "4D-data" using 1:2:3:4 with isosurface at <value> - splot "5D-data" using 1:2:3:4:5 with isosurface at <value> Other projects that I'd like to see done, but I'm not the best person to evaluate or coordinate it: 1) Updates to the "fit" subsystem - 1294507 Fitting using CERN Minuit routines - 1445064 Gnuplot fitting improvements 2) Fix up the "history" command (Dan Sebald was working on this) > First, I'd like to see the terminal module architecture that I proposed as > a patch in sourceforge to settle: > https://sourceforge.net/tracker/?func=3Ddetail&atid=3D302055&aid=3D157144= 3&group_id=3D2055 Is there any technical benefit to this work? I have the impression, perhaps incorrect, that it is being entirely driven by distaste for linking to libreadline. > What I implement in the plugin1.diff and plugin2.diff is the an in-between > interactive structure: > term->inter->waitforinput > term->inter->put_tmptext > term->inter->set_ruler > term->inter->set_cursor > term->inter->set_clipboard >=20 > so that non-interactive terminals just have term->inter =3D 0, making it > easier to extend the terminal API for interactive commands. Yes, that's a bit cleaner. But it's not like we extend the terminal API every week. > And in plugin2.diff, I move the ugly terminal-specific code in > raise_lower_command() (command.c) to where it belongs, in the terminals. > This is done by introducing: >=20 > term->inter->raise_term_window Please remind me where we ended up in previous discussions. I thought this turned out to be something that cannot be done in the terminal driver at all, because at the time you want to issue the command you may have a different terminal active. I tried implementing it x11, and what happened was the all the raise/lower events got queued up and executed in a batch the next time an x11 window pipe was the active input stream. That's clearly no good. I attempted to work around this with a patch to continue accepting input from the previous interactive terminal, but that didn't work very well either. > the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c". Instead > of moving the "raise console" code into the core, it could be moved to a > dummy terminal (like estimate.trm), which would be built as a module. > Voil=E0! No more code duplication without adding a Xlib dependency on the > core ! But that isn't going to make it any easier to figure how to do it in the first place. Also, does this mean you are thinking that one terminal driver would call into another terminal driver? Or is this an alternative to the term->inter->raise_term_window() mechanism you just mentioned above? > What are my other short-term projects ? > - commit the cairopdf terminal, eventually replacing the current pdf > terminal. It is really working nicely. Absolutely. This will be really great. The main hangup is the same as for the initial wxt terminal introduction - it isn't straightforward to build it on most machines yet, because the cairo library requirement is too bleeding edge. But that's not a problem in the longer term. > Another interesting comment was the lack of > a powerful and broadly available (i.e. for many languages) plotting > library.=20 There's a reason for that. Such libraries are not very useful, and tend to die a lingering death from lack of users. Additional comments in a separate post. =2D-=20 Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 01:15:51
|
Ethan Merritt wrote: > On Thursday 08 March 2007 04:53, Timothée Lecomte wrote: > >>Dear gnuplot enthusiasts, >> >>Since 4.2 is out, I would like to start discussing some things I have in >>mind for 4.3/4.4. > > > My list (in no particular order): > > 1) Continued work on internationalization > - better use and documentation of LOCALE settings > - support UTF-8 in as many terminal types as possible > - better mechanism for integrating and maintaining localized documentation > > 2) Transparency > - mostly done, but needs to be implemented in win, aqua, [others?] > > 3) Mousing support for SVG > > 4) Mousing support for multiplot mode > > 5) generate and plot 3D isosurface from 4D data > color-mapping a 5th value onto that surface gets us up to 5D data > - splot "4D-data" using 1:2:3:4 with isosurface at <value> > - splot "5D-data" using 1:2:3:4:5 with isosurface at <value> > > Other projects that I'd like to see done, but I'm not the best person to > evaluate or coordinate it: > > 1) Updates to the "fit" subsystem > - 1294507 Fitting using CERN Minuit routines > - 1445064 Gnuplot fitting improvements > > 2) Fix up the "history" command (Dan Sebald was working on this) [ gnuplot-Bugs-1534367 ] too much expansion in FindHelp [ gnuplot-Bugs-1525665 ] help has problems with I believe this one is ready to go. I recall some problems I had with a robust minor adjustment to the existing algorithm. But then I think a did an overhaul of the general strategy for history and left it in a state I thought made sense and worked well. Here are other items... [ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA() I believe this works well. Configuration goes with a library version of the routine tgamma/lgamma then falls back on gnuplot's version. There is even use of gamma/lgamma if the global variable is valid. I think I've cleared up the confusion with the use of that global variable and all systems are covered including MacOS (a user said it works). Some argued there is a bug in implementations of this, but I still am not convinced the standard calls out for use of the global variable. I think it works. [ gnuplot-Patches-1589067 ] Alpha Channel images People want this. Doesn't seem difficult. Just need time to work on it. Ethan has it pretty much figured out and put together a patch. term->clip_region (or whatever) Ethan suggested a clip region for the terminal. Lines/images/polygons/etc would then be clipped to this region. That would move an extraneous set of coordinates from the term->image function. [ gnuplot-Patches-1636431 ] Allow hidden3d with pm3d and rename to 'tileline' option This patch was simply a means of improving the sorting depth approach to hidden surface elements which is only an estimate. I don't think this patch itself will yield too much. However, I think there is a TODO item here and that is to utilize the hidden mesh code in combination with the pm3d elements. I think this might fit together better and more easily than people realize. There would be a couple things: 1) Clean up the current hidden 3D code. I see little vestigial bits of lines and corners in some of the hidden 3D examples. 2) After that, then come up with a robust hidden surface routine (in the above patch are some short 3D matrix inverse and hyperplane routines that could be useful), and then overlay the hidden 3D mesh. [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute This is an outright bug fix. It should have gone in 4.2 had there been a little time to review it. The only thing required is a reviewer to say "Hey, I don't like that nonlinear mouse movement behavior, I'd rather it be linear", or "Nonlinear is better than linear." [ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventions This one I think is a big winner. There's a bit of code there, but it is a full implementation of mouse/clipboard behavior consistent with the vast majority of X applications. [ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border This was a case where a double tic would appear at the end of an axis because of rounding effects. I believe the approach I used works well, but people didn't seem to buy it. It's rather simple really: "integerize" the tics rather than looping until the tic value falls out of range. That is, because of the integer nature we can tell when we are at the end of the range, i.e., the last possible tic. Then if at the last tic we test last_tic < end_range rather than the current approach (i.e., effect of looping) first_tic + delta_tic + delta_tic + ... + delta_tic < end_range The second approach is susceptible to rounding, the first isn't. I.e., the existing problem is that last_tic is greater than end_range (and the tic shouldn't be printed), but first_tic + delta_tic + ... + delta_tic is less than end_range (and the tic ends up being printed). [ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing" This code could be used. (There is a demo which illustrates different behavior.) I think mostly though this is about coming up with coherent method of handling these "data special exceptions" that was never formally considered, i.e., I think it used to be what you get is what you get. [ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application window Works as far as I know. X11 has an issue whereby two resources both controlling the mouse in a window will cause an error. Allow multiple palettes on a multiplot X11 window This is that problem where someone plotted a multiplot having two different palettes. It works on all terminals except X11. An X11 window only allows one palette. I think the best way to deal with this is to have individual X11 windows for the subplots that lies on top of the base plot X window. That way each window can have its own subplot and its own palette. Review the image placement We should review how image places the start of the bounding box and possibly make it consistent with any existing conventions. It may be off by half a pixel. Petr suggested possibly having an option so images can have the position in the center of the pixel or the lower left corner. After addressing that, then go through each of the terminals and verify consistency, e.g., GIF, etc. Unify plot layout for 2D and 3D This was discussed with Mike Sutton on the list. A bit of work. Place all plot information in structures Hans suggested this a long time ago so that multiplots and all plot may be redrawn freely. (One utility I know of simply launches multiple versions of gnuplot to hold information unique to individual plots.) Probably forgot some... Dan |
|
From: <tim...@en...> - 2007-03-08 22:35:10
|
On Thursday 08 March 2007 04:53, Timothée Lecomte wrote: >> Dear gnuplot enthusiasts, >> >> Since 4.2 is out, I would like to start discussing some things I have in >> mind for 4.3/4.4. > > My list (in no particular order): Thanks for participating in the discussion ! > > 1) Continued work on internationalization > - better use and documentation of LOCALE settings > - support UTF-8 in as many terminal types as possible > - better mechanism for integrating and maintaining localized > documentation One interesting quote from Lars's list in the TODO file: "- better documentation format; get rid of the doc2xxx utils [SGML. SGML. SGML]" Maybe localization could be an additional motivation for this. > > 2) Transparency > - mostly done, but needs to be implemented in win, aqua, [others?] > > 3) Mousing support for SVG > > 4) Mousing support for multiplot mode This one is probably more difficult than it seems. <...> > >> First, I'd like to see the terminal module architecture that I proposed >> as >> a patch in sourceforge to settle: >> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1571443&group_id=2055 > > Is there any technical benefit to this work? > I have the impression, perhaps incorrect, that it is being entirely > driven by distaste for linking to libreadline. This has nothing to do with readline, it's for the _terminal_, like wxt or gd, to be built as external modules and to be loaded at run-time. I understood that some people were not liking to have the core have many dependencies, so that's a way to overcome that. It may make packagers/distributions' life easier too. > >> What I implement in the plugin1.diff and plugin2.diff is the an >> in-between >> interactive structure: >> term->inter->waitforinput >> term->inter->put_tmptext >> term->inter->set_ruler >> term->inter->set_cursor >> term->inter->set_clipboard >> >> so that non-interactive terminals just have term->inter = 0, making it >> easier to extend the terminal API for interactive commands. > > Yes, that's a bit cleaner. > But it's not like we extend the terminal API every week. S you would suggest that I add term->raise_term_window directly in struct termentry ? In that case, my point is that: - if I add it to the bottom, then it's one more #ifdef USE_MOUSE - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0' manually to all drivers > >> And in plugin2.diff, I move the ugly terminal-specific code in >> raise_lower_command() (command.c) to where it belongs, in the terminals. >> This is done by introducing: >> >> term->inter->raise_term_window > > Please remind me where we ended up in previous discussions. > I thought this turned out to be something that cannot be done in the > terminal driver at all, because at the time you want to issue the command > you may have a different terminal active. I tried implementing it x11, > and what happened was the all the raise/lower events got queued up and > executed in a batch the next time an x11 window pipe was the active > input stream. That's clearly no good. I attempted to work around > this with a patch to continue accepting input from the previous > interactive terminal, but that didn't work very well either. You're miwing two opposite features: 1- 'raise console (xterm, konsole, ...)' which is bound to the spacebar in any interactive terminal. This cannot be moved as a function in struct termentry for the reason you just explained 2- I'm talking about 'raise terminal (wxt, x11, ...)' which is the 'raise' or 'lower' command (see 'help raise'). It makes sense to have act on the current active terminal, and to move the code to the terminal instead of command.c > >> the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c". >> Instead >> of moving the "raise console" code into the core, it could be moved to a >> dummy terminal (like estimate.trm), which would be built as a module. >> Voilà! No more code duplication without adding a Xlib dependency on the >> core ! > > But that isn't going to make it any easier to figure how to do it in the > first place. Also, does this mean you are thinking that one > terminal driver would call into another terminal driver? Or is this > an alternative to the term->inter->raise_term_window() mechanism you > just mentioned above? So, that's point 1 in the above enumeration. It is not terminal-specific, so it shouldn't be in the terminal code as it is now. The problem is that it can only be done by linking to Xlib (from a Unix environment, of course), and it was objected that we don't want to add a dependency on Xlib to the core. > >> What are my other short-term projects ? >> - commit the cairopdf terminal, eventually replacing the current pdf >> terminal. It is really working nicely. > > Absolutely. This will be really great. The main hangup is the same > as for the initial wxt terminal introduction - it isn't straightforward > to build it on most machines yet, because the cairo library requirement > is too bleeding edge. But that's not a problem in the longer term. Right. I plan to commit it soon, just after a couple a cleanups here and there. >> Another interesting comment was the lack of >> a powerful and broadly available (i.e. for many languages) plotting >> library. > > There's a reason for that. Such libraries are not very useful, > and tend to die a lingering death from lack of users. > Additional comments in a separate post. Ok, let's discuss it in the separate post. Thank you again for your comments. Timothée > > -- > Ethan A Merritt Courier Deliveries: 1959 NE Pacific > Dept of Biochemistry > Health Sciences Building > University of Washington - Seattle WA 98195-7742 > |
|
From: <tim...@en...> - 2007-03-08 23:01:59
|
> 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. > > 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. Also note that Mathemetica, Matlab, etc. are more for repetitive simulation/analysis tools. 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. > > 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), 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). > > I would be much more interested in proposals to extend gnuplot in > the other direction, allowing it to call user-provided application > code. One example of this kind of thinking is patchset #588805 > (the oldest patch still active on our tracker). This one is interesting. At least I see that what I wrote with GLib for my terminals-as-plugins could be done from scratch ;) Best regards, Timothée > > Ethan > |
|
From: Jonathan T. <jt...@ae...> - 2007-03-09 09:36:57
|
On Fri, 9 Mar 2007, Timothée Lecomte wrote:
> Currently, it's tricky to include a gnuplot graph in a data acquisition
> program (I mean in the same window, of course), it's unnatural to use
> gnuplot from another language than gnuplot native one (think python,
> ruby),
I do this latter thing quite often from Perl, with (I think) no particular
difficulty: My Perl program generates/manipulates some data files,
generates a gnuplot script which references those data files, then
invokes gnuplot on that script. Admittedly, these aren't _interactive_
plots (they're typically 'set term postscript' followed by invoking
ps2pdf) -- I've never tried invoking an interactive gnuplot terminal
from a program.
I could certainly _imagine_ a direct gnuplot-api, sort of like there's
a Perl/Tk binding to the Tk widget set (the "Tk" in "Tk/TCL"), and I
have no objection if people want to build such a thing.
> it's very difficult to build a useful general-purpose GUI on
> top of gnuplot (think xgfe)
I've long wanted to build (probably using Perl/Tk) a "movie gnuplot":
a GUI to make it easier to generate sequences of gnuplot commands which
iterate through the frames of a movie. Right now I use a custom-written
Perl program to generate the gnuplot script for each movie, which is
++clumsy.
ciao,
--
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
School of Mathematics, U of Southampton, England
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-08 23:45:07
|
On Thursday 08 March 2007 14:35, Timoth=E9e Lecomte wrote: > > 4) Mousing support for multiplot mode >=20 > This one is probably more difficult than it seems. At least in x11 it should not be fairly easy. Gnuplot_x11 already stores plot bounds and axis scaling information, used to echo back the mouse coordinates based on the current cursor coordinates in the window. To make mouse coordinates work for multiplot, one just needs a pre-test on the cursor coordinates to see which scaling table should be used. So I think echoing the appropriate mouse coordinates for various subplots on the screen would be easy. The difficult part would be to do something like zooming a subplot; as currently implemented, that would require going back to the original plot command and the original data, both of which are long gone. =20 On the other hand, you may get zooming for free in svg, because the viewer handles it. ... assuming that we get mousing to work in svg at all. But I really have not looked at the mousing code of the other mousing terminals, so I can't say whether the x11 solution applies to them as well. =20 > >> First, I'd like to see the terminal module architecture that I proposed > > > > Is there any technical benefit to this work? > > I have the impression, perhaps incorrect, that it is being entirely > > driven by distaste for linking to libreadline. >=20 > This has nothing to do with readline, it's for the _terminal_, like wxt or > gd, to be built as external modules and to be loaded at run-time. Ah. Light dawns. I totally mis-understood. Sorry. OK, I'll have a look at it. > >> What I implement in the plugin1.diff and plugin2.diff is the an > >> in-between > >> interactive structure: > >> term->inter->waitforinput > >> term->inter->put_tmptext > >> term->inter->set_ruler > >> term->inter->set_cursor > >> term->inter->set_clipboard > >> > >> so that non-interactive terminals just have term->inter =3D 0, making = it > >> easier to extend the terminal API for interactive commands. > > > > Yes, that's a bit cleaner. > > But it's not like we extend the terminal API every week. >=20 > S you would suggest that I add term->raise_term_window directly in > struct termentry ? Not at all. I was just commenting that extending the terminal API doesn't happen very often, so it doesn't seem like a high priority to rearrange things to make it easier. Nice, but not high priority. > term->inter->raise_term_window() > > Please remind me where we ended up in previous discussions. > > I thought this turned out to be something that cannot be done in the > > terminal driver at all, because at the time you want to issue the comma= nd > > you may have a different terminal active. I tried implementing it x11, > > and what happened was the all the raise/lower events got queued up and > > executed in a batch the next time an x11 window pipe was the active > > input stream. That's clearly no good. I attempted to work around > > this with a patch to continue accepting input from the previous > > interactive terminal, but that didn't work very well either. >=20 > You're mixing two opposite features: > 1- 'raise console (xterm, konsole, ...)' which is bound to the spacebar in > any interactive terminal. This cannot be moved as a function in struct > termentry for the reason you just explained > 2- I'm talking about 'raise terminal (wxt, x11, ...)' which is the 'raise' > or 'lower' command (see 'help raise'). It makes sense to have act on the > current active terminal, and to move the code to the terminal instead of > command.c No. I'm not talking about 'raise console' at all. I don't care about that, and would never use it :-) I'm talking about the case where you have a dozen x11 windows on your screen with old plots in them, and you want to raise plot #5, but don't remember which window that is. I gather from Petr's comments that this is typical in an Octave session. How do you send a "raise" command to an existing x11 window when it's not the currently active terminal? The current terminal may still be x11, but a different window. Even worse if the current terminal is post or png or something like that. I'm not saying it's impossible, but my simple-minding attempt to do it inside the x11=20 driver didn't work. =2D-=20 Ethan A Merritt |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-08 23:46:44
|
On Thursday 08 March 2007 15:44, Ethan Merritt wrote: > On Thursday 08 March 2007 14:35, Timoth=E9e Lecomte wrote: > > > 4) Mousing support for multiplot mode > >=20 > > This one is probably more difficult than it seems. >=20 > At least in x11 it should not be fairly easy. Bleah. Make that "should be fairly easy". =2D-=20 Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
|
From: <tim...@en...> - 2007-03-09 00:12:57
|
> On Thursday 08 March 2007 14:35, Timothée Lecomte wrote: >> > 4) Mousing support for multiplot mode >> >> This one is probably more difficult than it seems. > > At least in x11 it should not be fairly easy. Gnuplot_x11 already > stores plot bounds and axis scaling information, used to echo back > the mouse coordinates based on the current cursor coordinates in > the window. To make mouse coordinates work for multiplot, one just > needs a pre-test on the cursor coordinates to see which scaling > table should be used. So I think echoing the appropriate mouse > coordinates for various subplots on the screen would be easy. > The difficult part would be to do something like zooming a subplot; > as currently implemented, that would require going back to the > original plot command and the original data, both of which are > long gone. I was indeed thinking of getting original data, as this was what I was told before. I am thinking of overlapping multiplots too. > > >> >> First, I'd like to see the terminal module architecture that I >> proposed >> > >> > Is there any technical benefit to this work? >> > I have the impression, perhaps incorrect, that it is being entirely >> > driven by distaste for linking to libreadline. >> >> This has nothing to do with readline, it's for the _terminal_, like wxt >> or >> gd, to be built as external modules and to be loaded at run-time. > > Ah. Light dawns. I totally mis-understood. Sorry. > OK, I'll have a look at it. No problem. >> > Please remind me where we ended up in previous discussions. >> > I thought this turned out to be something that cannot be done in the >> > terminal driver at all, because at the time you want to issue the >> command >> > you may have a different terminal active. I tried implementing it >> x11, >> > and what happened was the all the raise/lower events got queued up and >> > executed in a batch the next time an x11 window pipe was the active >> > input stream. That's clearly no good. I attempted to work around >> > this with a patch to continue accepting input from the previous >> > interactive terminal, but that didn't work very well either. >> >> You're mixing two opposite features: >> 1- 'raise console (xterm, konsole, ...)' which is bound to the spacebar >> in >> any interactive terminal. This cannot be moved as a function in struct >> termentry for the reason you just explained >> 2- I'm talking about 'raise terminal (wxt, x11, ...)' which is the >> 'raise' >> or 'lower' command (see 'help raise'). It makes sense to have act on the >> current active terminal, and to move the code to the terminal instead of >> command.c > > No. I'm not talking about 'raise console' at all. I don't care about > that, and would never use it :-) > I'm talking about the case where you have a dozen x11 windows on your > screen > with old plots in them, and you want to raise plot #5, but don't remember > which window that is. I gather from Petr's comments that this is typical > in an Octave session. How do you send a "raise" command to an existing > x11 window when it's not the currently active terminal? The current > terminal may still be x11, but a different window. Even worse if the > current terminal is post or png or something like that. I'm not saying > it's impossible, but my simple-minding attempt to do it inside the x11 > driver didn't work. Well, everything is already there, see 'help raise' (you can do 'raise 5' to raise the 5th window). Currently, if you do: set term x11 plot x set term wxt plot x raise # then both wxt and x11 windows are raised. With my patch (whose first goal is to eradicate that ugly code from command.c): set term x11 plot x set term wxt plot x raise # only wxt windows is raised. set term x11 raise # only x11 windows is raised. Simple, isn't it ;) Timothée > > -- > Ethan A Merritt > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-09 00:36:34
|
On Thursday 08 March 2007 16:18, Timoth=E9e Lecomte wrote: > 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: >=20 > gnuplot_context * gnuplot_cairo_create_context(cr); > gnuplot_set_borders(gnuplot_context,...); > gnuplot_set_axis(gnuplot_context,...); > gnuplot_plot(gnuplot_context, data); You only think you want this :-) It does not avoid having to learn gnuplot, because the only way to understand what gnuplot_set_borders(gnuplot_context,...) actually does is to understand the underlying gnuplot command "set borders ...". So instead of simplifying things, it actually makes it more complex. Now you have to understand both the gnuplot behaviour, and whatever idiosyncracies or variants are introduced by the binding layer. Then if you want to do the same thing tomorrow from python or perl, you have to learn a whole new set of bindings with their own idiosyncracies. Perhaps it is also a matter of taste. I find the code fragment above harder to read than, say, print GNUPLOT <<END set term wxt set borders 31 set xrange [0:10] plot '-' END This way the only language-dependent bits are the statements that wrap the piped sequence of commands. =2D-=20 Ethan A Merritt |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 01:54:27
|
The OLPC project (One Laptop Per Child) is inviting contributed software suitable for educational use on the OLPC platform. http://wiki.laptop.org/Software I note with interest that the prefered software API is via the Pango/Cairo/GTK+ library layer. Several people here have expressed interest in a gnuplot GUI. My first reaction was "who would want one?", but the coincidental arrival of the OLPC invitation may have answered the question. So here's the challenge: - design a GUI for gnuplot usable by school-age kids to explore math and functions. Probably using GTK+ - provide a single terminal driver based on Pango/Cairo - make the existing gnuplot components modular enough that we can select a set of configuration options suitable for the OLPC platform (366 MHz Geode, 128 MB, custom display) Even if this never ends up as a standard OLPC app, I think the constraints make an interesting project. In particular I think that GUI design can only work if you have a clear target user group, and elementary maths education would be a good target to aim for. (certainly a GUI is of no use for the stuff I use gnuplot for :-) -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 02:17:40
|
Ethan A Merritt wrote: > The OLPC project (One Laptop Per Child) is inviting contributed > software suitable for educational use on the OLPC platform. > http://wiki.laptop.org/Software > > I note with interest that the prefered software API is via the > Pango/Cairo/GTK+ library layer. > > Several people here have expressed interest in a gnuplot GUI. > My first reaction was "who would want one?", but the coincidental > arrival of the OLPC invitation may have answered the question. > > So here's the challenge: > - design a GUI for gnuplot usable by school-age kids to explore > math and functions. Probably using GTK+ > - provide a single terminal driver based on Pango/Cairo > - make the existing gnuplot components modular enough that > we can select a set of configuration options suitable for > the OLPC platform (366 MHz Geode, 128 MB, custom display) What school age? 3rd-6th? Are you thinking something where the student types a function in a box and the plot appears? Then they hit a button that will print out their plot on a printer? Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 02:58:24
|
On Thursday 08 March 2007 18:29, Daniel J Sebald wrote: > Ethan A Merritt wrote: > > Several people here have expressed interest in a gnuplot GUI. > > My first reaction was "who would want one?", but the coincidental > > arrival of the OLPC invitation may have answered the question. > > > > So here's the challenge: > > - design a GUI for gnuplot usable by school-age kids to explore > > math and functions. Probably using GTK+ > > What school age? 3rd-6th? It's not entirely clear to me what age ranges the OLPC adopters will target. It may vary from country to country. I wouldn't rule out these things being used through high school. > Are you thinking something where the student types a function > in a box and the plot appears? That, and buttons to plot data from files. Think of a class project to measure things and type the measurements into a file. The kids could then call up the gnuplot GUI, use a file browser to select the data file, and use GUI buttons to play around with averaging, smoothing, histogramming, etc. Swap data files by wifi with your friends, plot them in different colors, and so on. Basically an all-in-one tool useful for learning experimental science, maths, and statistics. An even more integrated GUI could allow data entry from the clipboard. Then you could pull up a Wikipedia page with data of some sort in a browser window, select it with the mouse, and tell gnuplot to plot it. > Then they hit a button that will print out their plot on a printer? The OLPC laptops have no output other than screen and wifi. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2007-03-09 09:37:43
|
> On Thursday 08 March 2007 04:53, Timothée Lecomte wrote: > >> >>> What I implement in the plugin1.diff and plugin2.diff is the an >>> in-between >>> interactive structure: >>> term->inter->waitforinput >>> term->inter->put_tmptext >>> term->inter->set_ruler >>> term->inter->set_cursor >>> term->inter->set_clipboard >>> >>> so that non-interactive terminals just have term->inter = 0, making it >>> easier to extend the terminal API for interactive commands. >> >> Yes, that's a bit cleaner. >> But it's not like we extend the terminal API every week. > > So you would suggest that I add term->raise_term_window directly in > struct termentry ? > > In that case, my point is that: > - if I add it to the bottom, then it's one more #ifdef USE_MOUSE > - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0' > manually to all drivers Well, let's forget this idea of term->inter->... I can actually add term->raise_term_window just inside the existing #ifdef USE_MOUSE ... #endif, and I can introduce the following: #define EMPTY_MOUSE_ENTRIES \ #ifdef USE_MOUSE \ 0, 0, 0, 0, 0, 0, \ #endif So that non-mouseable terminals will just use NO_MOUSE_ENTRIES, and it will be much easier to add new mousing commands in the future. Does that sound right ? Best regards, Timothée |
|
From: <tim...@en...> - 2007-03-09 20:30:35
|
Timothée Lecomte wrote: >> On Thursday 08 March 2007 04:53, Timothée Lecomte wrote: >> > > >>>> What I implement in the plugin1.diff and plugin2.diff is the an >>>> in-between >>>> interactive structure: >>>> term->inter->waitforinput >>>> term->inter->put_tmptext >>>> term->inter->set_ruler >>>> term->inter->set_cursor >>>> term->inter->set_clipboard >>>> >>>> so that non-interactive terminals just have term->inter = 0, making it >>>> easier to extend the terminal API for interactive commands. >>>> >>> Yes, that's a bit cleaner. >>> But it's not like we extend the terminal API every week. >>> >> So you would suggest that I add term->raise_term_window directly in >> struct termentry ? >> >> In that case, my point is that: >> - if I add it to the bottom, then it's one more #ifdef USE_MOUSE >> - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0' >> manually to all drivers >> > > Well, let's forget this idea of term->inter->... > I can actually add term->raise_term_window just inside the existing #ifdef > USE_MOUSE ... #endif, and I can introduce the following: > > #define EMPTY_MOUSE_ENTRIES \ > #ifdef USE_MOUSE \ > 0, 0, 0, 0, 0, 0, \ > #endif > > > So that non-mouseable terminals will just use NO_MOUSE_ENTRIES, and it > will be much easier to add new mousing commands in the future. > > Does that sound right ? > > Best regards, > > Timothée > Ok, that's done: http://sourceforge.net/tracker/index.php?func=detail&aid=1677582&group_id=2055&atid=302055 Comments ? Best regards, Timothée |
|
From: Petr M. <mi...@ph...> - 2007-03-15 09:45:13
|
> >> > 4) Mousing support for multiplot mode > >> > >> This one is probably more difficult than it seems. > > > > At least in x11 it should not be fairly easy. Gnuplot_x11 already > > stores plot bounds and axis scaling information, used to echo back > > the mouse coordinates based on the current cursor coordinates in > > the window. To make mouse coordinates work for multiplot, one just > > needs a pre-test on the cursor coordinates to see which scaling > > table should be used. So I think echoing the appropriate mouse > > coordinates for various subplots on the screen would be easy. I think so. And it does not depend on x11 at all. > > The difficult part would be to do something like zooming a subplot; > > as currently implemented, that would require going back to the Yes, that's impossible .. unless the whole output of "save ..." just after the plot is stored internally. > Well, everything is already there, see 'help raise' (you can do 'raise 5' > to raise the 5th window). > > Currently, if you do: > > set term x11 > plot x > set term wxt > plot x > raise # then both wxt and x11 windows are raised. > > With my patch (whose first goal is to eradicate that ugly code from > command.c): > > > set term x11 > plot x > set term wxt > plot x > raise # only wxt windows is raised. > set term x11 > raise # only x11 windows is raised. Will the "raise" command keep raising all windows of wxt and/or of x11? And which one will it choose when currently there is e.g. "set term post"? --- PM |
|
From: <tim...@en...> - 2007-03-15 11:02:12
|
>> >> > 4) Mousing support for multiplot mode
>> >>
>> >> This one is probably more difficult than it seems.
>> >
>> > The difficult part would be to do something like zooming a subplot;
>> > as currently implemented, that would require going back to the
>
> Yes, that's impossible .. unless the whole output of "save ..." just after
> the plot is stored internally.
Not only 'save', but also the input data, which is not available anymore
in case of a pipe for example. We would need some cache layer in between
the parser and the terminals. Doesn't it exist for pm3d quadrangles
already ?
>
>
>> Well, everything is already there, see 'help raise' (you can do 'raise
>> 5'
>> to raise the 5th window).
>>
>> Currently, if you do:
>>
>> set term x11
>> plot x
>> set term wxt
>> plot x
>> raise # then both wxt and x11 windows are raised.
>>
>> With my patch (whose first goal is to eradicate that ugly code from
>> command.c):
>>
>>
>> set term x11
>> plot x
>> set term wxt
>> plot x
>> raise # only wxt windows is raised.
>> set term x11
>> raise # only x11 windows is raised.
>
> Will the "raise" command keep raising all windows of wxt and/or of x11?
> And which one will it choose when currently there is e.g. "set term post"?
It affects the current terminal only, so it won't do anything if the
current terminal is postscript for example. When I say 'current terminal',
it includes all windows for an interactive terminal. I think it's clear
when you look at the function primitive:
term->raise_termwindow(int w /* windows number */,
TBOOLEAN raise /* raise or lower*/,
TBOOLEAN all /* all windows or only the given
number */)
As an example:
set term x11 0
plot x
set term x11 1
plot x
set term wxt 0
plot x
set term wxt 1
plot x
set term plot; raise # nothing happens
set term wxt; raise # all wxt windows is raised.
set term wxt; raise 1 # wxt window n°1 is raised
set term wxt; raise 0 # wxt window n°0 is raised
set term wxt 0; raise 1 # wxt window n°1 is raised
set term x11; raise 0 # x11 window n°0 is raised
set term x11; raise 1 # x11 window n°1 is raised
set term x11 0; raise 1 # x11 window n°1 is raised
Does that sound right to you ?
Timothée
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-15 16:42:34
|
On Thursday 15 March 2007 04:02, Timoth=E9e Lecomte wrote: > It affects the current terminal only, so it won't do anything if the > current terminal is postscript for example. When I say 'current terminal', > it includes all windows for an interactive terminal. It is slightly more complicated for x11. The "raise" command can only affect x11 windows opened by the current instance of gnuplot_X11. It is possible, although unusual, to have multiple active instances of gnuplot_x11, each managing a separate set of display windows. If we wanted to make this truly general, we would have to keep a=20 table mapping previous x11 plot commands to the x11 window ID that=20 they were assigned. That could be done, but it would be a big headache and I don't recommend it. Ethan=20 > I think it's clear=20 > when you look at the function primitive: >=20 > term->raise_termwindow(int w /* windows number */, > TBOOLEAN raise /* raise or lower*/, > TBOOLEAN all /* all windows or only the given > number */) >=20 > As an example: >=20 > set term x11 0 > plot x > set term x11 1 > plot x > set term wxt 0 > plot x > set term wxt 1 > plot x > set term plot; raise # nothing happens > set term wxt; raise # all wxt windows is raised. > set term wxt; raise 1 # wxt window n=B01 is raised > set term wxt; raise 0 # wxt window n=B00 is raised > set term wxt 0; raise 1 # wxt window n=B01 is raised > set term x11; raise 0 # x11 window n=B00 is raised > set term x11; raise 1 # x11 window n=B01 is raised > set term x11 0; raise 1 # x11 window n=B01 is raised >=20 > Does that sound right to you ? =2D-=20 Ethan A Merritt |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-15 15:57:12
|
On Thursday 15 March 2007 02:44, Petr Mikulik wrote: > > > > The difficult part would be to do something like zooming a subplot; > > > as currently implemented, that would require going back to the > > Yes, that's impossible .. unless the whole output of "save ..." just after > the plot is stored internally. It is not impossible. In fact SVG can already do it, because the SVG viewer is responsible for the zooming. It does not recalculate the axis positions and relabel them, of course, but it does give you an zoomed-in view of the original plot. The same thing could be done in x11 if we decide it's worth it. Furthermore, it would be possible to do a more efficient job of "replot" in the core code that would benefit all terminals. Perhaps I am overlooking something, but I don't see any hard requirement to re-read the original data from a file on each replot command. Yes, this is sometimes exactly what you want because you know the data has changed. But more often you just want to redraw the plot with a different plot option, or zoom or view angle. In these cases there should be enough, or almost enough, information already stored in the data structures from the previous plot. Why re-read the data file when it is just storing the same information all over again? This would in particular be of plot '-', where it is very annoying to type in the same data all over again. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@mo...> - 2007-03-15 17:11:31
|
> Furthermore, it would be possible to do a more efficient job > of "replot" in the core code that would benefit all terminals. > Perhaps I am overlooking something, but I don't see any hard > requirement to re-read the original data from a file on each > replot command. Yes, this is sometimes exactly what you want > because you know the data has changed. But more often you > just want to redraw the plot with a different plot option, > or zoom or view angle. In these cases there should be enough, > or almost enough, information already stored in the data structures > from the previous plot. Why re-read the data file when it is > just storing the same information all over again? This would in > particular be of plot '-', where it is very annoying to type in > the same data all over again. Mousing in 3D -- rotating by mouse -- does not reread the data, but uses those in the memory. It would be useful for those "-" to do the same. Thus there could be two replots, e.g. replot and Replot, where the second would not reread the data from disk. --- PM |
|
From: Petr M. <mi...@mo...> - 2007-04-08 11:23:43
|
I went through the octave-help archive and a message (see its copy at the
bottom) says that mousing (zooming, and also hotkeys) does no longer work
with octave 2.9.10. I had a look what this octave version is doing by:
octave> gnuplot_binary('tee a.log | gnuplot');
and there appears:
plot "-" using ($1):($2) title "" with lines linestyle 1;
-20 -20
-19 -19
-18 -18
Therefrom, octave does no longer use temporary data files but switched to
inline data. That's a nice improvement. Unfortunately, gnuplot ignores
"replot" for plots with "-", and consequently mousing+hotkeys do not work.
Thus, it looks like a strong demand to gnuplot developers to implement
replot for "-". This matter was discussed recently, see below...
Note: 3D plots, e.g.
octave> mesh(hilb(9))
which produces
splot "-" using ($1):($2):($3) title "" with line palette;
1 1 1
1 2 2
can be rotated by mouse, because gnuplot reuses the loaded 3D data in
this case; but hotkeys do not work again.
Does somebody know how to implement it? (Me not.)
---
PM
On Thu, 15 Mar 2007, Petr Mikulik wrote:
> > Furthermore, it would be possible to do a more efficient job
> > of "replot" in the core code that would benefit all terminals.
> > Perhaps I am overlooking something, but I don't see any hard
> > requirement to re-read the original data from a file on each
> > replot command. Yes, this is sometimes exactly what you want
> > because you know the data has changed. But more often you
> > just want to redraw the plot with a different plot option,
> > or zoom or view angle. In these cases there should be enough,
> > or almost enough, information already stored in the data structures
> > from the previous plot. Why re-read the data file when it is
> > just storing the same information all over again? This would in
> > particular be of plot '-', where it is very annoying to type in
> > the same data all over again.
>
> Mousing in 3D -- rotating by mouse -- does not reread the data, but uses
> those in the memory. It would be useful for those "-" to do the same.
>
> Thus there could be two replots, e.g. replot and Replot, where the second
> would not reread the data from disk.
===
According to:
http://www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html
>gnuplot zoom not functioning anymore in octave 2.9.10
>John W. Eaton jwe at bevo.che.wisc.edu
>Wed Apr 4 09:33:03 CDT 2007
>| until version 2.9.9, it was possible to enable zoom with the
>| "set mouse" command (e.g. in ~/.gnuplot). After changing to
>| version 2.9.10, this does not function anymore.
>
>It still works for me with gnuplot 4.0.
>
>With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots
>does not work for me when gnuplot is called from Octave. It does work
>when I run gnuplot directly. I don't know what the proper fix is. In
>any case, the changes you make with the mouse will still not be
>reflected in the axes settings seen by Octave as the communication
>with gnuplot is still a simple one way pipe.
>
>jwe
|
