gnuplot-beta — Developers and beta testers of new gnuplot code

Re: change handling of time data for 5.0?

[sfeam <sf...@us...>]

On Saturday, 04 October 2014 08:37:17 PM Karl Ratzsch wrote:
> On 04.10.2014 02:17, Ethan A Merritt wrote:
> > On Friday, 03 October, 2014 15:04:07 Karl Ratzsch wrote:
> >> Would it be difficult to make the second parameter to timecolumn()
> >> optional, and use whatever is set via "set timefmt" if no format
> >> string is given?
> > 
> > Yes, it is possible to trap the case of a single parameter and
> > fall back to a default timefmt. That loses the ability to have
> > separate default formats for the x and y axes, but see below.
> > 
> > The whole idea of having the time format be per-axis rather than
> > per-datafile makes little sense to me. So I'm now thinking we could
> > remove the timefmt field from (struct axis) and have one global default.
> > This is in fact what the 4.6 documentation describes, even though
> > it hasn't been true for a very long time. So although it would
> > internally be a change, it would keep the previous documentated 
> > behavior. It would only affect scripts that used the undocumented 
> > command: set timefmt y "format".
> 
> Even that can be kept, imo. timecolumn() could check for a format
> string as (in that order) second parameter, in timefmt <colnum>
> (new), timefmt <x/y), general timefmt, and use the first it finds set.

That isn't possible, because at the level of interpretation where
f_timecolumn() receives control it has no idea which axis may or
may not be involved.  So it can't look up a per-axis quantity.
This wasn't working reliably in earlier versions either, which was
part of the reason for adding the second parameter.

Since the per-axis timeformat was not reliable and was never
documented anyhow (perhaps for that reason?), I don't feel badly about
failing to provide a 100% backwards-compatible replacement.

I have a patch to provide backwards compatibility for the common case:

   plot <foo> using (timecolumn(N)):M

It does not catch more complicated cases in which the timecolumn()
call is part of a longer expression, as in

   plot <foo> using (Offset_2_weeks + timecolumn(N)):M

I don't see a way to catch that without adding additional bookkeeping
code to the expression parsing.  That might be worth looking into
at some point, but right now it would be a major distraction.

	Ethan

Re: change handling of time data for 5.0?

[Karl R. <ra...@un...>]

On 04.10.2014 02:17, Ethan A Merritt wrote:
> On Friday, 03 October, 2014 15:04:07 Karl Ratzsch wrote:
>> Would it be difficult to make the second parameter to timecolumn()
>> optional, and use whatever is set via "set timefmt" if no format
>> string is given?
> 
> Yes, it is possible to trap the case of a single parameter and
> fall back to a default timefmt. That loses the ability to have
> separate default formats for the x and y axes, but see below.
> 
> The whole idea of having the time format be per-axis rather than
> per-datafile makes little sense to me. So I'm now thinking we could
> remove the timefmt field from (struct axis) and have one global default.
> This is in fact what the 4.6 documentation describes, even though
> it hasn't been true for a very long time. So although it would
> internally be a change, it would keep the previous documentated 
> behavior. It would only affect scripts that used the undocumented 
> command: set timefmt y "format".

Even that can be kept, imo. timecolumn() could check for a format
string as (in that order) second parameter, in timefmt <colnum>
(new), timefmt <x/y), general timefmt, and use the first it finds set.

  Karl


-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum, Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg i. Br.
Tel.: 0761/203-4748 Fax: -4701

Re: change handling of time data for 5.0?

[<pl...@pi...>]

On 10/04/14 02:17, Ethan A Merritt wrote:
> Yes, it is possible to trap the case of a single parameter and
>
> fall back to a default timefmt. That loses the ability to have
>
> separate default formats for the x and y axes, but see below.
>

I was going to suggest this myself. It would be preferable to maintain 
b/w compatibility if possible. While there is the possibility due to 
major version change this should only be exercised when there is a clear 
need to do so. IMO.

Peter.

Re: change handling of time data for 5.0?

[Ethan A M. <sf...@us...>]

On Friday, 03 October, 2014 15:04:07 Karl Ratzsch wrote:

> > We already broke some backwards compatibility by adding a 2nd
> > parameter to
> > timecolumn(). The new version obviates the need for "set xdata time" to
> > handle input, although arguably it is uglier to put the information
> > in the
> > "using" part of every plot command rather than setting it only once via
> > "set xdata time; set timefmt x 'foo'".
> 
> Would it be difficult to make the second parameter to timecolumn()
> optional, and use whatever is set via "set timefmt" if no format
> string is given?

Yes, it is possible to trap the case of a single parameter and
fall back to a default timefmt.  That loses the ability to have
separate default formats for the x and y axes, but see below.

The whole idea of having the time format be per-axis rather than
per-datafile makes little sense to me.  So I'm now thinking we could
remove the timefmt field from (struct axis) and have one global default.
This is in fact what the 4.6 documentation describes, even though
it hasn't been true for a very long time.  So although it would
internally be a change, it would keep the previous documentated
behavior.  It would only affect scripts that used the undocumented
command: set timefmt y "format".

	Ethan

Re: change handling of time data for 5.0?

[Karl R. <ra...@un...>]

On 02.10.2014 19:55, Ethan A Merritt wrote:
> https://sourceforge.net/p/gnuplot/feature-requests/392/
> which points out that it's really annoying if a quantity that represents
> elapsed time is treated as a date rather than simply some number of
> days+hours+minutes+seconds. In that particular use case the
> quantity is a vector length, not an axis coordinate per se,
> so "set xtics time" would not really fill the need. Yes the x coordinate
> is a date, but the vector length is elapsed time - two different formats
> are required.

Right, "date" is a more appropriate name for the option to "set
xtics"/"set format". Later a new option "time" can be introduced,
which checks for the biggest unit in the format string and
consequently does not wrap e.g. at 24hs. Other format string
varieties ("numeral","geographic", ...) can be added as necessary.

For tabular output, "set format <>" could be extended to allow
setting the format for individual column numbers.


> We already broke some backwards compatibility by adding a 2nd
> parameter to
> timecolumn(). The new version obviates the need for "set xdata time" to
> handle input, although arguably it is uglier to put the information
> in the
> "using" part of every plot command rather than setting it only once via
> "set xdata time; set timefmt x 'foo'".

Would it be difficult to make the second parameter to timecolumn()
optional, and use whatever is set via "set timefmt" if no format
string is given?

Alternatively, new command
"set data <coln> [time/numeral/...] <formatstring>" ?


  Karl

Re: change handling of time data for 5.0?

[Ethan A M. <sf...@us...>]

