Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2014-10-28 09:41:16
|
On 10/27/2014 01:53 PM, Ethan A Merritt wrote: > I also have code to add save-to-png-file to the wxt toolbar. > But I haven't worked with this toolkit before and I haven't found a > decent worked example to show how to embed this in a pull-down menu. > So as before ... > >> Patches welcome. I've placed a patch here: https://sourceforge.net/p/gnuplot/patches/704/ Give that a try. All you need to do is put your code for saving as PNG or whatnot in the location provided in the new switch statement. You may also want to tweak things, e.g., change the filters to whatever files you can save as. This is slightly different than the way Qt behaves as far as picking a file format. It's done via the file dialog's filter feature. It makes for a more conventional method of choosing, and in fact makes for easier programming versus putting a dropdown menu associated with the toolbar button. I suggest adding your code and moving into the repository then let people compare/experiment. If people prefer the dropdown menu, I can give that a try. Note that for the file icon I simply used one of the standard stock icons for wxWidgets, the wxART_FILE_SAVE_AS icon (suggested size wxART_TOOLBAR). So, the icon should be the same as you see in GTK, KDE or whatever. I saw in the icons directory how to convert a PNG file, but before doing that I thought I'd give this a try. Dan |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-07 01:52:03
|
[snip] > > I've placed a patch here: > > https://sourceforge.net/p/gnuplot/patches/704/ > > Give that a try. All you need to do is put your code for saving as > PNG or whatnot in the location provided in the new switch statement. > You may also want to tweak things, e.g., change the filters to > whatever files you can save as. > > This is slightly different than the way Qt behaves as far as picking > a file format. It's done via the file dialog's filter feature. It > makes for a more conventional method of choosing, and in fact makes > for easier programming versus putting a dropdown menu associated with > the toolbar button. I suggest adding your code and moving into the > repository then let people compare/experiment. If people prefer the > dropdown menu, I can give that a try. I finally got around to rebuilding from the tip (which now includes this patch), and I think this is fantastic! (I also like the way the format is chosen - just as in about every other application out there.) Thanks, Daniel! I think it will really help, in particular for casual use(r)s. Best, Ph. |
|
From: Bastian M. <bma...@we...> - 2014-10-25 18:05:48
|
Am 25.10.2014 um 19:46 schrieb Daniel J Sebald: > On 10/25/2014 03:40 AM, Daniel J Sebald wrote: > >> I removed the interlock test and it creates quite a mess with invalid >> events, seg faults in bad library calls, to scratch the surface. >> >> Investigating a bit, I think the problem lies in the fact wxt terminal >> is not in its own process. > > It's too much work to do this in an afternoon or so. Having looked at > the code, though, I'd say some things get simplified when WXT is run in > its own process as an outboard plotter. All these sorts of conditions > > #if defined(WXT_MONOTHREADED) || defined(_Windows) > > go away. > > Dan Btw. Timothée had been working on this years ago, see patch #380 https://sourceforge.net/p/gnuplot/patches/380 Also, the qt and wxt terminals run nicely in the same session on Windows. It just took some effort to make qt->waitforinput() work. Since waitforinput() is a terminal routine it typically only handles events from the library the current terminal uses. If we want to use multiple libraries in the same process, we need to replace/extend that mechanism. From my experience with the (outboard) qt terminal, I sincerely doubt that moving the wxt terminal to its own process will significantly simplify the source. Bastian |
|
From: Daniel J S. <dan...@ie...> - 2014-10-25 18:33:11
|
On 10/25/2014 01:05 PM, Bastian Märkisch wrote: > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald: >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote: >> >>> I removed the interlock test and it creates quite a mess with invalid >>> events, seg faults in bad library calls, to scratch the surface. >>> >>> Investigating a bit, I think the problem lies in the fact wxt terminal >>> is not in its own process. >> >> It's too much work to do this in an afternoon or so. Having looked at >> the code, though, I'd say some things get simplified when WXT is run in >> its own process as an outboard plotter. All these sorts of conditions >> >> #if defined(WXT_MONOTHREADED) || defined(_Windows) >> >> go away. >> >> Dan > > Btw. Timothée had been working on this years ago, see patch #380 > https://sourceforge.net/p/gnuplot/patches/380 Thanks. That could save a ton on the initial tedious work of putting bulk of the code in its own program. > Also, the qt and wxt terminals run nicely in the same session on > Windows. It just took some effort to make qt->waitforinput() work. > > Since waitforinput() is a terminal routine it typically only handles > events from the library the current terminal uses. If we want to use > multiple libraries in the same process, we need to replace/extend that > mechanism. I think once the active terminal is changed, mousing and keyboard input is disabled for others. > From my experience with the (outboard) qt terminal, I sincerely doubt > that moving the wxt terminal to its own process will significantly > simplify the source. It won't simplify the source, but it will get rid of those "corner cases". As you point out, Windows works fine for both terminals...and that's why the things like: #if defined(WXT_MONOTHREADED) || defined(_Windows) are in the code. But if WXT is running in its own thread all the Windows items should still work fine as well as linux. That's the idea anyway. Just to confirm, does the Qt terminal work in both Linux and Windows? Dan |
|
From: sfeam <sf...@us...> - 2014-10-25 20:23:46
|
On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote: > On 10/25/2014 01:05 PM, Bastian Märkisch wrote: > > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald: > >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote: > >> > >>> I removed the interlock test and it creates quite a mess with invalid > >>> events, seg faults in bad library calls, to scratch the surface. > >>> > >>> Investigating a bit, I think the problem lies in the fact wxt terminal > >>> is not in its own process. > >> > >> It's too much work to do this in an afternoon or so. Having looked at > >> the code, though, I'd say some things get simplified when WXT is run in > >> its own process as an outboard plotter. All these sorts of conditions > >> > >> #if defined(WXT_MONOTHREADED) || defined(_Windows) > >> > >> go away. > >> > >> Dan > > > > Btw. Timothée had been working on this years ago, see patch #380 > > https://sourceforge.net/p/gnuplot/patches/380 > > Thanks. That could save a ton on the initial tedious work of putting > bulk of the code in its own program. > > > > Also, the qt and wxt terminals run nicely in the same session on > > Windows. It just took some effort to make qt->waitforinput() work. > > > > Since waitforinput() is a terminal routine it typically only handles > > events from the library the current terminal uses. If we want to use > > multiple libraries in the same process, we need to replace/extend that > > mechanism. > > I think once the active terminal is changed, mousing and keyboard input > is disabled for others. > > > > From my experience with the (outboard) qt terminal, I sincerely doubt > > that moving the wxt terminal to its own process will significantly > > simplify the source. > > It won't simplify the source, but it will get rid of those "corner > cases". As you point out, Windows works fine for both terminals...and > that's why the things like: > > #if defined(WXT_MONOTHREADED) || defined(_Windows) Before tearing into a project to split off wxt into a separate process altogether, I think you should look into making the WXT_MONOTHREADED variant work on linux. Some/all of the problems it now has are due to the graphics event loop running in a separate thread. Anyhow, I really don't see the need for typical users to switch between qt and wxt within a single gnuplot session. Especially because the distro-packaged gnuplot versions probably only provide one or the other, not both. It can be handy for a developer, yes, because you'd like to compare the output of the two terminals. But I don't think that's a particularly useful thing for a typical gnuplot session. So really I think this is low priority compared to some other issues. For instance, how about fixing the auto-scaling for image plots? Right now the default behavior is to auto-scale to the center of the 4 corner pixels, which clips all the outermost pixels in half. That would be OK if there were an easy way to override it, but many of the obvious commands don't work. E.g. set xrange [-0.5:*] # doesn't work with image data set offset .5, .5, .5, .5 # this doesn't work either Ethan > > are in the code. But if WXT is running in its own thread all the > Windows items should still work fine as well as linux. That's the idea > anyway. > > Just to confirm, does the Qt terminal work in both Linux and Windows? > > Dan > > ------------------------------------------------------------------------------ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Daniel J S. <dan...@ie...> - 2014-10-25 21:46:45
|
On 10/25/2014 03:01 PM, sfeam wrote: > On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote: > >> On 10/25/2014 01:05 PM, Bastian Märkisch wrote: > >> > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald: > >> >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote: > >> >> > >> >>> I removed the interlock test and it creates quite a mess with invalid > >> >>> events, seg faults in bad library calls, to scratch the surface. > >> >>> > >> >>> Investigating a bit, I think the problem lies in the fact wxt terminal > >> >>> is not in its own process. > >> >> > >> >> It's too much work to do this in an afternoon or so. Having looked at > >> >> the code, though, I'd say some things get simplified when WXT is run in > >> >> its own process as an outboard plotter. All these sorts of conditions > >> >> > >> >> #if defined(WXT_MONOTHREADED) || defined(_Windows) > >> >> > >> >> go away. > >> >> > >> >> Dan > >> > > >> > Btw. Timothée had been working on this years ago, see patch #380 > >> > https://sourceforge.net/p/gnuplot/patches/380 > >> > >> Thanks. That could save a ton on the initial tedious work of putting > >> bulk of the code in its own program. > >> > >> > >> > Also, the qt and wxt terminals run nicely in the same session on > >> > Windows. It just took some effort to make qt->waitforinput() work. > >> > > >> > Since waitforinput() is a terminal routine it typically only handles > >> > events from the library the current terminal uses. If we want to use > >> > multiple libraries in the same process, we need to replace/extend that > >> > mechanism. > >> > >> I think once the active terminal is changed, mousing and keyboard input > >> is disabled for others. > >> > >> > >> > From my experience with the (outboard) qt terminal, I sincerely doubt > >> > that moving the wxt terminal to its own process will significantly > >> > simplify the source. > >> > >> It won't simplify the source, but it will get rid of those "corner > >> cases". As you point out, Windows works fine for both terminals...and > >> that's why the things like: > >> > >> #if defined(WXT_MONOTHREADED) || defined(_Windows) > > Before tearing into a project to split off wxt into a separate process > > altogether, I think you should look into making the WXT_MONOTHREADED > > variant work on linux. Some/all of the problems it now has are due to > > the graphics event loop running in a separate thread. I know that Qt has a requirement that graphics be only in the main thread. I can't verify that is the case for wxWidgets and I see some discussion on the Web that graphics can be done in non-main threads (sometimes with extra initialization inside the other threads). In any case, is that the desired setup? To have interactive graphics running in the same thread? Doesn't that create some event management code that typically is averted by using separate threads or processes? One approach might be to put what is now the main thread/code for processing command line input into a separate thread and then leaving the main thread for a possible interactive terminal, but not sure I like that idea. > Anyhow, I really don't see the need for typical users to switch between > > qt and wxt within a single gnuplot session. Especially because the > > distro-packaged gnuplot versions probably only provide one or the other, > > not both. It can be handy for a developer, yes, because you'd like to > > compare the output of the two terminals. But I don't think that's a > > particularly useful thing for a typical gnuplot session. > > So really I think this is low priority compared to some other issues. > > For instance, how about fixing the auto-scaling for image plots? > > Right now the default behavior is to auto-scale to the center of > > the 4 corner pixels, which clips all the outermost pixels in half. > > That would be OK if there were an easy way to override it, but > > many of the obvious commands don't work. > > E.g. > > set xrange [-0.5:*] # doesn't work with image data > > set offset .5, .5, .5, .5 # this doesn't work either Could you give an example? This works on my system: reset set xrange [-0.5:*] set cbrange [0:1] unset key set tics out plot '-' with rgbimage 0 0 0.0 0.0 0.5 0 1 0.0 0.5 0.0 1 0 0.5 0.0 0.5 1 1 0.0 0.5 0.5 e Although, I would point out that the Qt terminal doesn't quite layout of the pixels correctly. The left column pixels are about 5% to 10% too wide and overlap the right column pixels. The wxt terminal is better at this, but I notice that wxt has some problems when scaling the plot size. Sometimes there is a small white space between the axes and image. This sort of works: reset set offset 0.5, 0.5, 0.5, 0.5 set cbrange [0:1] unset key set tics out plot '-' with rgbimage 0 0 0.0 0.0 0.5 0 1 0.0 0.5 0.0 1 0 0.5 0.0 0.5 1 1 0.0 0.5 0.5 e but it seems to me that a 0.5 border is created, but then the autorange is taking that extra space to compute nice round numbers a little bigger than the 0.5 border, i.e., [-1:2]. We should come up with a definition for the image pixel coordinate system, if that hasn't already been done. I'm recalling confusion about one of us thinking in terms of pixel centers, while the other in terms of pixels at the coordinate system leading edge. They're both valid and the choice is somewhat arbitrary, but it would be nice to have the accepted spatial coordinate system written down so that when programming there's no doubt about how to program computations. We should have: 1) A fairly detailed statement in a code file or a text file. 2) An intricate demo plotting an image along with some lines and arrow describing what the convention is. Dan |
|
From: sfeam <sf...@us...> - 2014-10-25 22:03:40
|
On Saturday, 25 October 2014 04:46:23 PM Daniel J Sebald wrote: > On 10/25/2014 03:01 PM, sfeam wrote: > > On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote: > > > >> On 10/25/2014 01:05 PM, Bastian Märkisch wrote: > > > >> > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald: > > > >> >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote: > > > >> >> > > > >> >>> I removed the interlock test and it creates quite a mess with invalid > > > >> >>> events, seg faults in bad library calls, to scratch the surface. > > > >> >>> > > > >> >>> Investigating a bit, I think the problem lies in the fact wxt terminal > > > >> >>> is not in its own process. > > > >> >> > > > >> >> It's too much work to do this in an afternoon or so. Having looked at > > > >> >> the code, though, I'd say some things get simplified when WXT is run in > > > >> >> its own process as an outboard plotter. All these sorts of conditions > > > >> >> > > > >> >> #if defined(WXT_MONOTHREADED) || defined(_Windows) > > > >> >> > > > >> >> go away. > > > >> >> > > > >> >> Dan > > > >> > > > > >> > Btw. Timothée had been working on this years ago, see patch #380 > > > >> > https://sourceforge.net/p/gnuplot/patches/380 > > > >> > > > >> Thanks. That could save a ton on the initial tedious work of putting > > > >> bulk of the code in its own program. > > > >> > > > >> > > > >> > Also, the qt and wxt terminals run nicely in the same session on > > > >> > Windows. It just took some effort to make qt->waitforinput() work. > > > >> > > > > >> > Since waitforinput() is a terminal routine it typically only handles > > > >> > events from the library the current terminal uses. If we want to use > > > >> > multiple libraries in the same process, we need to replace/extend that > > > >> > mechanism. > > > >> > > > >> I think once the active terminal is changed, mousing and keyboard input > > > >> is disabled for others. > > > >> > > > >> > > > >> > From my experience with the (outboard) qt terminal, I sincerely doubt > > > >> > that moving the wxt terminal to its own process will significantly > > > >> > simplify the source. > > > >> > > > >> It won't simplify the source, but it will get rid of those "corner > > > >> cases". As you point out, Windows works fine for both terminals...and > > > >> that's why the things like: > > > >> > > > >> #if defined(WXT_MONOTHREADED) || defined(_Windows) > > > > Before tearing into a project to split off wxt into a separate process > > > > altogether, I think you should look into making the WXT_MONOTHREADED > > > > variant work on linux. Some/all of the problems it now has are due to > > > > the graphics event loop running in a separate thread. > > I know that Qt has a requirement that graphics be only in the main > thread. I can't verify that is the case for wxWidgets and I see some > discussion on the Web that graphics can be done in non-main threads > (sometimes with extra initialization inside the other threads). > > In any case, is that the desired setup? To have interactive graphics > running in the same thread? Doesn't that create some event management > code that typically is averted by using separate threads or processes? > > One approach might be to put what is now the main thread/code for > processing command line input into a separate thread and then leaving > the main thread for a possible interactive terminal, but not sure I like > that idea. > > > > Anyhow, I really don't see the need for typical users to switch between > > > > qt and wxt within a single gnuplot session. Especially because the > > > > distro-packaged gnuplot versions probably only provide one or the other, > > > > not both. It can be handy for a developer, yes, because you'd like to > > > > compare the output of the two terminals. But I don't think that's a > > > > particularly useful thing for a typical gnuplot session. > > > > So really I think this is low priority compared to some other issues. > > > > For instance, how about fixing the auto-scaling for image plots? > > > > Right now the default behavior is to auto-scale to the center of > > > > the 4 corner pixels, which clips all the outermost pixels in half. > > > > That would be OK if there were an easy way to override it, but > > > > many of the obvious commands don't work. > > > > E.g. > > > > set xrange [-0.5:*] # doesn't work with image data > > > > set offset .5, .5, .5, .5 # this doesn't work either > > Could you give an example? Sure. Based on the 1st plot in heatmaps.dem %%%%%% unset key set tic scale 0 # Color runs from white to green set palette rgbformula -7,2,-7 set cbrange [0:5] unset cbtics $map1 << EOD 5 4 3 1 0 2 2 0 0 1 0 0 0 1 0 0 0 0 2 3 0 1 2 4 3 EOD set view map set multiplot layout 1,2 set title "auto-scaled" splot '$map1' matrix with image set xrange [-0.5:4.5] set yrange [-0.5:4.5] set title "explicit set xrange [-0.5:4.5]" replot unset multiplot pause -1 %%%%%% Ethan > > This works on my system: > > reset > set xrange [-0.5:*] > set cbrange [0:1] > unset key > set tics out > plot '-' with rgbimage > 0 0 0.0 0.0 0.5 > 0 1 0.0 0.5 0.0 > 1 0 0.5 0.0 0.5 > 1 1 0.0 0.5 0.5 > e > > Although, I would point out that the Qt terminal doesn't quite layout of > the pixels correctly. The left column pixels are about 5% to 10% too > wide and overlap the right column pixels. The wxt terminal is better at > this, but I notice that wxt has some problems when scaling the plot > size. Sometimes there is a small white space between the axes and image. > > This sort of works: > > reset > set offset 0.5, 0.5, 0.5, 0.5 > set cbrange [0:1] > unset key > set tics out > plot '-' with rgbimage > 0 0 0.0 0.0 0.5 > 0 1 0.0 0.5 0.0 > 1 0 0.5 0.0 0.5 > 1 1 0.0 0.5 0.5 > e > > but it seems to me that a 0.5 border is created, but then the autorange > is taking that extra space to compute nice round numbers a little bigger > than the 0.5 border, i.e., [-1:2]. > > We should come up with a definition for the image pixel coordinate > system, if that hasn't already been done. I'm recalling confusion about > one of us thinking in terms of pixel centers, while the other in terms > of pixels at the coordinate system leading edge. They're both valid and > the choice is somewhat arbitrary, but it would be nice to have the > accepted spatial coordinate system written down so that when programming > there's no doubt about how to program computations. We should have: > > 1) A fairly detailed statement in a code file or a text file. > > 2) An intricate demo plotting an image along with some lines and arrow > describing what the convention is. > > Dan > > ------------------------------------------------------------------------------ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: <pl...@pi...> - 2014-10-27 20:30:08
|
On 10/27/14 19:53, Ethan A Merritt wrote: > I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget. > > The very first time you use it, the state of the toggle button may not be > reported correctly because the corresponding state variable doesn't exist > in your previous saved-state file. But once you've exited the program > that first time, causing the saved-state to be updated, everything should work > correcly in subsequent sessions. > > I also have code to add save-to-png-file to the wxt toolbar. > But I haven't worked with this toolkit before and I haven't found a > decent worked example to show how to embed this in a pull-down menu. > So as before ... > >> >Patches welcome. > Ethan > Nice addition Ethan, thanks for putting that in. Having to hit replot every time I resize wxt was always a drag but never seemed important enough to mention. I'm not sure what purpose there is in the toggle option, when is it useful to have the plot temporarily not match the new terminal size? Surely if the user resizes the terminal it is with the intention to resize the graph, which will happen next time anything is plotted or replotted. I'm not a hard-line GUI minimalist but this toggle seems like feature clutter. Peter. |
|
From: Ethan A M. <sf...@us...> - 2014-10-27 21:00:08
|
On Monday, 27 October, 2014 21:30:04 pl...@pi... wrote: > On 10/27/14 19:53, Ethan A Merritt wrote: > > I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget. > > > > The very first time you use it, the state of the toggle button may not be > > reported correctly because the corresponding state variable doesn't exist > > in your previous saved-state file. But once you've exited the program > > that first time, causing the saved-state to be updated, everything should work > > correcly in subsequent sessions. > > > > I also have code to add save-to-png-file to the wxt toolbar. > > But I haven't worked with this toolkit before and I haven't found a > > decent worked example to show how to embed this in a pull-down menu. > > So as before ... > > > >> >Patches welcome. > > Ethan > > > > Nice addition Ethan, thanks for putting that in. Having to hit replot > every time I resize wxt was always a drag but never seemed important > enough to mention. I'm not sure what purpose there is in the toggle > option, when is it useful to have the plot temporarily not match the new > terminal size? If you resize a complex 3D plot (e.g. the ones in transparent_solids.dem) resizing the window can get really slow. Same thing for a comutationally intensive 2D plot. It gets _really_ slow in some cases. For instance, I have some data-plotting scripts that take ~5 seconds to redraw the plot. Not so bad if the reason for redrawing is to change the data file. But resizing the plot triggers the redraw multiple times, so it can be more than a minute before the display settles down again. I would normally keep this option "off". A better fix would be to only refresh when the resizing operation stops. I'm sure that's possible, but would require bookkeeping that isn't in there at present. Ethan > Surely if the user resizes the terminal it is with the > intention to resize the graph, which will happen next time anything is > plotted or replotted. > > I'm not a hard-line GUI minimalist but this toggle seems like feature > clutter. > > Peter. |
|
From: <pl...@pi...> - 2014-10-28 10:27:39
|
On 10/27/14 21:58, Ethan A Merritt wrote: > > On Monday, 27 October, 2014 21:30:04 pl...@pi... wrote: >> On 10/27/14 19:53, Ethan A Merritt wrote: >>> I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget. >>> >>> The very first time you use it, the state of the toggle button may not be >>> reported correctly because the corresponding state variable doesn't exist >>> in your previous saved-state file. But once you've exited the program >>> that first time, causing the saved-state to be updated, everything should work >>> correcly in subsequent sessions. >>> >>> I also have code to add save-to-png-file to the wxt toolbar. >>> But I haven't worked with this toolkit before and I haven't found a >>> decent worked example to show how to embed this in a pull-down menu. >>> So as before ... >>> >>>>> Patches welcome. >>> Ethan >>> >> >> Nice addition Ethan, thanks for putting that in. Having to hit replot >> every time I resize wxt was always a drag but never seemed important >> enough to mention. I'm not sure what purpose there is in the toggle >> option, when is it useful to have the plot temporarily not match the new >> terminal size? > > If you resize a complex 3D plot (e.g. the ones in transparent_solids.dem) > resizing the window can get really slow. Same thing for a comutationally > intensive 2D plot. It gets _really_ slow in some cases. For instance, > I have some data-plotting scripts that take ~5 seconds to redraw the plot. > Not so bad if the reason for redrawing is to change the data file. > But resizing the plot triggers the redraw multiple times, so it can be > more than a minute before the display settles down again. > I would normally keep this option "off". > > A better fix would be to only refresh when the resizing operation stops. > I'm sure that's possible, but would require bookkeeping that isn't in there > at present. > > Ethan > OK, that makes a lot of sense. I use wxt almost exclusively so did not realise that there were multiple re-drawings being triggered in other terminals resize ops. Obviously redrawing the plot while a resize is in progress is very wasteful. A simple test for mouse button pressed status could prevent this and would seem to be a simple test rather than book-keeping ( does anyone resize using keyboard? ). This also points out the need for a means to interrupt a plot process. I have hit this before when I did something unintentional and it got locked into doing something for several minutes without any apparent means to stop it without using kill -9 gnuplot ! Maybe there should be some periodic check for Esc or cntl-c keypress during plotting. Peter. |
|
From: Ethan A M. <sf...@us...> - 2014-10-31 00:04:24
|
On Thursday, 23 October, 2014 23:18:12 Philipp K. Janert wrote: > > I think it would be wonderful if both current > interactive terminals (Qt and wxt) would allow > the user to "save" the current graph to file in > a range of file formats (basically PNG and PDF). This thread kind of diverged into discussion of other things, but thanks in large part to Dan Sebald there is now an Export to File widget on the wxt terminal toolbar. It supports output to png, pdf, or svg. I added it to cvs for 5.1 but I'd like to hear whether it does or doesn't work on Windows and OSX before deciding whether to include it in the 5.0 release. I'm also curious how widespread the wxt support for svg output is. If your local cairo installation doesn't support it then you should get an error message. The qt terminal already has such a widget. Ethan |
|
From: Jun T. <tak...@kb...> - 2014-10-31 18:57:10
|
I haven't been following this long thread, but 2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote: > I added it to cvs for 5.1 but I'd like to hear whether it does or > doesn't work on Windows and OSX I tried cvs HEAD and the Export to File works fine on OSX, but the Copy to clipboard (pasteboard) button is now gone. Is it possible to have both? When copying the plot to the clipboard, I prefer PDF format rather than PNG (either on wxt or qt). Is this possible? It would be also great if I can copy the plot just by typing cmd-C (Mac) or ctrl-C (Windows/Unix, or other key if ctrl-C can cause interrupt). |
|
From: Ethan A M. <sf...@us...> - 2014-10-31 19:22:23
|
On Saturday, 01 November, 2014 03:57:01 Jun T. wrote:
> I haven't been following this long thread, but
>
> 2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote:
> > I added it to cvs for 5.1 but I'd like to hear whether it does or
> > doesn't work on Windows and OSX
>
> I tried cvs HEAD and the Export to File works fine on OSX,
> but the Copy to clipboard (pasteboard) button is now gone.
> Is it possible to have both?
I agree. I was hoping that someone, maybe Dan Sebald, can find a
clever way to make "clipboard" act like a filetype in the selection widget.
> When copying the plot to the clipboard, I prefer PDF format rather than
> PNG (either on wxt or qt). Is this possible?
I don't know.
> It would be also great if I can copy the plot just by typing cmd-C (Mac)
> or ctrl-C (Windows/Unix, or other key if ctrl-C can cause interrupt).
Petr Mikulik mentioned that there is an undocumented command
"screendump". I did not know about this. If "screendump" works
on your system, then I would expect that you can bind it to whatever
key you like using the "bind" command.
bind "ctrl-c" "screendump"
But right now I think this command must only exist for Windows.
Petr said:
> This reminds me: there is an undocumented command for printing
> the current graph (i.e. for showing a Print(er) dialog):
> screendump
> This, however, works for the "windows" terminal only, otherwise
> gnuplot says
> screendump not implemented
Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-10-31 19:50:38
|
On 10/31/2014 02:21 PM, Ethan A Merritt wrote: > On Saturday, 01 November, 2014 03:57:01 Jun T. wrote: > >> I haven't been following this long thread, but > >> > >> 2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote: > >> > I added it to cvs for 5.1 but I'd like to hear whether it does or > >> > doesn't work on Windows and OSX > >> > >> I tried cvs HEAD and the Export to File works fine on OSX, > >> but the Copy to clipboard (pasteboard) button is now gone. > >> Is it possible to have both? > > I agree. I was hoping that someone, maybe Dan Sebald, can find a > > clever way to make "clipboard" act like a filetype in the selection widget. > >> When copying the plot to the clipboard, I prefer PDF format rather than > >> PNG (either on wxt or qt). Is this possible? > > I don't know. I think it would be possible to derive a custom button from the standard button and add a right mouse click handler to the event table. How about right mouse click on the clipboard icon opens a dialog or drop down menu that configures the image format saved to file? To make things more clear, the format, e.g., "png", "pdf", "svg" could be superimposed on the clipboard icon with the format selection. And maybe change the tool tip to read "Left Click: Copy, Right Click: Configure". Dan |
|
From: Jun T. <tak...@kb...> - 2014-11-10 16:54:13
|
2014/11/09 16:26, Daniel J Sebald <dan...@ie...> wrote: > Jun, do you have some program/application in mind that might accept PDF from the clipboard? Sorry, I'm not using Linux for creating documents or read/write mails. On Mac OS X, aquaterm (set term aqua) can copy a plot in PDF, and many apps (Pages, Keynote, MS Office, many drawing/graphics apps, etc.) accept it. If I paste it to a composing window of Mail.app, it becomes an attachment in PDF. Probably there are only few gnuplot users on Mac. If so, supporting PDF clipboard by wxt/qt on Mac would not be a high priority. Aquaterm works fine and, for most of the cases, enough for me. But I guess copying a plot in a vector format (SVG ?) would also be useful on Linux (assuming there are many apps which accept SVG from clipboard). Or is this already possible? |
|
From: Daniel J S. <dan...@ie...> - 2014-11-10 18:24:50
|
[Change of subject thread from "Re: Proposal: Saving graphs from Qt and wxt terminals"] On 11/10/2014 10:54 AM, Jun T. wrote: > 2014/11/09 16:26, Daniel J Sebald<dan...@ie...> wrote: >> Jun, do you have some program/application in mind that might accept PDF from the clipboard? > > Sorry, I'm not using Linux for creating documents or read/write mails. > > On Mac OS X, aquaterm (set term aqua) can copy a plot in PDF, and many apps > (Pages, Keynote, MS Office, many drawing/graphics apps, etc.) accept it. If I > paste it to a composing window of Mail.app, it becomes an attachment in PDF. > > Probably there are only few gnuplot users on Mac. If so, supporting PDF > clipboard by wxt/qt on Mac would not be a high priority. > Aquaterm works fine and, for most of the cases, enough for me. > > But I guess copying a plot in a vector format (SVG ?) would also be useful on > Linux (assuming there are many apps which accept SVG from clipboard). > Or is this already possible? Useful? Probably. Already possibly? Don't know. But from this FAQ on something called Inkscape, my guess would be "No" or "Maybe, but not fundamentally": http://wiki.inkscape.org/wiki/index.php/Frequently_asked_questions#Copying_and_pasting_in_Inkscape_creates_pixellated_images_instead_of_copying_the_vector_objects The way the answer is worded suggests that Mac OS X clipboard is more robust than X11 clipboard. That's likely the main difference here, and in the case of Linux it sounds like GTK/KDE may have clipboard support which is different--my guess being that KDE attempts to extend the X11 clipboard capabilities more than GTK does. I've searched for some definitive X11 documentation on the limitations and and future changes/additions for clipboard support, e.g., https://www.xpra.org/trac/wiki/Clipboard and I'm none the wiser for it. The questions I wonder are, Why the X11 clipboard doesn't seem to have emerging, more robust support for formats? and Is there something that has emerged that serves as a standard for more formats thereby dampening the need for X11 to add better support? Might MIME be something used in clipboards these days? Here is the MIME for svg: image/svg+xml The Qt documentation has a discussion about MIME (whereas wxWidgets appear not to): http://qt-project.org/doc/qt-4.8/qclipboard.html#setMimeData Quote: QClipboard features some convenience functions to access common data types: setText() allows the exchange of Unicode text and setPixmap() and setImage() allows the exchange of QPixmaps and QImages between applications. The setMimeData() function is the ultimate in flexibility: it allows you to add any QMimeData into the clipboard. Notice "ultimate in flexibility". Does that apply only to email interchange? Or does it open the door to many applications on an X11-based desktop environment? Perhaps I'll switch over to Qt terminal and experiment there a bit. Dan |
|
From: Daniel J S. <dan...@ie...> - 2014-11-10 18:35:06
|
On 11/10/2014 12:24 PM, Daniel J Sebald wrote: > Might MIME be something used in clipboards these days? Here is the MIME > for svg: > > image/svg+xml A bit more info: http://www.ietf.org/rfc/rfc3023.txt 8.19 Image/svg+xml Content-type: image/svg+xml <?xml version="1.0" ?> Scalable Vector Graphics (SVG) documents are XML documents whose content describes graphical information, as defined by [SVG]. As a format based on XML, SVG documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for SVG and so this media type should not be used until such registration has been completed. |
|
From: Daniel J S. <dan...@ie...> - 2014-11-09 07:27:04
|
On 10/31/2014 02:50 PM, Daniel J Sebald wrote: > On 10/31/2014 02:21 PM, Ethan A Merritt wrote: >> On Saturday, 01 November, 2014 03:57:01 Jun T. wrote: [snip] >>> When copying the plot to the clipboard, I prefer PDF format rather than >> >>> PNG (either on wxt or qt). Is this possible? >> >> I don't know. > > I think it would be possible to derive a custom button from the standard > button and add a right mouse click handler to the event table. How > about right mouse click on the clipboard icon opens a dialog or drop > down menu that configures the image format saved to file? To make > things more clear, the format, e.g., "png", "pdf", "svg" could be > superimposed on the clipboard icon with the format selection. And maybe > change the tool tip to read "Left Click: Copy, Right Click: Configure". Ethan and I looked at the clipboard a bit. He wondered if it even makes sense to put something in the clipboard of a particular format like PDF, or PNG. I'm starting to wonder that as well. There is a way to create a PNG type of bitmap and then place that in the clipboard. However, I think this is done by converting that PNG bitmap to an internal clipboard BITMAP. I can create custom data objects to place in the clipboard and assign them names like "png", but other programs don't seem to highlight the "Paste" text in the menu for a data format like that. (I.e., the calling program doesn't know what a "png" data object is.) Jun, do you have some program/application in mind that might accept PDF from the clipboard? So, right now the capability is there, but the utility of it is in question. But this brings to mind that HTML is one of the internal clipboard formats. I think I'm going to try figuring out how to place and HTML version of the plot in the clipboard along with the BITMAP (it can be multiple types of data). It seems to me that being able to paste into an email composer is one of the nicer features, as it means one doesn't have to first save the plot to a file, then to email composer. Dan |
|
From: Daniel J S. <dan...@ie...> - 2014-11-09 18:55:36
|
On 11/09/2014 01:26 AM, Daniel J Sebald wrote: > So, right now the capability is there, but the utility of it is in > question. But this brings to mind that HTML is one of the internal > clipboard formats. I think I'm going to try figuring out how to place > and HTML version of the plot in the clipboard along with the BITMAP (it > can be multiple types of data). It seems to me that being able to paste > into an email composer is one of the nicer features, as it means one > doesn't have to first save the plot to a file, then to email composer. Are others able to copy from the WXT terminal and paste into HTML-based email composers? Yes or no, please indicate your desktop environment and email composer. Thanks, Dan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2014-11-01 01:27:22
|
Am 31.10.2014 um 20:21 schrieb Ethan A Merritt: > On Saturday, 01 November, 2014 03:57:01 Jun T. wrote: > > It would be also great if I can copy the plot just by typing cmd-C (Mac) > > > or ctrl-C (Windows/Unix, or other key if ctrl-C can cause interrupt). > > Petr Mikulik mentioned that there is an undocumented command > "screendump". I did not know about this. Well, it's not strictly undocumented. The documentation is just stuck away inside the chapter about the (so far) only terminal driver that command exists in: see "help windows printing" (or term/win.trm around line 1120, if you don't have a Windows version of gnuplot at hand). But if a feature like this is extended to other drivers, the command and its documentation should probably move up into "help commands" |
|
From: Ethan A M. <sf...@us...> - 2014-10-31 20:20:09
|
On Friday, 31 October, 2014 14:50:18 Daniel J Sebald wrote: > On 10/31/2014 02:21 PM, Ethan A Merritt wrote: > > On Saturday, 01 November, 2014 03:57:01 Jun T. wrote: > > > >> I haven't been following this long thread, but > > > >> > > > >> 2014/10/31 09:03, Ethan A Merritt <sf...@us...> wrote: > > > >> > I added it to cvs for 5.1 but I'd like to hear whether it does or > > > >> > doesn't work on Windows and OSX > > > >> > > > >> I tried cvs HEAD and the Export to File works fine on OSX, > > > >> but the Copy to clipboard (pasteboard) button is now gone. > > > >> Is it possible to have both? > > > > I agree. I was hoping that someone, maybe Dan Sebald, can find a > > > > clever way to make "clipboard" act like a filetype in the selection widget. > > > >> When copying the plot to the clipboard, I prefer PDF format rather than > > > >> PNG (either on wxt or qt). Is this possible? > > > > I don't know. > > I think it would be possible to derive a custom button from the standard > button and add a right mouse click handler to the event table. That's more complicated that I had in mind. I was thinking that "clipboard" would be a label in the file-selector widget (that part is easy), but unlike the others it would not require a file name (that is the part I got stuck on). I can make it copy to the clipboard just fine, but only if I first click on or type some junk file name. > How > about right mouse click on the clipboard icon opens a dialog or drop > down menu that configures the image format saved to file? To make > things more clear, the format, e.g., "png", "pdf", "svg" could be > superimposed on the clipboard icon with the format selection. And maybe > change the tool tip to read "Left Click: Copy, Right Click: Configure". Maybe. My inclination is that if you want a file then Export-to-File is the right thing to look for. The clipboard is typically used for cut-and-paste, and I don't think many program are expected a paste operation to contain pdf or svg. Or we could just put the Clipboard icon back as a separate widget. That is easy but IMHO kind of ugly compared to grouping all the export options in a single place. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-10-31 21:04:39
|
On 10/31/2014 03:16 PM, Ethan A Merritt wrote: > On Friday, 31 October, 2014 14:50:18 Daniel J Sebald wrote: >> On 10/31/2014 02:21 PM, Ethan A Merritt wrote: >>> On Saturday, 01 November, 2014 03:57:01 Jun T. wrote: >>> >>>> I haven't been following this long thread, but >>> >>>> >>> >>>> 2014/10/31 09:03, Ethan A Merritt<sf...@us...> wrote: >>> >>>> > I added it to cvs for 5.1 but I'd like to hear whether it does or >>> >>>> > doesn't work on Windows and OSX >>> >>>> >>> >>>> I tried cvs HEAD and the Export to File works fine on OSX, >>> >>>> but the Copy to clipboard (pasteboard) button is now gone. >>> >>>> Is it possible to have both? >>> >>> I agree. I was hoping that someone, maybe Dan Sebald, can find a >>> >>> clever way to make "clipboard" act like a filetype in the selection widget. >>> >>>> When copying the plot to the clipboard, I prefer PDF format rather than >>> >>>> PNG (either on wxt or qt). Is this possible? >>> >>> I don't know. >> >> I think it would be possible to derive a custom button from the standard >> button and add a right mouse click handler to the event table. > > That's more complicated that I had in mind. This is actually one of the easier approaches I've come across having dug into WXT a bit. > I was thinking that "clipboard" would be a label in the file-selector widget > (that part is easy), but unlike the others it would not require a file name > (that is the part I got stuck on). I can make it copy to the clipboard just > fine, but only if I first click on or type some junk file name. Yeah, the dialog must have some type of filename, otherwise it doesn't pass the wxID_OK event further on to the dialog. Unfortunately, the logic for this is in the particular tookkits and not in a generic location where one could make an easy change. Here's GTK, for example: https://github.com/LuaDist/wxwidgets/blob/master/src/gtk/filedlg.cpp WXT has a bit of limitation in the sense that it is difficult to program in front of a widget operation. There's access after a widget has done something and indicates an event, but not before. E.g., I'm finding it quite difficult to get at the program flow before the "Save" button does its file-exists check. >> How >> about right mouse click on the clipboard icon opens a dialog or drop >> down menu that configures the image format saved to file? To make >> things more clear, the format, e.g., "png", "pdf", "svg" could be >> superimposed on the clipboard icon with the format selection. And maybe >> change the tool tip to read "Left Click: Copy, Right Click: Configure". > > Maybe. My inclination is that if you want a file then Export-to-File is > the right thing to look for. The clipboard is typically used for cut-and-paste, > and I don't think many program are expected a paste operation to > contain pdf or svg. I agree with that. But there are a number of formats for which cut-and-paste will work. > Or we could just put the Clipboard icon back as a separate widget. > That is easy but IMHO kind of ugly compared to grouping all the > export options in a single place. That was what I was thinking when I queried the discussion list. The clipboard icon would be present, but it could be easily configured for the image format. Copying to clipboard should be a one-step operation. Opening a dialog and then doing another action to copy to clipboard seems too much. But if one were to go that route, maybe adding a third button to the file dialog, i.e., "Cancel", "Copy To Clipboard" and "Save" would be the most straightforward. That then is just one additional step (provided the file type remains sticky, for which I just about have a patch ready). Think it over. I can program something this weekend. Dan |
|
From: Jun T. <tak...@kb...> - 2014-11-01 08:16:05
|
I don't feel it ugly to have separate buttons for Copy and Export. If I can copy by keyboard shortcut (ctr-C etc.) then I don't need a separate button for Copy, of course. But If that is not possible, then I prefer a separate button for Copy rather than to open a dialog and push one or more buttons there. On Mac, copy/paste in pdf is supported by many applications. On Windows, many applications may support EMF but I'm not sure. I personally use copy/paste in pdf (by aqua terminal) much more frequently than save into file. But each user may have his/her own way of using gnuplot. |
|
From: Philipp K. J. <ja...@ie...> - 2014-11-01 16:24:50
|
On Sat, 1 Nov 2014 17:15:55 +0900 "Jun T." <tak...@kb...> wrote: > I don't feel it ugly to have separate buttons for Copy and Export. I would agree! > > If I can copy by keyboard shortcut (ctr-C etc.) then I don't need > a separate button for Copy, of course. But If that is not possible, > then I prefer a separate button for Copy rather than to open a dialog > and push one or more buttons there. > > On Mac, copy/paste in pdf is supported by many applications. > On Windows, many applications may support EMF but I'm not sure. > > I personally use copy/paste in pdf (by aqua terminal) much more > frequently than save into file. But each user may have his/her own > way of using gnuplot. > > ------------------------------------------------------------------------------ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
