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

Re: towards 4.4

[Petr M. <mi...@ph...>]

> I have found a serious side effect of this patch. Gui dialog 'gnuplot 
> pause' does not appear on wgnuplot when terminal is wxt.

I thought that term->waitforinput() works in wxt in the same way as on 
non-Windows.

But in wxt_gui.cpp there is a special code for WGP_CONSOLE and not for 
WIN_IPC in wxt_waitforinput().

Should there be 
  if (0) {
instead of
  if (!strcmp(term->name, "wxt")) {
in command.c? Please try it.

It's the same as removing the whole block
# ifdef WXWIDGETS
...
# endif /* _Windows && WXWIDGETS */


---
PM

Re: towards 4.4

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

Hello

I have posted my reply before seeing the post by Petr.

--- Petr Mikulik  wrote:

> > That "after return the graph window is active" problem is there all the 
> > time when running the windows terminal under linux/wine.  I have assumed 
> > that people using MSWin want it that way, although I myself find it 
> > incredibly annoying. My preference would be to never allow the program to 
> > steal focus from the command window
> 
> I have no idea what do you mean. Just "plot x" and which window is focused 
> afterwards? It works the same way as on X11. Also "pause -1" goes back to 
> command window after you hit Enter or click "OK" button.
> 
> Otherwisse, hitting "Space" makes the command window active.

Indeed! I have forgotten about that functionality. 
 
> > and get rid of the pop-up "pause" widget altogether.
> 
> OS/2 PM has three possibilities: Pause dialog, Pause item on the menu bar of 
> the graph windows; Hit Enter in the command window. It's user configurable. 
> I prefer the menu bar item as it is not necessary to leave the graph window 
> just to hit Enter elsewhere to continue something.dem.

My opinion was written in the previous post.
Anyway the problem wgnuplot+wxt+pause mouse does not work now.

I have consider a modification on the weekend.  

I have one point to ask about the wxt terminal. Is there any way to detect whether the wxt graph
window is active or not.  I have remembered that my personal trial to treat wgnuplot+wxt+pause mouse
issue was failed in this point.

Regards

Tatsuro

 

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

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

Hello


--- Ethan Merritt wrote:
> 
> That "after return the graph window is active" problem is there all the time
> when running the windows terminal under linux/wine.  I have assumed that 
> people using MSWin want it that way, although I myself find it incredibly annoying.
> My preference would be to never allow the program to steal focus from the
> command window, and get rid of the pop-up "pause" widget altogether.
> But I'm not using MSWin anyway. So if these behaviours are considered normal
> by people who do use MSWin, go ahead and ignore me.
> 
> 	Ethan

> That "after return the graph window is active" problem is there all the time
> when running the windows terminal under linux/wine.

The similar thing was happened in wxt terminal gnuplot.exe on windows.:-(

However, wgnuplot.exe is a gui based windows program so that popup of a gui dialog of 'gnuplot pause'
for pause -1 is better to unified for both windows and wxt terminal.

When a user who has been used wgnuplot.exe with the windows terminal might be surprised if 'pause -1'
does not produce the 'gnuplot pause' dialog when he tries to use wxt terminal on wgnuplot.exe,
I think.

Regards

Tatsuro


  

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Petr M. <mi...@ph...>]

> I found that Petr applied his patch for 'pause mouse' to cvs trees.  I have build them and tried
> all.dem
> 
> I have found a serious side effect of this patch. Gui dialog 'gnuplot pause' does not appear on
> wgnuplot when terminal is wxt.


>> We can break pause press return on the command window of wgnuplot.exe but 
>> after return the graph window is active, we have to turn back to the 
>> command window. This is really annoying to carry out all.dem.
>
> That "after return the graph window is active" problem is there all the 
> time when running the windows terminal under linux/wine.  I have assumed 
> that people using MSWin want it that way, although I myself find it 
> incredibly annoying. My preference would be to never allow the program to 
> steal focus from the command window

I have no idea what do you mean. Just "plot x" and which window is focused 
afterwards? It works the same way as on X11. Also "pause -1" goes back to 
command window after you hit Enter or click "OK" button.

Otherwisse, hitting "Space" makes the command window active.

> and get rid of the pop-up "pause" widget altogether.

OS/2 PM has three possibilities: Pause dialog, Pause item on the menu bar of 
the graph windows; Hit Enter in the command window. It's user configurable. 
I prefer the menu bar item as it is not necessary to leave the graph window 
just to hit Enter elsewhere to continue something.dem.

---
PM

Re: towards 4.4

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 January 2010, Tatsuro MATSUOKA wrote:
> Hello
> 
> --- Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > --- Petr Mikulik wrote:
> > 
> > > > The patch gives s gui 'gnuplot pause' window when the command 'pause -1' 
> > > > is executed when terminal is set to 'windows'. When WGP_CONSOLE is true. 
> > > > the code should be modified. I have encountered this problem and I have 
> > > > considered to treat the side effect. I will show it afterwards.
> > > 
> > > "pause -1" shows a GUI Pause dialog. You would prefer to have just 
> > > fgets(stdin) for gnuplot.exe. I've tried it, but then mouse hotkeys are not 
> > > working during pause. So I prefer the current GUI dialog.
> > 
> > What do you mean mouse hotkeys?
> > 
> > Is 'the hotkey 'h' in the graph window' a example of mouse hotkey.
> > 
> > The gnuplot.exe on windows on current state (without your patch) allows hotkeys ,'h','p',
> > 'l'...... on
> > graph window when gnuplot is in pause -1 and pause mouse mode.  
> > In pause -1 mode, we can use mouse zooming on the current gnuplot.exe on windows.
> > 
> > Is the above a problem?
> > 
> > However only return key breaks 'pause -1' for wgnuplot and gnuplot-x11(I have confirmed on
> > cygwin) but
> > any key breaks pause -1.
> > 
> > That is a problem, I think.
> > 
> > You patch at least changes of the feature of pause -1 on gnuplot.exe on windows from current
> > state. 
> > If people hope this change, I am not against it.
> 
> Although I wrote the above, the gui dialog on gnuplot.exe for windows is not my favor. 
> Perhaps it is better hear the opinions from other people.
> 
> 
> BTW
> 
> I found that Petr applied his patch for 'pause mouse' to cvs trees.  I have build them and tried
> all.dem
> 
> I have found a serious side effect of this patch. Gui dialog 'gnuplot pause' does not appear on
> wgnuplot when terminal is wxt.
> 
> We can break pause press return on the command window of wgnuplot.exe but after return the graph
> window is active, we have to turn back to the command window. This is really annoying to carry out
> all.dem. 

That "after return the graph window is active" problem is there all the time
when running the windows terminal under linux/wine.  I have assumed that 
people using MSWin want it that way, although I myself find it incredibly annoying.
My preference would be to never allow the program to steal focus from the
command window, and get rid of the pop-up "pause" widget altogether.
But I'm not using MSWin anyway. So if these behaviours are considered normal
by people who do use MSWin, go ahead and ignore me.

	Ethan

> The should be corrected, I think.
> 
> Regards
> 
> Tatsuro

Re: towards 4.4

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

Hello


I have found web page in written Japanese.

It was written that SIGINT is not easy to handle in console applications.
However, there shows a way to use SetConsoleCtrlHandler function.

#***************
#include <windows.h>
#include <wincon.h>
#include <iostream>

//handler function
BOOL handler(DWORD ctrlChar){
  if(CTRL_C_EVENT == ctrlChar){
    std::cout<< "Ctrl+C pressed"<< std::endl;
    return FALSE;
  }

int main(void){
  ::SetConsoleCtrlHandler(handler, TRUE);

  while(true)
    ::Sleep(100);

  return 0;
}

#*********
prototype of handler
BOOL WINAPI HandlerRoutine(DWORD dwCtrlType);

#***************

dwCtrlType

CTRL_C_EVENT       Receives Cntl+C 
CTRL_BREAK_EVENT   Receives Cntl+BREAK 
CTRL_CLOSE_EVENT   Console is closed by a user
CTRL_LOGOFF_EVENT  Receives a signal which is sent from the system
                    to all console processes because user tries to log off
CTRL_SHUTDOWN_EVENT Receives a signal which is sent from the system
                    to all console processes because user tries to shut down

#**************

MSDN page in English

http://msdn.microsoft.com/en-us/library/ms686016(VS.85).aspx


Are the above helpful?

Regards

Tatsuro

--- Ethan Merritt <merritt@u.washington.edu> wrote:

> On Thursday 28 January 2010 15:33:48 Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for
> windows.
> > 
> > http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183
> > 
> > ****************
> > --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c	2009-09-20 20:16:47 +0200
> > +++ gnuplot-4.3.0-2009-07-08/src/plot.c	2009-10-18 13:06:08 +0200
> > @@ -684,7 +684,11 @@
> >      setmatherr(purec_matherr);
> >  #endif
> >  
> > +#if defined(WGP_CONSOLE)
> > +    (void) signal(SIGINT, SIG_IGN);
> > +#else
> >      (void) signal(SIGINT, (sigfunc) inter);
> > +#endif
> >  
> >  #ifdef SIGPIPE
> >      /* ignore pipe errors, this might happen with set output "|head" */
> > ******************
> > 
> > The above seems not to be applied yet.
> 
> That would cause the program to ignore ctrl-c.
> It would be better to fix the signal-handling routine so that it
> responds to ctrl-c correctly.
> 
> Does someone know the history of this problem?
> Did ctrl-c work on Windows in older versions of gnuplot?
> If so, when did it break?
> 
> -- 
> Ethan A Merritt
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

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

Hello

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> --- Petr Mikulik wrote:
> 
> > > The patch gives s gui 'gnuplot pause' window when the command 'pause -1' 
> > > is executed when terminal is set to 'windows'. When WGP_CONSOLE is true. 
> > > the code should be modified. I have encountered this problem and I have 
> > > considered to treat the side effect. I will show it afterwards.
> > 
> > "pause -1" shows a GUI Pause dialog. You would prefer to have just 
> > fgets(stdin) for gnuplot.exe. I've tried it, but then mouse hotkeys are not 
> > working during pause. So I prefer the current GUI dialog.
> 
> What do you mean mouse hotkeys?
> 
> Is 'the hotkey 'h' in the graph window' a example of mouse hotkey.
> 
> The gnuplot.exe on windows on current state (without your patch) allows hotkeys ,'h','p',
> 'l'...... on
> graph window when gnuplot is in pause -1 and pause mouse mode.  
> In pause -1 mode, we can use mouse zooming on the current gnuplot.exe on windows.
> 
> Is the above a problem?
> 
> However only return key breaks 'pause -1' for wgnuplot and gnuplot-x11(I have confirmed on
> cygwin) but
> any key breaks pause -1.
> 
> That is a problem, I think.
> 
> You patch at least changes of the feature of pause -1 on gnuplot.exe on windows from current
> state. 
> If people hope this change, I am not against it.

Although I wrote the above, the gui dialog on gnuplot.exe for windows is not my favor. 
Perhaps it is better hear the opinions from other people.


BTW

I found that Petr applied his patch for 'pause mouse' to cvs trees.  I have build them and tried
all.dem

I have found a serious side effect of this patch. Gui dialog 'gnuplot pause' does not appear on
wgnuplot when terminal is wxt.

We can break pause press return on the command window of wgnuplot.exe but after return the graph
window is active, we have to turn back to the command window. This is really annoying to carry out
all.dem. 

The should be corrected, I think.

Regards

Tatsuro


 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 January 2010 15:33:48 Tatsuro MATSUOKA wrote:
> Hello
> 
> I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for windows.
> 
> http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183
> 
> ****************
> --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c	2009-09-20 20:16:47 +0200
> +++ gnuplot-4.3.0-2009-07-08/src/plot.c	2009-10-18 13:06:08 +0200
> @@ -684,7 +684,11 @@
>      setmatherr(purec_matherr);
>  #endif
>  
> +#if defined(WGP_CONSOLE)
> +    (void) signal(SIGINT, SIG_IGN);
> +#else
>      (void) signal(SIGINT, (sigfunc) inter);
> +#endif
>  
>  #ifdef SIGPIPE
>      /* ignore pipe errors, this might happen with set output "|head" */
> ******************
> 
> The above seems not to be applied yet.

That would cause the program to ignore ctrl-c.
It would be better to fix the signal-handling routine so that it
responds to ctrl-c correctly.

Does someone know the history of this problem?
Did ctrl-c work on Windows in older versions of gnuplot?
If so, when did it break?

-- 
Ethan A Merritt

Re: towards 4.4

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

Hello

I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for windows.

http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183

****************
--- gnuplot-4.3.0-2009-07-08-orig/src/plot.c	2009-09-20 20:16:47 +0200
+++ gnuplot-4.3.0-2009-07-08/src/plot.c	2009-10-18 13:06:08 +0200
@@ -684,7 +684,11 @@
     setmatherr(purec_matherr);
 #endif
 
+#if defined(WGP_CONSOLE)
+    (void) signal(SIGINT, SIG_IGN);
+#else
     (void) signal(SIGINT, (sigfunc) inter);
+#endif
 
 #ifdef SIGPIPE
     /* ignore pipe errors, this might happen with set output "|head" */
******************

The above seems not to be applied yet.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Petr M. <mi...@ph...>]

> > "pause -1" shows a GUI Pause dialog. You would prefer to have just 
> > fgets(stdin) for gnuplot.exe. I've tried it, but then mouse hotkeys are not 
> > working during pause. So I prefer the current GUI dialog.
> 
> What do you mean mouse hotkeys?
> Is 'the hotkey 'h' in the graph window' a example of mouse hotkey.

Yes, mouse zooming and hotkeys should work during "pause -1".

> You patch at leasdt changes of the feature of pause -1 on gnuplot.exe on 
> windows from current state.

I've committed the change to both 4.4 and cvs.
There was one more typo there, please test it.

> > I.e. wgnuplot.exe + wx terminal + "pause mouse" still waits for Enter. 
> I have another idea to treat it. I have a winter term examination in my lecture tomorrow.
> Please wait a while to try the idea. 

The above combination seems to be the last one waiting for a fix.

---
PM

Re: towards 4.4

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

Hello

--- Petr Mikulik wrote:

> > The patch gives s gui 'gnuplot pause' window when the command 'pause -1' 
> > is executed when terminal is set to 'windows'. When WGP_CONSOLE is true. 
> > the code should be modified. I have encountered this problem and I have 
> > considered to treat the side effect. I will show it afterwards.
> 
> "pause -1" shows a GUI Pause dialog. You would prefer to have just 
> fgets(stdin) for gnuplot.exe. I've tried it, but then mouse hotkeys are not 
> working during pause. So I prefer the current GUI dialog.

What do you mean mouse hotkeys?

Is 'the hotkey 'h' in the graph window' a example of mouse hotkey.

The gnuplot.exe on windows on current state (without your patch) allows hotkeys ,'h','p', 'l'...... on
graph window when gnuplot is in pause -1 and pause mouse mode.  
In pause -1 mode, we can use mouse zooming on the current gnuplot.exe on windows.

Is the above a problem?

However only return key breaks 'pause -1' for wgnuplot and gnuplot-x11(I have confirmed on cygwin) but
any key breaks pause -1.

That is a problem, I think.

You patch at leasdt changes of the feature of pause -1 on gnuplot.exe on windows from current state. 
If people hope this change, I am not against it.

I have another idea to treat it. I have a winter term examination in my lecture tomorrow.
Please wait a while to try the idea. 

> 
> > # ***** results for wgnuplot{_pipes}.exe *****
> > 
> > The patch does not correct the 'pause mouse' issue of wxt term.
> > Clicking mouse button does not break 'pause mouse' while pressing a key breaks it. 
> > Of course, the pause mouse for windows terminals works correct.
> 
> I.e. wgnuplot.exe + wx terminal + "pause mouse" still waits for Enter. 

Exactly.

> windows terminal is not using the waitforinput but WIN_IPC. In "pause 
> mouse", it stops pausing when the event arrives to gnuplot. Could a similar 
> reaction be applied to pausing from wxt?

I have tried perhaps the way you mensioned the above. When graph windows was active, it went well. 
However pause mouse without graph window make a trouble. The trail was done in the computer at home. 
I cannot remember how the trouble is and cannot reproduce now.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Petr M. <mi...@ph...>]

> The patch gives s gui 'gnuplot pause' window when the command 'pause -1' 
> is executed when terminal is set to 'windows'. When WGP_CONSOLE is true. 
> the code should be modified. I have encountered this problem and I have 
> considered to treat the side effect. I will show it afterwards.

"pause -1" shows a GUI Pause dialog. You would prefer to have just 
fgets(stdin) for gnuplot.exe. I've tried it, but then mouse hotkeys are not 
working during pause. So I prefer the current GUI dialog.


> # ***** results for wgnuplot{_pipes}.exe *****
> 
> The patch does not correct the 'pause mouse' issue of wxt term.
> Clicking mouse button does not break 'pause mouse' while pressing a key breaks it. 
> Of course, the pause mouse for windows terminals works correct.

I.e. wgnuplot.exe + wx terminal + "pause mouse" still waits for Enter. 

> There is no gnuplot executable for all other platformes which has a 
> original GUI based console except for wgnuplot.  I suspect that 
> wxt_waitforinput() does not work correct on wgnuplot.exe. However it is no 
> more than speculation at present.

windows terminal is not using the waitforinput but WIN_IPC. In "pause 
mouse", it stops pausing when the event arrives to gnuplot. Could a similar 
reaction be applied to pausing from wxt?

---
PM

Re: towards 4.4

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

Hello

--- Petr Mikulik wrote:

> If WX is the current terminal under windows, then the pausing code with 
> waitforinput() has to be used instead. Will the (untested) enclosed patch 
> work?
> 
Hello

I have applied your patch to cvs trees.

In the patch, a small fix is needed
+	if (!strcmp(term->title, "wx")) {
should be 
+	if (!strcmp(term->name, "wxt")) {

# ***** results for gnuplot.exe *****
The patch for pause mouse for windows and wxt terminals works well except a side effect.
 
The patch gives s gui 'gnuplot pause' window when the command 'pause -1' is executed when terminal is
set to 'windows'.
When WGP_CONSOLE is true. the code should be modified.
I have encountered this problem and I have considered to treat the side effect.
I will show it afterwards.

# ***** results for wgnuplot{_pipes}.exe *****

The patch does not correct the 'pause mouse' issue of wxt term.
Clicking mouse button does not break 'pause mouse' while pressing a key breaks it. 
Of course, the pause mouse for windows terminals works correct.

I have tried the similar treatment but that also did not work.

There is no gnuplot executable for all other platformes which has a original GUI based console except
for wgnuplot.  I suspect that wxt_waitforinput() does not work correct on wgnuplot.exe.
However it is no more than speculation at present.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

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

Hello

--- Petr Mikulik wrote:

> If WX is the current terminal under windows, then the pausing code with 
> waitforinput() has to be used instead. Will the (untested) enclosed patch 
> work?
> 
Hello

I have applied your patch to cvs trees.

In the patch, a small fix is needed
+	if (!strcmp(term->title, "wx")) {
should be 
+	if (!strcmp(term->name, "wxt")) {

# ***** results for gnuplot.exe *****
The patch for pause mouse for windows and wxt terminals works well except a side effect.
 
The patch gives s gui 'gnuplot pause' window when the command 'pause -1' is executed when terminal is
set to 'windows'.
When WGP_CONSOLE is true. the code should be modified.
I have encountered this problem and I have considered to treat the side effect.
I will show it afterwards.

# ***** results for wgnuplot{_pipes}.exe *****

The patch does not correct the 'pause mouse' issue of wxt term.
Clicking mouse button does not break 'pause mouse' while pressing a key breaks it. 
Of course, the pause mouse for windows terminals works correct.

I have tried the similar treatment but that also did not work.

There is no gnuplot executable for all other platformes which has a original GUI based console except
for wgnuplot.  I suspect that wxt_waitforinput() does not work correct on wgnuplot.exe.
However it is no more than speculation at present.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

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

Hello Bastian Maerkisch

--- Bastian Maerkisch wrote:

> Hello
> 
> I understand that you use cygwin to compile gnuplot on windows. It would 
> be great if you could include readline (or editline) in your build for 
> "gnuplot.exe". This is now standard on Linux and is one of the things I 
> am sorely missing on windows.
> 
> Regards
> 	Bastian


I do not use cygwin to build gnuplot binaries native to windows.  I am using msys + mingw + mingw gcc
to build them.  I use cygwin when I build cygwin version of gnuplot.

For building of gnuplot on the above platform, ./configure-make procedure is not used but it uses
customized makefile (makefile.mgw) and config.h (config.mgw is override to config.h in make process.).

In makefile.mgw, there is no description of the readline feature.  I have a windows version
libreadline libraries provides by GnuWin32 project. I will try it Perhaps I have to add
-DHAVE_LIBREADLINE to complier flag, add include and library path and add -lreadline in linker flag.
Of cource, I will try it only for gnuplot.exe and do not want to do for wgnuplot[_pipes].exe. 

I do not know whether it will be successful or not.  Please wait keeping your expectations low.
If you or someone gives me suggestions for the matter, it will be welcome.

Regards

Tatsuro


Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Petr M. <mi...@ph...>]

> In my idea, pause mouse issues lies on the following the code in command.c
> 
> #if defined(_Windows) && !defined(WGP_CONSOLE)
>     if (paused_for_mouse && !graphwin.hWndGraph) {
> 	if (interactive) { /* cannot wait for Enter in a non-interactive session without the graph window */
> 	    char tmp[512];
> 	    if (buf) fprintf(stderr,"%s\n", buf);
> 	    fgets(tmp, 512, stdin); /* graphical window not yet initialized, wait for any key here */
> 	}
>     } else { /* pausing via graphical windows */
> 	int tmp = paused_for_mouse;
> 	if (buf && paused_for_mouse) fprintf(stderr,"%s\n", buf);
> 	if (!Pause(buf)) {
> 	    if (!tmp) {
> 		bail_to_command_line();
> 	    } else {
> 		if (!graphwin.hWndGraph) 
> 		    bail_to_command_line();
> 	    }
> 	}
>     }

The code above is a correct code for the Windows terminal, therefore there 
must be
     #if defined(_Windows)
and not
     #if defined(_Windows) && !defined(WGP_CONSOLE)
Then all "pause mouse" commands work correctly in gnuplot.exe as well as in
wgnuplot.exe.

The test
	!graphwin.hWndGraph
is there because of "pause mouse" issued before any "{s}plot" command.


If WX is the current terminal under windows, then the pausing code with 
waitforinput() has to be used instead. Will the (untested) enclosed patch 
work?

---
PM

Re: towards 4.4

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

> You claim there (message by Tatsuro MATSUOKA-2 Dec 11, 2009; 09:40am) that 
> the reason is that "pause mouse" does not work on gnuplot.exe + Windows 
> terminal. It seems I missed this test yesterday. Isn't this related to 
> another bug, that gnuplot.exe running under Wine freezes after the first 
> entered command?
> 
> 
> I've tried it:
> 
> With "set term windows":
> - pause mouse key; show var
>   pause mouse; show var
>   pause mouse any; show var
>   ... in wgnuplot{_pipes}.exe: work correctly
>   ... in gnuplot.exe: MOUSE_ variables are filled correctly, but <enter> has 
>       to be pressed in the command window to return back to the command 
>       prompt
> - pause mouse button{1-3}; show var
>   ... Wrong: it terminates on any mouse button
> 
> With "set term wxt":
> - all "pause mouse" commands work correctly in gnuplot.exe
> - all "pause mouse" commands have a problem in wgnuplot{_pipes}.exe:
>   MOUSE_ variables are filled correctly, but <enter> has to be pressed
>   in the command window to return back to the command prompt
> 
> It seems the "hit <enter>" bug is in windows+gnuplot.exe and in 
> wxt+wgnuplot.exe combination.
> 
> 
> Is WIN_IPC used correctly in both cases? Isn't somewhere missing an #ifdef?

In my idea, pause mouse issues lies on the following the code in command.c


#if defined(_Windows) && !defined(WGP_CONSOLE)
    if (paused_for_mouse && !graphwin.hWndGraph) {
	if (interactive) { /* cannot wait for Enter in a non-interactive session without the graph window */
	    char tmp[512];
	    if (buf) fprintf(stderr,"%s\n", buf);
	    fgets(tmp, 512, stdin); /* graphical window not yet initialized, wait for any key here */
	}
    } else { /* pausing via graphical windows */
	int tmp = paused_for_mouse;
	if (buf && paused_for_mouse) fprintf(stderr,"%s\n", buf);
	if (!Pause(buf)) {
	    if (!tmp) {
		bail_to_command_line();
	    } else {
		if (!graphwin.hWndGraph) 
		    bail_to_command_line();
	    }
	}
    }

#if defined(_Windows) && !defined(WGP_CONSOLE)

This gives different behaviors of pause mouse between gnuplot.exe and wgnuplot{_pipes}.exe.

For gnuplot.exe, term->waitforinput is called but for wgnuplot{_pipes}.exe, the above code is used for
wgnuplot.exe.  It is clear that the code for wgnuplot{_pipes}.exe does not consider wxt terminal
because we cannot get wxt window information cannot be obtained by 'graphwin.hWndGraph'.

I , at the moment, have any good idea to treat them.

For term->waitforinput, I have compared 
x11_X11_waitforinput() in term/x11.trm and wxt_waitforinput() in src/wxterminal/wxt_gui.cpp are very
different each other.  I think that treatment of x11 is better because it gives message of 'Mousing
not active' if x11 graph window is not active.

I think that it is better to unify the behavior for interactive terminals as possible.

Regards

Tatsuro
  


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Petr M. <mi...@ph...>]

> --- Petr Mikulik  wrote:
> 
> > BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows 
> > correctly?
> No not yet. See:
> http://old.nabble.com/Problem-with-ginput-td26706688.html

You claim there (message by Tatsuro MATSUOKA-2 Dec 11, 2009; 09:40am) that 
the reason is that "pause mouse" does not work on gnuplot.exe + Windows 
terminal. It seems I missed this test yesterday. Isn't this related to 
another bug, that gnuplot.exe running under Wine freezes after the first 
entered command?


I've tried it:

With "set term windows":
- pause mouse key; show var
  pause mouse; show var
  pause mouse any; show var
  ... in wgnuplot{_pipes}.exe: work correctly
  ... in gnuplot.exe: MOUSE_ variables are filled correctly, but <enter> has 
      to be pressed in the command window to return back to the command 
      prompt
- pause mouse button{1-3}; show var
  ... Wrong: it terminates on any mouse button

With "set term wxt":
- all "pause mouse" commands work correctly in gnuplot.exe
- all "pause mouse" commands have a problem in wgnuplot{_pipes}.exe:
  MOUSE_ variables are filled correctly, but <enter> has to be pressed
  in the command window to return back to the command prompt

It seems the "hit <enter>" bug is in windows+gnuplot.exe and in 
wxt+wgnuplot.exe combination.


Is WIN_IPC used correctly in both cases? Isn't somewhere missing an #ifdef?

Octave's ginput with wxt should work correctly then. BTW, I find wxt faster
than windows terminal for "plot" and "plot with image" (because of 
redrawings), but it is slower for "splot" pm3d surfaces.

---
PM

Re: towards 4.4

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

Hello

--- Petr Mikulik  wrote:

> BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows 
> correctly?
No not yet. See:
http://old.nabble.com/Problem-with-ginput-td26706688.html

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Hans-Bernhard B. <HBB...@t-...>]

Benjamin Lindner wrote:

[about wgnuplot 4.4 candidate:]
> There is still one issue open I believe:
> - Copying to clipboard as metafile is broken.

Broken how, exactly?

Re: towards 4.4

[Petr M. <mi...@ph...>]

> > BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows
> > correctly?
> 
> There has been a Bug report against this in octave, and IIRC there was an
> issue with "set multiplot".
> But I'm not currently up-to-date on whether this has been fixed already.
> It's not mentioned in the thread
> http://old.nabble.com/Ginput-doesn%27t-work-in-3.2.3-tp26470943p26470943.html

This occured on all OSes; it was due to missing "unset multiplot". It has 
been fixed.

---
PM

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

> 
> Other Windows issues:
> - Shall be the default terminal wx instead of windows? I would vote for 
>   this change.

If you build gnuplot with wxt terminal then it is already the default.
I personally prefer the native windows terminal, it is *much* faster, 
and it exhibits the expected behaviour of redrawing when moved/resized.
So I'd actually prefer to have the windows terminal the default.

There is still one issue open I believe:
- Copying to clipboard as metafile is broken.

This I'd love to see fixed, but I don't really see where the problem lurks.

benjamin

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

> BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows 
> correctly?

There has been a Bug report against this in octave, and IIRC there was 
an issue with "set multiplot".
But I'm not currently up-to-date on whether this has been fixed already.
It's not mentioned in the thread
http://old.nabble.com/Ginput-doesn%27t-work-in-3.2.3-tp26470943p26470943.html

benjamin

Re: towards 4.4

[Petr M. <mi...@ph...>]

> > Other Windows issues:
> > - Shall be the default terminal wx instead of windows? I would vote for 
> >   this change.
> > 
> > - The only issue which is missing in wx terminal is the "Print" button.
> >   How many Windows people use it for printing graphs instead of "set term"
> >   mechanism? Is it possible to add the print dialog easily?
> 
> I do not know how much effort will be required to add the print dialog.
> The wxt terminal is multi-platform terminal.  The addition the print dialog is better to be realized
> for all platforms if it is possible.

Can somebody comment how to add this feature?

> The remaining issue I know is 'pause mouse' problem on windows.
> http://old.nabble.com/pause-mouse-key-on-Windows-td5131156.html#a5131156
> http://old.nabble.com/pause-mouse-does-not-work-on-windows-term-on-gnuplot.exe-(on-wgnuplot,-pause-mouse-works-correct)-td26739744.html#a26772986
> 
> I have tried to fix the problem but I have not yet complete it because it is difficult to treat pause
> mouse issue on both windows terminal and wxt terminal to my ability.

I've tried it:

With "set term windows":
- pause mouse key; show var
  pause mouse; show var
  pause mouse any; show var
  ... Work correctly
- pause mouse button{1-3}; show var
  ... Wrong: it terminates on any mouse button

With "set term wxt":
- all "pause mouse" commands work correctly in gnuplot.exe
- all "pause mouse" commands have a problem in wgnuplot{_pipes}.exe:
  MOUSE_ variables are filled correctly, but <enter> has to be pressed
  in the command window to return back to the command prompt

Could someone solve this bug?
Is this bug a stop for 4.4 release?

BTW, gnuplot.exe is used in Octave nowadays ... does ginput work on Windows 
correctly?

---
PM

Re: towards 4.4

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

Hello

--- Petr Mikulik  wrote:
tribution for Windows:
> - Tatsuro MATSUOKA can compile Windows binary with all new features, such as 
>   wxterminal, pdfcairo, lua, etc. These are missing in binary packages 
>   provided by me.  I propose to distribute the package by TM obtained by 
>   joining his current
> 	gp44rc1-winbin.zip
> 	gp44rc1-winbin-wxt-diff.zip

It is glad for me if my binaries will uploaded in the gnuplot download page. 
 
> - Further, there will be x11 package for /usr-like system in Cygwin.
>   Is there any difference between the package provided by me and TM?
>   Note: this binary does not contain wxt, only x11.

Perhaps you build your binary of cygwin-1.5 if you build your binary on cygwin-1.7 you can easily add
lua/tikz, pdfcairo, and pngcairo.  On Dec 23 2009, the cygwin-1.7 has been a current release. If you
install dependencies of lua/tikz, pdfcairo, and pngcairo by cygwin setup.exe, you can easily add the
three terminals.

The cygwin-1.7 does not have the wxWidgets toolkits at present.  If 



 
> Other Windows issues:
> - Shall be the default terminal wx instead of windows? I would vote for 
>   this change.
> 
> - The only issue which is missing in wx terminal is the "Print" button.
>   How many Windows people use it for printing graphs instead of "set term"
>   mechanism? Is it possible to add the print dialog easily?

I do not know how much effort will be required to add the print dialog.
The wxt terminal is multi-platform terminal.  The addition the print dialog is better to be realized
for all platforms if it is possible.

The remaining issue I know is 'pause mouse' problem on windows.
http://old.nabble.com/pause-mouse-key-on-Windows-td5131156.html#a5131156
http://old.nabble.com/pause-mouse-does-not-work-on-windows-term-on-gnuplot.exe-(on-wgnuplot,-pause-mouse-works-correct)-td26739744.html#a26772986

I have tried to fix the problem but I have not yet complete it because it is difficult to treat pause
mouse issue on both windows terminal and wxt terminal to my ability.

Regards

Tatsuro   

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/