On Thursday, 02 October, 2014 14:57:15 Karl Ratzsch wrote:
> 
> With the new version of the timecolumn() function now including a format
> string, i think it is time to deprecate the use of the "set xdata time"
> / "set timefmt" combination,
> the former influencing inconveniently both input and output.

I agree that it would be worth re-thinking these commands.

> This would technically (as I see) only need a new option "time" to "set
> xtics" so the interpretation of the output format string can be
> controlled without "set xdata time".

It's more complicated than that.

For one thing, the desire for time formats is not limited to axis labeling,
and even when labeling an axis it does not follow that "time" is the same
thing as "date".

See for example 
   https://sourceforge.net/p/gnuplot/feature-requests/392/
which points out that it's really annoying if a quantity that represents
elapsed time is treated as a date rather than simply some number of
days+hours+minutes+seconds.  In that particular use case the
quantity is a vector length, not an axis coordinate per se, 
so "set xtics time" would not really fill the need.  Yes the x coordinate
is a date, but the vector length is elapsed time - two different formats
are required.

> Worst part of this would probably be rewriting a lot of documentation,
> for which i´d volunteer. Do this for gp50? 

It turns out the current documentation for "set timefmt" is simply wrong
(left over from version 4.4 I guess).  I did a quick re-write yesterday for
inclusion in v5, but yes it would be nice to have a more comprehensive
revision, better yet if it comes with examples or demos.

> The technical change would be backward-compatible, but changes of
> recommended syntax should probably not happen at minor releases.

Input
=====

We already broke some backwards compatibility by adding a 2nd parameter to
timecolumn().   The new version obviates the need for "set xdata time" to
handle input, although arguably it is uglier to put the information in the
"using" part of every plot command rather than setting it only once via
"set xdata time; set timefmt x 'foo'".

Output
======

I think this is actually the messier part.  timecolumn() can be used to
differentiate individual columns on input, or for that matter different
formats in different input files on the same plot.   But we have no
corresponding mechanism for writing out times that are not dates.
Not for axis tic labels and certainly not for arbitrary columns written
by "set table" or "plot .... with table".

Your suggestion for a "set xtics time 'timefmt'" would partially
address this. But I think we would want to distinguish
     set xtics {time|date|numeric|geographic|other?}
And we would still need some additional way to control tabuler output.

Other issues
=================

That leaves the problem that "set xdata time; set timefmt foo" is
used to interpret axis ranges as well as input data.
This is IMHO completely confusing already, since it doesn't match
what is used to actually label the axis ("set format x").
I don't have a good suggestion on how to fix this.

Related to that, I think that mousing readout and zoom also depend
on "set xdata".

V5 supports geographic coordinates (degrees minutes seconds) for
axis labels, but not for data input.  I.e. "set xdata geographic" 
affects only the output side.  So it would go naturally into a
revised "set xtics" command and could be removed as an option to
"set xdata" since it was never in v4.

	Ethan

change handling of time data for 5.0?

[Karl R. <ra...@un...>]

With the new version of the timecolumn() function now including a format
string, i think it is time to deprecate the use of the "set xdata time"
/ "set timefmt" combination, the former influencing inconveniently both
input and output.

This would technically (as I see) only need a new option "time" to "set
xtics" so the interpretation of the output format string can be
controlled without "set xdata time".

Worst part of this would probably be rewriting a lot of documentation,
for which i´d volunteer. Do this for gp50? The technical change would be
backward-compatible, but changes of recommended syntax should probably
not happen at minor releases.

Best, Karl

-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum / Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg im Breisgau
Tel. 0761/203-4748 Fax:-4701
ra...@un...

Re: Persistent confusion about gnuplot -persist

[Jun T. <tak...@kb...>]

First of all, I personally feel the current behavior of --persist is just fine.
If an equivalent of [2] is implemented within gnuplot, what a user can do if
she/he wants to get the current behavior of [1]?

Anyway, I tested the following three commands with term=aqua/wxt/qt on my Mac
so that you can get an idea about the situation on Mac.

term=xxx	# aqua/wxt/qt
[0] gnuplot -e "set term $term; splot x*y*y"
[1] gnuplot -e "set term $term; splot x*y*y" --persist 
[2] gnuplot -e "set term $term; splot x*y*y; pause mouse close" &

(OS X 10.8.5/gnuplot-cvs/wxWidgets-svn/Qt5.3.2)

=====[[ aqua ]]=====
Aquaterm.app is an application independent of gnuplot and does not
support mouse feedback.

[0][1] The gnuplot quits immediately but the plot window survives.
The plot can't be changed by mouse (this is always the case with aqua)
but I can print or save the plot from the Aquaterm menu.

[2] The gnuplot process goes into the background, and suspended (stopped) by
'tty input'. It does not quit even when the plot window is closed.
(If I bring the gnuplot to the foreground then it quits.)
Since aqua does not support mouse, 'pause mouse close' is equivalent to
'pause -1' and gnuplot is waiting for a carriage return to be hit.

=====[[ wxt ]]=====`
On Mac OS X gnuplot handles wxt by itself (does not fork).

[0][1] A plot window opens but closes immediately, and the gnuplot quits.

[2] The plot window survives and I can rotate the plot by mouse.
But If I change the focus to the terminal window from which I started the
gnuplot and enter a next shell command (or just hit return), then the gnuplot
process (in the background) is stopped by "tty input"; I can't change the
focus back to the plot window (it does not respond). If I bring the gnuplot
to the foreground then it quits and the plot window is closed.
I haven't yet understood why this happens.

=====[[ qt ]]=====
[0] gnuplot quits and the plot window is closed immediately.
[1] gnuplot quits but the plot window (gnuplot_qt) survives;
the plot can't be rotated by mouse (of course).
[2] The plot window survives and the plot can be rotated by mouse.
If the plot window is closed then the gnuplot (in the backgrond) also quits.
Changing the focus from/to the plot window causes no problem.

To summarize, on Mac OS X, [2] works fine with qt but not with aqua/wxt
(at least currently).
But implementing [2] within gnulot may not be equivalent to putting gnuplot
into background by shell, and the 'tty input' problem would not happen
(or could be avoided).

NOTE:
I noticed the following two are equivalent:
gnuplot -e 'cmd1; cmd2'
gnuplot -e 'cmd1; cmd2; exit'

In plot.c (line 622) noinputfiles is set to FALSE if '-e cmds' is given;
the '-e cmds' is considered as a kind of "input file".
The man page of gnuplot is somewhat ambiguous about the behavior when
'-e cmds' is specified but no input file is given.

Jun

Re: Persistent confusion about gnuplot -persist

[Tatsuro M. <tma...@ya...>]

Sorry I have mistaken.

line around 455 => 1455


Tatsuro 
> 
> In command.c
> 
> 
> line around 455 => 1455
> #=====================================================================
> 
> #if defined(_Windows)
> # ifdef WXWIDGETS
> if (!strcmp(term->name, "wxt")) {
>    /* copy of the code below:  !(_Windows || OS2) */
>    if (term && term->waitforinput && paused_for_mouse){
> fprintf(stderr, "%s\n", buf);
> term->waitforinput(0);
>    } else {
> #  if defined(WGP_CONSOLE)
> fprintf(stderr, "%s\n", buf);
> if (term && term->waitforinput)
>    while (term->waitforinput(0) != (int)'\r') {}; /* waiting for 
> Enter*/
> #  else /* !WGP_CONSOLE */
> if (!Pause(buf))
>    bail_to_command_line();
> #  endif
>    }
> } else
> # endif /* _Windows && WXWIDGETS */
> 
> #=====================================================================
> 
> 
> For qt, are similar treatments required?
> 
> Sorry I do not enough time to check the matter more in detail.
> 
> Tatsuro  
> 

Re: Persistent confusion about gnuplot -persist

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: tmacchant3 Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2014/9/24, Wed 13:35
> Subject: Re: Persistent confusion about gnuplot -persist
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA 
>>  To: Merritt Ethan ; gnuplot-beta
>>  Cc: 
>>  Date: 2014/9/24, Wed 10:34
>>  Subject: Re: Persistent confusion about gnuplot -persist
>> 
>>  ----- Original Message -----
>> 
>>>   From: Ethan A Merritt 
>>>   To: gnuplot-beta; Tatsuro MATSUOKA 
>>>   Cc: 
>>>   Date: 2014/9/24, Wed 03:23
>>>   Subject: Re: Persistent confusion about gnuplot -persist
>>> 
>>>   On Tuesday, 23 September, 2014 17:54:44 Tatsuro MATSUOKA wrote:
>>>> 
>>>>    ----- Original Message -----
>>>>    > From: Ethan A Merritt
>>>>    > To: gnuplot-beta
>>>>    > Cc: 
>>>>    > Date: 2014/9/23, Tue 03:43
>>>>    > Subject: Persistent confusion about gnuplot -persist
>>>>    > 
>>>>    > 
>>>>    > There have recently been several queries, bug reports, 
> support 
>>>   requests,
>>>>    > and so on that involve misunderstanding about what to expect 
> from 
>> 
>>>>    > gnuplot -persist    or    set term <foo> persist.
>>>>    > 
>>>>    > People seem to assume that if the window is still showing on 
> the 
>>>   screen,
>>>>    > they should be able to pan/zoom/unzoom and so on using the 
> mouse
>>>>    > buttons or the widgets at the top of the terminal GUI.  
>>>>    > 
>>>>    > The documentation is quite explicit that this isn't true 
> in 
>>>   general because
>>>>    > such operations require the main program to recalculate and 
>>  redraw the
>>>>    > plot, which cannot happen in -persist mode because the main 
>>  program
>>>>    > has already exited.     As it happens, the wxt terminal back 
> in 
>>>   version 4.4
>>>>    > was an exception to this general case.  I guess people 
> remember 
>>  that 
>>>>    > exception and want to generalize it to all current 
> terminals.
>>>>    > 
>>>>    > That is, people expect this
>>>>    > 
>>>>    >     [1] gnuplot -persist -e "plot sinh(x); exit"
>>>>    > 
>>>>    > to act like this
>>>>    > 
>>>>    >     [2] gnuplot -e "plot sinh(x); pause mouse close; 
>>  exit" 
>>>   &
>>>>    > 
>>>>    > The question is, should we continue pointing to the 
> documented 
>>>   limitations
>>>>    > of "persist", or should we change what persist 
> does to 
>>  match 
>>> 
>>>>    > people's
>>>>    > expectation?  
>>>>    > 
>>>>    > So far as I know [2] works properly for the x11, wxt, and qt 
> 
>>  terminals
>>>>    > under linux.  I don't know about MSWin (win) or OSX 
> (aqua).
>>>>    > 
>>>>    > Assuming that [2] can be made to work correctly on all three 
> of 
>>  these
>>>>    > platforms, should we reimplement "set term ... 
> persist" 
>>  and 
>>>>    > "gnuplot -persist"
>>>>    > to act like this instead of retaining the current 
> implementation?
>>>>    >
>>>> 
>>>> 
>>>>    I have tested on windows (cvs changelog date is 2014-09-20)
>>>> 
>>>>    gnuplot -e "plot sinh(x); pause mouse close; exit"
>>>> 
>>>> 
>>>>    works as expected for wxt and windows terminal.
>>> 
>>>>    But for qt terminal, gnuplot exit immediately and we cannot use 
> mouse.
>>> 
>>>   Does "pause mouse close" work correctly from an interactive 
>>  session 
>>>   using qt?    
>>> 
>>>       Ethan
>> 
>> 
>>  On windows using qt  
>>  "pause mouse close" does not work correctly.
>> 
>> 
>>  The plot does not respond any mouse and keyboard operation.
>>  By closing plot by close button top right position, "gnuplot>" 
> 
>>  prompt does not appear.
>> 
>>  BTW, on windows using wxt and windows  
>>  "pause mouse close" works correctly.
>> 
> Using qt on windows, "pause mouse xxx" ("xxx" is a keyword) 
> does not work correctly
> on version 5.1.0 (ChangeLog 2014-09-24). 


In command.c


line around 455
#=====================================================================

#if defined(_Windows)
# ifdef WXWIDGETS
if (!strcmp(term->name, "wxt")) {
    /* copy of the code below:  !(_Windows || OS2) */
    if (term && term->waitforinput && paused_for_mouse){
fprintf(stderr, "%s\n", buf);
term->waitforinput(0);
    } else {
#  if defined(WGP_CONSOLE)
fprintf(stderr, "%s\n", buf);
if (term && term->waitforinput)
    while (term->waitforinput(0) != (int)'\r') {}; /* waiting for Enter*/
#  else /* !WGP_CONSOLE */
if (!Pause(buf))
    bail_to_command_line();
#  endif
    }
} else
# endif /* _Windows && WXWIDGETS */

#=====================================================================


For qt, are similar treatments required?

Sorry I do not enough time to check the matter more in detail.

Tatsuro  

Re: Persistent confusion about gnuplot -persist

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2014/9/24, Wed 10:34
> Subject: Re: Persistent confusion about gnuplot -persist
> 
> ----- Original Message -----
> 
>>  From: Ethan A Merritt 
>>  To: gnuplot-beta; Tatsuro MATSUOKA 
>>  Cc: 
>>  Date: 2014/9/24, Wed 03:23
>>  Subject: Re: Persistent confusion about gnuplot -persist
>> 
>>  On Tuesday, 23 September, 2014 17:54:44 Tatsuro MATSUOKA wrote:
>>> 
>>>   ----- Original Message -----
>>>   > From: Ethan A Merritt
>>>   > To: gnuplot-beta
>>>   > Cc: 
>>>   > Date: 2014/9/23, Tue 03:43
>>>   > Subject: Persistent confusion about gnuplot -persist
>>>   > 
>>>   > 
>>>   > There have recently been several queries, bug reports, support 
>>  requests,
>>>   > and so on that involve misunderstanding about what to expect from 
> 
>>>   > gnuplot -persist    or    set term <foo> persist.
>>>   > 
>>>   > People seem to assume that if the window is still showing on the 
>>  screen,
>>>   > they should be able to pan/zoom/unzoom and so on using the mouse
>>>   > buttons or the widgets at the top of the terminal GUI.  
>>>   > 
>>>   > The documentation is quite explicit that this isn't true in 
>>  general because
>>>   > such operations require the main program to recalculate and 
> redraw the
>>>   > plot, which cannot happen in -persist mode because the main 
> program
>>>   > has already exited.     As it happens, the wxt terminal back in 
>>  version 4.4
>>>   > was an exception to this general case.  I guess people remember 
> that 
>>>   > exception and want to generalize it to all current terminals.
>>>   > 
>>>   > That is, people expect this
>>>   > 
>>>   >     [1] gnuplot -persist -e "plot sinh(x); exit"
>>>   > 
>>>   > to act like this
>>>   > 
>>>   >     [2] gnuplot -e "plot sinh(x); pause mouse close; 
> exit" 
>>  &
>>>   > 
>>>   > The question is, should we continue pointing to the documented 
>>  limitations
>>>   > of "persist", or should we change what persist does to 
> match 
>> 
>>>   > people's
>>>   > expectation?  
>>>   > 
>>>   > So far as I know [2] works properly for the x11, wxt, and qt 
> terminals
>>>   > under linux.  I don't know about MSWin (win) or OSX (aqua).
>>>   > 
>>>   > Assuming that [2] can be made to work correctly on all three of 
> these
>>>   > platforms, should we reimplement "set term ... persist" 
> and 
>>>   > "gnuplot -persist"
>>>   > to act like this instead of retaining the current implementation?
>>>   >
>>> 
>>> 
>>>   I have tested on windows (cvs changelog date is 2014-09-20)
>>> 
>>>   gnuplot -e "plot sinh(x); pause mouse close; exit"
>>> 
>>> 
>>>   works as expected for wxt and windows terminal.
>> 
>>>   But for qt terminal, gnuplot exit immediately and we cannot use mouse.
>> 
>>  Does "pause mouse close" work correctly from an interactive 
> session 
>>  using qt?    
>> 
>>      Ethan
> 
> 
> On windows using qt  
> "pause mouse close" does not work correctly.
> 
> 
> The plot does not respond any mouse and keyboard operation.
> By closing plot by close button top right position, "gnuplot>" 
> prompt does not appear.
> 
> BTW, on windows using wxt and windows  
> "pause mouse close" works correctly.
> 
Using qt on windows, "pause mouse xxx" ("xxx" is a keyword) does not work correctly
on version 5.1.0 (ChangeLog 2014-09-24). 

Re: Persistent confusion about gnuplot -persist

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Ethan A Merritt 
> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: 
> Date: 2014/9/24, Wed 03:23
> Subject: Re: Persistent confusion about gnuplot -persist
> 
> On Tuesday, 23 September, 2014 17:54:44 Tatsuro MATSUOKA wrote:
>> 
>>  ----- Original Message -----
>>  > From: Ethan A Merritt
>>  > To: gnuplot-beta
>>  > Cc: 
>>  > Date: 2014/9/23, Tue 03:43
>>  > Subject: Persistent confusion about gnuplot -persist
>>  > 
>>  > 
>>  > There have recently been several queries, bug reports, support 
> requests,
>>  > and so on that involve misunderstanding about what to expect from 
>>  > gnuplot -persist    or    set term <foo> persist.
>>  > 
>>  > People seem to assume that if the window is still showing on the 
> screen,
>>  > they should be able to pan/zoom/unzoom and so on using the mouse
>>  > buttons or the widgets at the top of the terminal GUI.  
>>  > 
>>  > The documentation is quite explicit that this isn't true in 
> general because
>>  > such operations require the main program to recalculate and redraw the
>>  > plot, which cannot happen in -persist mode because the main program
>>  > has already exited.     As it happens, the wxt terminal back in 
> version 4.4
>>  > was an exception to this general case.  I guess people remember that 
>>  > exception and want to generalize it to all current terminals.
>>  > 
>>  > That is, people expect this
>>  > 
>>  >     [1] gnuplot -persist -e "plot sinh(x); exit"
>>  > 
>>  > to act like this
>>  > 
>>  >     [2] gnuplot -e "plot sinh(x); pause mouse close; exit" 
> &
>>  > 
>>  > The question is, should we continue pointing to the documented 
> limitations
>>  > of "persist", or should we change what persist does to match 
> 
>>  > people's
>>  > expectation?  
>>  > 
>>  > So far as I know [2] works properly for the x11, wxt, and qt terminals
>>  > under linux.  I don't know about MSWin (win) or OSX (aqua).
>>  > 
>>  > Assuming that [2] can be made to work correctly on all three of these
>>  > platforms, should we reimplement "set term ... persist" and 
>>  > "gnuplot -persist"
>>  > to act like this instead of retaining the current implementation?
>>  >
>> 
>> 
>>  I have tested on windows (cvs changelog date is 2014-09-20)
>> 
>>  gnuplot -e "plot sinh(x); pause mouse close; exit"
>> 
>> 
>>  works as expected for wxt and windows terminal.
> 
>>  But for qt terminal, gnuplot exit immediately and we cannot use mouse.
> 
> Does "pause mouse close" work correctly from an interactive session 
> using qt?    
> 
>     Ethan


On windows using qt  
"pause mouse close" does not work correctly.


The plot does not respond any mouse and keyboard operation.
By closing plot by close button top right position, "gnuplot>" prompt does not appear.

BTW, on windows using wxt and windows  
"pause mouse close" works correctly.

 
Tatsuro

Re: Persistent confusion about gnuplot -persist

[Ethan A M. <sf...@us...>]

On Tuesday, 23 September, 2014 17:54:44 Tatsuro MATSUOKA wrote:
> 
> ----- Original Message -----
> > From: Ethan A Merritt
> > To: gnuplot-beta
> > Cc: 
> > Date: 2014/9/23, Tue 03:43
> > Subject: Persistent confusion about gnuplot -persist
> > 
> > 
> > There have recently been several queries, bug reports, support requests,
> > and so on that involve misunderstanding about what to expect from 
> > gnuplot -persist    or    set term <foo> persist.
> > 
> > People seem to assume that if the window is still showing on the screen,
> > they should be able to pan/zoom/unzoom and so on using the mouse
> > buttons or the widgets at the top of the terminal GUI.  
> > 
> > The documentation is quite explicit that this isn't true in general because
> > such operations require the main program to recalculate and redraw the
> > plot, which cannot happen in -persist mode because the main program
> > has already exited.     As it happens, the wxt terminal back in version 4.4
> > was an exception to this general case.  I guess people remember that 
> > exception and want to generalize it to all current terminals.
> > 
> > That is, people expect this
> > 
> >     [1] gnuplot -persist -e "plot sinh(x); exit"
> > 
> > to act like this
> > 
> >     [2] gnuplot -e "plot sinh(x); pause mouse close; exit" &
> > 
> > The question is, should we continue pointing to the documented limitations
> > of "persist", or should we change what persist does to match 
> > people's
> > expectation?  
> > 
> > So far as I know [2] works properly for the x11, wxt, and qt terminals
> > under linux.  I don't know about MSWin (win) or OSX (aqua).
> > 
> > Assuming that [2] can be made to work correctly on all three of these
> > platforms, should we reimplement "set term ... persist" and 
> > "gnuplot -persist"
> > to act like this instead of retaining the current implementation?
> >
> 
> 
> I have tested on windows (cvs changelog date is 2014-09-20)
> 
> gnuplot -e "plot sinh(x); pause mouse close; exit"
> 
> 
> works as expected for wxt and windows terminal.

> But for qt terminal, gnuplot exit immediately and we cannot use mouse.

Does "pause mouse close" work correctly from an interactive session using qt?     

	Ethan


> 
> For windows, there is not "fork" function so that persist mode works differently from other platforms.
> In persist mode (case [1]), 
> gnuplot session does not terminated so that we can use mouse for windows and wxt 
> terminal. 
> 
> For qt terminal, perhaps gnuplot session is terminated but gnuplot_qt process exists.
> We cannot use mouse for zoom for qt terminal.

Yes. That is the documented behavior.   But it seems to surprise some people.

> 
> Tatsuro

Re: Persistent confusion about gnuplot -persist

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> From: Ethan A Merritt
> To: gnuplot-beta
> Cc: 
> Date: 2014/9/23, Tue 03:43
> Subject: Persistent confusion about gnuplot -persist
> 
> 
> There have recently been several queries, bug reports, support requests,
> and so on that involve misunderstanding about what to expect from 
> gnuplot -persist    or    set term <foo> persist.
> 
> People seem to assume that if the window is still showing on the screen,
> they should be able to pan/zoom/unzoom and so on using the mouse
> buttons or the widgets at the top of the terminal GUI.  
> 
> The documentation is quite explicit that this isn't true in general because
> such operations require the main program to recalculate and redraw the
> plot, which cannot happen in -persist mode because the main program
> has already exited.     As it happens, the wxt terminal back in version 4.4
> was an exception to this general case.  I guess people remember that 
> exception and want to generalize it to all current terminals.
> 
> That is, people expect this
> 
>     [1] gnuplot -persist -e "plot sinh(x); exit"
> 
> to act like this
> 
>     [2] gnuplot -e "plot sinh(x); pause mouse close; exit" &
> 
> The question is, should we continue pointing to the documented limitations
> of "persist", or should we change what persist does to match 
> people's
> expectation?  
> 
> So far as I know [2] works properly for the x11, wxt, and qt terminals
> under linux.  I don't know about MSWin (win) or OSX (aqua).
> 
> Assuming that [2] can be made to work correctly on all three of these
> platforms, should we reimplement "set term ... persist" and 
> "gnuplot -persist"
> to act like this instead of retaining the current implementation?
>


I have tested on windows (cvs changelog date is 2014-09-20)

gnuplot -e "plot sinh(x); pause mouse close; exit"


works as expected for wxt and windows terminal.
But for qt terminal, gnuplot exit immediately and we cannot use mouse.

For windows, there is not "fork" function so that persist mode works differently from other platforms.
In persist mode (case [1]), 
gnuplot session does not terminated so that we can use mouse for windows and wxt 
terminal. 

For qt terminal, perhaps gnuplot session is terminated but gnuplot_qt process exists.
We cannot use mouse for zoom for qt terminal.

Tatsuro

Persistent confusion about gnuplot -persist

[Ethan A M. <sf...@us...>]

There have recently been several queries, bug reports, support requests,
and so on that involve misunderstanding about what to expect from 
gnuplot -persist    or    set term <foo> persist.

People seem to assume that if the window is still showing on the screen,
they should be able to pan/zoom/unzoom and so on using the mouse
buttons or the widgets at the top of the terminal GUI.   

The documentation is quite explicit that this isn't true in general because
such operations require the main program to recalculate and redraw the
plot, which cannot happen in -persist mode because the main program
has already exited.     As it happens, the wxt terminal back in version 4.4
was an exception to this general case.  I guess people remember that 
exception and want to generalize it to all current terminals.

That is, people expect this

    [1] gnuplot -persist -e "plot sinh(x); exit"

to act like this

    [2] gnuplot -e "plot sinh(x); pause mouse close; exit" &

The question is, should we continue pointing to the documented limitations
of "persist", or should we change what persist does to match people's
expectation?   

So far as I know [2] works properly for the x11, wxt, and qt terminals
under linux.  I don't know about MSWin (win) or OSX (aqua).

Assuming that [2] can be made to work correctly on all three of these
platforms, should we reimplement "set term ... persist" and "gnuplot -persist"
to act like this instead of retaining the current implementation?

If so, is it worth holding up release of 5.0 until this change has been
implemented and tested?

	Ethan 

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

On Sun, 21 Sep 2014 10:39:55 -0700
sfeam <sf...@us...> wrote:

Thanks for the explanation!


> On Sunday, 21 September 2014 09:31:52 AM Philipp K. Janert wrote:
> > 
> > [snip]
> > 
> > > 
> > > > When using the "classic" method (set t ..., set o,
> > > > replot, etc), it's very specific regarding the size
> > > > and resolution of the bitmap or vector image that
> > > > is being saved. Is there any control over these
> > > > qualities when copying to clipboard?
> > > 
> > > In theory , set term wxt size 800,300  determines the terminal
> > > window size, hence what is copied, by any technique, from the
> > > screen output. Also FVWM can display the window size during drag
> > > to get an exact desired window size.
> > > 
> > 
> > Since this whole functionality is new to me, I am trying
> > to make sure I am really getting it. I it possible to 
> > generate genuine vector graphics this way (that is, going 
> > through the clipboard)?
> 
> It is technically possible.  For instance on Windows the clipboard
> holds blocks of WMF or EMF (or at least it used to, I have not used
> Windows for many years).  In principle an application can stuff
> arbitrary data into a clipboard, but in practice it's usually 
> either pure text or a bitmap image.  Current the wxt terminal
> stuffs a bitmap image to the clipboard.  Here is the code:
> 
>         wxTheClipboard->UsePrimarySelection(false);
>         /* SetData clears the clipboard */
>         if ( wxTheClipboard->Open() ) {
>                 wxTheClipboard->SetData(new
> wxBitmapDataObject(cp_bitmap)); wxTheClipboard->Close();
>         }
>         wxTheClipboard->Flush();
> 
> I think it would be straightforward to have the wxt terminal offer
> the same output widget options as the qt terminal:  png/pdf/svg output
> of the current plot contents triggered from the GUI.   There is a nice
> comparison of how to generate the various output modes here:
> 
> 		http://zetcode.com/gfx/cairo/cairobackends/
> 
> In this case you probably would want to export to a file rather than 
> to the clipboard, just because most applications on the receiving end
> probably won't know what to do with a block of svg (for instance) 
> pulled from the clipboard.  But Inkscape might. 
> 
> > I just tried to export a graph to PDF, by copying to 
> > clipboard and then pasting into inkscape - when blown
> > up, the results are definitely pixelated (which they
> > would not be with "genuine" PDF).
> 
> Inkscape is an SVG tool.  It can import bitmap images,
> but I don't think it knows how to convert PDF to SVG.
> In fact I don't know of any tool that does this.
>  
> > So, is it fair to say that the copy-to-clipboard tactic
> > gets me exactly the graph I see - as a pixmap -, but that
> > if I want vector graphics, the classic set t pdfcairo, etc
> > strategy is the way to go?
> 
> That's what I do in practice.  I find that the pdfcairo output
> is nearly identical to the wxt screen display content if you
> specify an appropriate size for the pdf canvas.  But as noted
> above this could probably be automated via a GUI widget.
> Patches welcome.
> 
> 	Ethan
> 
> 
> 
> 
> 

Re: File dialog in wxt does not work

[sfeam <sf...@us...>]

On Sunday, 21 September 2014 09:31:52 AM Philipp K. Janert wrote:
> 
> [snip]
> 
> > 
> > > When using the "classic" method (set t ..., set o,
> > > replot, etc), it's very specific regarding the size
> > > and resolution of the bitmap or vector image that
> > > is being saved. Is there any control over these
> > > qualities when copying to clipboard?
> > 
> > In theory , set term wxt size 800,300  determines the terminal window 
> > size, hence what is copied, by any technique, from the screen output. 
> > Also FVWM can display the window size during drag to get an exact 
> > desired window size.
> > 
> 
> Since this whole functionality is new to me, I am trying
> to make sure I am really getting it. I it possible to 
> generate genuine vector graphics this way (that is, going 
> through the clipboard)?

It is technically possible.  For instance on Windows the clipboard
holds blocks of WMF or EMF (or at least it used to, I have not used
Windows for many years).  In principle an application can stuff
arbitrary data into a clipboard, but in practice it's usually 
either pure text or a bitmap image.  Current the wxt terminal
stuffs a bitmap image to the clipboard.  Here is the code:

        wxTheClipboard->UsePrimarySelection(false);
        /* SetData clears the clipboard */
        if ( wxTheClipboard->Open() ) {
                wxTheClipboard->SetData(new wxBitmapDataObject(cp_bitmap));
                wxTheClipboard->Close();
        }
        wxTheClipboard->Flush();

I think it would be straightforward to have the wxt terminal offer
the same output widget options as the qt terminal:  png/pdf/svg output
of the current plot contents triggered from the GUI.   There is a nice
comparison of how to generate the various output modes here:

		http://zetcode.com/gfx/cairo/cairobackends/

In this case you probably would want to export to a file rather than 
to the clipboard, just because most applications on the receiving end
probably won't know what to do with a block of svg (for instance) 
pulled from the clipboard.  But Inkscape might. 

> I just tried to export a graph to PDF, by copying to 
> clipboard and then pasting into inkscape - when blown
> up, the results are definitely pixelated (which they
> would not be with "genuine" PDF).

Inkscape is an SVG tool.  It can import bitmap images,
but I don't think it knows how to convert PDF to SVG.
In fact I don't know of any tool that does this.
 
> So, is it fair to say that the copy-to-clipboard tactic
> gets me exactly the graph I see - as a pixmap -, but that
> if I want vector graphics, the classic set t pdfcairo, etc
> strategy is the way to go?

That's what I do in practice.  I find that the pdfcairo output
is nearly identical to the wxt screen display content if you
specify an appropriate size for the pdf canvas.  But as noted
above this could probably be automated via a GUI widget.
Patches welcome.

	Ethan

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

[snip]

> 
> > When using the "classic" method (set t ..., set o,
> > replot, etc), it's very specific regarding the size
> > and resolution of the bitmap or vector image that
> > is being saved. Is there any control over these
> > qualities when copying to clipboard?
> 
> In theory , set term wxt size 800,300  determines the terminal window 
> size, hence what is copied, by any technique, from the screen output. 
> Also FVWM can display the window size during drag to get an exact 
> desired window size.
> 

Since this whole functionality is new to me, I am trying
to make sure I am really getting it. I it possible to 
generate genuine vector graphics this way (that is, going 
through the clipboard)? Or are the results invariably pixelated?

I just tried to export a graph to PDF, by copying to 
clipboard and then pasting into inkscape - when blown
up, the results are definitely pixelated (which they
would not be with "genuine" PDF).

So, is it fair to say that the copy-to-clipboard tactic
gets me exactly the graph I see - as a pixmap -, but that
if I want vector graphics, the classic set t pdfcairo, etc
strategy is the way to go?

Re: File dialog in wxt does not work

[<pl...@pi...>]

On 09/20/14 18:36, Philipp K. Janert wrote:
> Naive question on the entire saving/clipboard
> issue: what actually is being saved? Is this
> in any way different than taking a screenshot?
> (Because, if it's not more than a screenshot,
> then gnuplot does not need to implement anything,
> really - there are plenty of screenshot utilities
> out there.)
>

As Ethan correctly points out, there are clipboard widgets in the 
mastodon window managers like KDE and Gnome. Like Philipp I use a 
lightweight WM that does not have loads of bells and whistles.

There is probably some small clipboard util. that I could use if I dug 
around. Firing up Gimp is a hammer/walnut solution.

The difference in what yor get is that with a screen-shot util. you get 
the window borders, icons, menus etc. unless you  try to manually select 
exactly the area you want, which is hard to get exactly right and is 
time consuming.



> When using the "classic" method (set t ..., set o,
> replot, etc), it's very specific regarding the size
> and resolution of the bitmap or vector image that
> is being saved. Is there any control over these
> qualities when copying to clipboard?

In theory , set term wxt size 800,300  determines the terminal window 
size, hence what is copied, by any technique, from the screen output. 
Also FVWM can display the window size during drag to get an exact 
desired window size.

However, while consistent, I find here that it does not give the 
requested size eg 800,300 gives me a window 700,255 !  x always loses 
100 px :?

I find the terminal size that gives me the required clipboard image to 
work around that problem. Maybe I should raise a bug about that.

Using set t png; set output "fn"; replot  produces significantly 
different results to what is on the screen which, as I detailed earlier, 
is why I no longer use the gnuplot ong etc  terminals to produce 
permanent output.

I ought to find a more efficient way of saving clipboard to file.

regards. Peter




>
> Best,
>
> 		Ph.

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

On Sat, 20 Sep 2014 09:24:30 -0700
sfeam <sf...@us...> wrote:

> On Saturday, 20 September 2014 07:51:54 AM pl...@pi... wrote:
> >
> > Firing up Gimp, just to do a paste and then use its file "export"
> > dialogue is a time waster.
> 
> That would indeed be a time waster.  But at least in KDE, hitting the
> "print screen" key brings up a widget where you can save to a file
> the entire screen, the content of one window, or an arbitrary
> rectangle. I believe Gnome provides an equivalent option via
> gnome-utils. I don't know what's available of that sort on the IceWM
> that Philip is using.
> 

Naive question on the entire saving/clipboard 
issue: what actually is being saved? Is this 
in any way different than taking a screenshot?
(Because, if it's not more than a screenshot,
then gnuplot does not need to implement anything,
really - there are plenty of screenshot utilities
out there.)

When using the "classic" method (set t ..., set o, 
replot, etc), it's very specific regarding the size
and resolution of the bitmap or vector image that 
is being saved. Is there any control over these
qualities when copying to clipboard?

Best,

		Ph.

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

On Sat, 20 Sep 2014 07:51:54 +0200
pl...@pi... wrote:

> On 09/20/14 02:28, Philipp K. Janert wrote:
> > Those were the two ideas that came to my mind, too.
> > Additionally, I think the icon could be much enhanced
> > with the addition of a big red arrow from the graph to
> > the clipboard. In fact, I'd interchange the current
> > positions of the graph and the clipboard in the icon,
> > so that the arrow would align with the typical (western)
> > workflow "left to right".
> 
> Oh, for pity's sake no more dumb-assed,  " you have just pressed X", 
> "are you sure" windozian messages.
> 
> I do not want half my work flow to be dismissing stupid messages
> telling what I've just done.

I can agree with that.

> 
> This is all part of the universal obscurity-by-icons problem. Thirty 
> year ago it would have been the word "copy" , now everything has to
> be an icon. In the pressure to save space the icons have to be small
> and therefore have limited means of communicating anything. They are
> just enough to be reminders once you know what the interface does.

I can agree with that, too - but what are
you gonna do about it?

> 
> That's what tool-tips are for. That is a fairly standard, cross
> platform technique.If you don't know what something does , hover.

The problem was that I didn't know I didn't know.
I was certain (though wrong) that I knew what it
did. And I have had enough trouble with gnuplot
terminals that, when I got no visible response, 
I assumed that there was a malfunction/bug, rather 
than a misuse on my part.

> 
> The "top left" convention is for MENUS, this is an icon tool bar.
> There is no convention that says the first entry on a tool bar should
> bring up a file_open dialogue.
> 
> Sorry, Philipp, you just fooled yourself by making unfounded
> assumptions that wxt would do the same thing and the qt terminal
> instead of trying to discover what the (new to you ) interface did.

I disagree. "Top left" is a sufficiently widely followed 
convention, even for icon bars, that I cannot accept the
"unfounded assumption" statement.

> 
> I've been using wxt pretty much all along with gnuplot and did not
> find this feature at first, until the day I decided to find out what
> all the buttons did. The tool-tips soon made it clear.
>
> This is a very useful feature and it is very useful in that it gives
> you exactly what you are looking at. I use this almost exclusively
> for creating permanent copy of my graphs since the png terminal
> produce something so different from what is on the screen.: different
> fonts, different line widths, different colours....  Usually by the
> time I get to want output, I've got the graph looking the way I need
> it. I do not want something else stored or in hardcopy.

Question for you: what do you choose to paste the copy into?
Gimp? Or something else? Any experience to share?

> 
> Now if qt allows saving the _screen image_ of the graph in png or 
> similar format, this would be a good addition to wxt. Firing up Gimp, 
> just to do a paste and then use its file "export" dialogue is a time 
> waster.
> 
> Adding a 'save to file' icon that takes the same image that goes to 
> clipboard would be good enhancement, should anyone feel inclined.

Thanks.

> 
> Peter.
> 
> 
> >
> > Another idea is to change the functionality - I am not so
> > familiar with the capabilities of wxt, but would it be
> > possible to save the graph to PDF/PNG immediately, rather
> > than (merely) to the clipboard? This would naturally lead
> > to a file-selection dialog, as in the qt terminal.
> >
> > I should add that I really like this feature in principle,
> > because the workflow of saving (actually: exporting) graphs
> > from gnuplot has always been a bit awkward (5 steps: set t,
> > set o, replot, set o, set t). So, being able to do it all
> > in one mouse-click is a huge improvement (in my opinion),
> > and also brings gnuplot's behavior closer to what current
> > users have come to expect from applications.
> >
> >> >
> >> >Actually, I'll agree with Philipp: nothing about the GUI options
> >> >in the wxt plot window is immediately clear. For example, what is
> >> >the cross-hair cursor supposed to do, as you move it around?
> >> >
> >> >Allin Cottrell
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: File dialog in wxt does not work

[sfeam <sf...@us...>]

On Saturday, 20 September 2014 07:51:54 AM pl...@pi... wrote:
>
> Firing up Gimp, just to do a paste and then use its file "export"
> dialogue is a time waster.

That would indeed be a time waster.  But at least in KDE, hitting the
"print screen" key brings up a widget where you can save to a file
the entire screen, the content of one window, or an arbitrary rectangle.
I believe Gnome provides an equivalent option via gnome-utils.
I don't know what's available of that sort on the IceWM that Philip
is using.

	Ethan

Re: File dialog in wxt does not work

[<pl...@pi...>]

On 09/20/14 02:28, Philipp K. Janert wrote:
> Those were the two ideas that came to my mind, too.
> Additionally, I think the icon could be much enhanced
> with the addition of a big red arrow from the graph to
> the clipboard. In fact, I'd interchange the current
> positions of the graph and the clipboard in the icon,
> so that the arrow would align with the typical (western)
> workflow "left to right".

Oh, for pity's sake no more dumb-assed,  " you have just pressed X", 
"are you sure" windozian messages.

I do not want half my work flow to be dismissing stupid messages telling 
what I've just done.

This is all part of the universal obscurity-by-icons problem. Thirty 
year ago it would have been the word "copy" , now everything has to be 
an icon. In the pressure to save space the icons have to be small and 
therefore have limited means of communicating anything. They are just 
enough to be reminders once you know what the interface does.

That's what tool-tips are for. That is a fairly standard, cross platform 
technique.If you don't know what something does , hover.

The "top left" convention is for MENUS, this is an icon tool bar. There 
is no convention that says the first entry on a tool bar should bring up 
a file_open dialogue.

Sorry, Philipp, you just fooled yourself by making unfounded assumptions 
that wxt would do the same thing and the qt terminal instead of trying 
to discover what the (new to you ) interface did.

I've been using wxt pretty much all along with gnuplot and did not find 
this feature at first, until the day I decided to find out what all the 
buttons did. The tool-tips soon made it clear.

This is a very useful feature and it is very useful in that it gives you 
exactly what you are looking at. I use this almost exclusively for 
creating permanent copy of my graphs since the png terminal produce 
something so different from what is on the screen.: different fonts, 
different line widths, different colours....  Usually by the time I get 
to want output, I've got the graph looking the way I need it. I do not 
want something else stored or in hardcopy.

Now if qt allows saving the _screen image_ of the graph in png or 
similar format, this would be a good addition to wxt. Firing up Gimp, 
just to do a paste and then use its file "export" dialogue is a time 
waster.

Adding a 'save to file' icon that takes the same image that goes to 
clipboard would be good enhancement, should anyone feel inclined.

Peter.


>
> Another idea is to change the functionality - I am not so
> familiar with the capabilities of wxt, but would it be
> possible to save the graph to PDF/PNG immediately, rather
> than (merely) to the clipboard? This would naturally lead
> to a file-selection dialog, as in the qt terminal.
>
> I should add that I really like this feature in principle,
> because the workflow of saving (actually: exporting) graphs
> from gnuplot has always been a bit awkward (5 steps: set t,
> set o, replot, set o, set t). So, being able to do it all
> in one mouse-click is a huge improvement (in my opinion),
> and also brings gnuplot's behavior closer to what current
> users have come to expect from applications.
>
>> >
>> >Actually, I'll agree with Philipp: nothing about the GUI options in
>> >the wxt plot window is immediately clear. For example, what is the
>> >cross-hair cursor supposed to do, as you move it around?
>> >
>> >Allin Cottrell

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

On Fri, 19 Sep 2014 19:55:45 -0400 (EDT)
Allin Cottrell <cot...@wf...> wrote:

> On Fri, 19 Sep 2014, Philipp K. Janert wrote:
> 
> > [snip]
> >
> >>> The functionality is nice, but the user-interface
> >>> might be rather confusing for people. (I doubt I
> >>> am the only one who expected a file dialog.)
> >>
> >> The icon at the top left is supposed to represent "copy" and a
> >> clipboard, and its tooltip says "Copy the plot to clipboard". I'm
> >> not sure why one would expect a "file dialog".
> >
> > Answer: because that's what is in the top-left corner
> > of menus, almost universally. (Eg, among many others,
> > gnuplot's own wxt terminal.)
> >
> > The icon is too small and to unspecific to send a
> > strong message, either way. And I admit that I did
> > not wait for the tooltip.
> 
> Granted, top-left corner is usually File/<something or other> and 
> the icon is not immediately recognizable. But I'm not sure what the 
> "solution" is: maybe move the icon off the top-left corner, and/or 
> add feedback in the form of a "Plot copied to clipboard" message 
> box?

Those were the two ideas that came to my mind, too.
Additionally, I think the icon could be much enhanced
with the addition of a big red arrow from the graph to
the clipboard. In fact, I'd interchange the current 
positions of the graph and the clipboard in the icon,
so that the arrow would align with the typical (western)
workflow "left to right". 

Another idea is to change the functionality - I am not so 
familiar with the capabilities of wxt, but would it be
possible to save the graph to PDF/PNG immediately, rather
than (merely) to the clipboard? This would naturally lead
to a file-selection dialog, as in the qt terminal.

I should add that I really like this feature in principle,
because the workflow of saving (actually: exporting) graphs 
from gnuplot has always been a bit awkward (5 steps: set t, 
set o, replot, set o, set t). So, being able to do it all
in one mouse-click is a huge improvement (in my opinion),
and also brings gnuplot's behavior closer to what current
users have come to expect from applications.

> 
> Actually, I'll agree with Philipp: nothing about the GUI options in 
> the wxt plot window is immediately clear. For example, what is the 
> cross-hair cursor supposed to do, as you move it around?
> 
> Allin Cottrell

Re: File dialog in wxt does not work

[Allin C. <cot...@wf...>]

On Fri, 19 Sep 2014, Philipp K. Janert wrote:

> [snip]
>
>>> The functionality is nice, but the user-interface
>>> might be rather confusing for people. (I doubt I
>>> am the only one who expected a file dialog.)
>>
>> The icon at the top left is supposed to represent "copy" and a
>> clipboard, and its tooltip says "Copy the plot to clipboard". I'm
>> not sure why one would expect a "file dialog".
>
> Answer: because that's what is in the top-left corner
> of menus, almost universally. (Eg, among many others,
> gnuplot's own wxt terminal.)
>
> The icon is too small and to unspecific to send a
> strong message, either way. And I admit that I did
> not wait for the tooltip.

Granted, top-left corner is usually File/<something or other> and 
the icon is not immediately recognizable. But I'm not sure what the 
"solution" is: maybe move the icon off the top-left corner, and/or 
add feedback in the form of a "Plot copied to clipboard" message 
box?

Actually, I'll agree with Philipp: nothing about the GUI options in 
the wxt plot window is immediately clear. For example, what is the 
cross-hair cursor supposed to do, as you move it around?

Allin Cottrell