gnuplot-beta

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Sun, 4 Jul 2004, Ethan A Merritt wrote:

> On Sunday 04 July 2004 07:46 am, Hans-Bernhard Broeker wrote:
> > Warning:  wgnuplot now tends to lose the first keypress after starting
> > the program.  This did not happen with 4.0.0, and is fixed by back-dating
> > mouse.[ch] and readline.c to that state.
> 
> The last significant change I can see in readline.c is the change 
> 1.33 -> 1.34 (catch EINTR), but that was from 18 Feb 2004 so *before*
> the 4.0.0 tag.

Now that you mention it: right ;-).  A red herring.  On to the next one.

> (1) the pause-for-mouse code - but all of these changes are protected
>     by "if (paused_for_mouse) {...}" so I don't see how they could explain
>     anything that happens immediately on program entry

Agreed.

> (2) the addition of a table of "special keys" (4 Jun 2004).  I can't see
>     anything wrong with this code either, but it's Petr's addition so maybe
>     he can spot something I didn't.

This would be my prime suspect for the moment.

> > Which rather strongly hints at problems with the mousing/keyboard
> > synchronization not only on X11, but also on MS Windows.
> 
> Maybe.  But I don't recall that we ever saw X11 problems on program entry.

Not immediately on program entry, but this problem does feel vaguely like
the early renditions of our select()/buffering problems on X11 / PIPE_IPC,
where e.g. commands typed or piped in while the gnuplot_x11 window was
being started could be dropped, e.g.

	echo -e "plot sin(x)\nplot(cos(x)\n" | gnuplot

might end up with the sine wave plot shown, because the second line of
input was lost in transport.

> None of the recent code additions should be triggered until you actually
> issue a "pause mouse" command.  Is there any conceivable way that
> Windows could manage to start up without having initialized the
> pause_for_mouse TBOOLEAN to FALSE?

I don't think so.

> Does the problem still happen if gnuplot is configured with
> #undef USE_MOUSE ?

To be experimented with.  I'm not even sure the Windows version
still builds in that configuration...

> > But backdating those files to 4.0.0 doesn't cure this problem
> > --- it doesn't seem to occur in 4.0.0 though.
> 
> How about if things are back-dated to just before ANSI-fication?

The OP reported the probleming having appeared considerably earlier than
4.0.1, i.e. before the ANSI-fication.  Anyway, the Windows code was quite
completely ANSI style long before that anyway, since K&R compilers never
existed for MS Windows programs.

But for the record: going back to 4.0.1 didn't help, unless I misremember
the weekend's experiments badly.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Hans-Bernhard Broeker wrote:

> > Does the problem still happen if gnuplot is configured with
> > #undef USE_MOUSE ?
> 
> To be experimented with.  I'm not even sure the Windows version
> still builds in that configuration...

Testing...  it almost does.  (wpause assumes paused_for_mouse, had to
#ifdef USE_MOUSE that).  But it doesn't help to prevent the problem.

But now I've found a truly ghastly factor influencing one of the problems
I described: it depends on where the gnuplot text window pops up, relative
to the current position of the mouse.  If the mouse pointer is at rest
while starting wgnuplot.exe (current version) via the keyboard, and it
happens to be sitting *inside* the newly popped-up wgnuplot text window,
the first keypress will be lost.  This is insane.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

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

On Monday 05 July 2004 05:07 pm, Hans-Bernhard Broeker wrote:
>
> But now I've found a truly ghastly factor influencing one of the problems
> I described: it depends on where the gnuplot text window pops up, relative
> to the current position of the mouse.  If the mouse pointer is at rest
> while starting wgnuplot.exe (current version) via the keyboard, and it
> happens to be sitting *inside* the newly popped-up wgnuplot text window,
> the first keypress will be lost.  This is insane.

OK.  So it takes one event (does Windows call them "events"?) before
focus is given to the new text window.  That sounds like a Windows bug,
pure and simple.  Why did it not strike before?  I don't know.  But the
work-around would seem to be to have gnuplot itself generate a 
junk event of some sort on entry, so that the first event is something
other than a keypress.  Or maybe there is an explicit "gain focus" call?

Re: Keyboard input losses also on MS Windows

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Mon, 5 Jul 2004, Hans-Bernhard Broeker wrote:
>
>  
>
>>>Does the problem still happen if gnuplot is configured with
>>>#undef USE_MOUSE ?
>>>      
>>>
>>To be experimented with.  I'm not even sure the Windows version
>>still builds in that configuration...
>>    
>>
>
>Testing...  it almost does.  (wpause assumes paused_for_mouse, had to
>#ifdef USE_MOUSE that).  But it doesn't help to prevent the problem.
>
>But now I've found a truly ghastly factor influencing one of the problems
>I described: it depends on where the gnuplot text window pops up, relative
>to the current position of the mouse.  If the mouse pointer is at rest
>while starting wgnuplot.exe (current version) via the keyboard, and it
>happens to be sitting *inside* the newly popped-up wgnuplot text window,
>the first keypress will be lost.  This is insane.
>

That is a strange one...  On the topic of plot window location, anyone 
else find it kind of irksome that a newly created plot window is always 
situated on top of the command line window and completely covering it? 
 I'd prefer it to be created as far away from the command line as 
possible, and not grab focus if not in "raise" mode.

Dan

Re: Keyboard input losses also on MS Windows

[Daniel J S. <dan...@ie...>]

> That is a strange one...  On the topic of plot window location, anyone 
> else find it kind of irksome that a newly created plot window is 
> always situated on top of the command line window and completely 
> covering it? I'd prefer it to be created as far away from the command 
> line as possible, and not grab focus if not in "raise" mode. 


In X11, that is -- D

Re: Keyboard input losses also on MS Windows

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

On Monday 05 July 2004 06:34 pm, Daniel J Sebald wrote:
> On the topic of plot window location, anyone
> else find it kind of irksome that a newly created plot window is always
> situated on top of the command line window and completely covering it?
>  I'd prefer it to be created as far away from the command line as
> possible, 


So?  Tell your window manager that.
Or put it in your Xresources file.
My plot windows stack in the upper right corner of the screen.

> and not grab focus if not in "raise" mode. 

I tell KDE not to give focus to a window unless the mouse
is in it.  If your window manager doesn't allow that, then
look for a better one.

Re: Keyboard input losses also on MS Windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Monday 05 July 2004 06:34 pm, Daniel J Sebald wrote:
>  
>
>>On the topic of plot window location, anyone
>>else find it kind of irksome that a newly created plot window is always
>>situated on top of the command line window and completely covering it?
>> I'd prefer it to be created as far away from the command line as
>>possible, 
>>    
>>
>
>
>So?  Tell your window manager that.
>Or put it in your Xresources file.
>My plot windows stack in the upper right corner of the screen.
>

OK, I've tried a bit of this now.  I have SawFish.  There are plenty of 
settings but some have undesirable behavior.  One of them is not too 
bad, called "first-fit", placing windows in corners of the screen and 
seems to avoid the parent's space.  Pretty much what I want, thanks.

The focus is a different matter.  Someone who uses the gnuplot_x11 
window hot keys a lot probably doesn't mind the created plot grabbing 
the focus.  Changing the window manager settings so that "focus on 
display" is not active helps in gnuplot... but it alters all other 
window behavior too.  The thing is, in most applications you want to 
grab focus upon display.  Say one creates an editor window with "xemacs 
junk &"; well you're going to type in the editor right away so, yes, 
"grab focus".  But in gnuplot, one isn't going to type in the plot 
window (unless hot key user) so, no, don't grab focus.

I tried creating a patch with XGetInputFocus() and XSetInputFocus() to 
restore the focus to the parent, i.e., gnuplot command line.  But I 
couldn't get it to work...  Not that important.

Dan

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Ethan Merritt wrote:

> On Monday 05 July 2004 05:07 pm, Hans-Bernhard Broeker wrote:
> >
> > But now I've found a truly ghastly factor influencing one of the problems
> > I described: it depends on where the gnuplot text window pops up, relative
> > to the current position of the mouse.  If the mouse pointer is at rest
> > while starting wgnuplot.exe (current version) via the keyboard, and it
> > happens to be sitting *inside* the newly popped-up wgnuplot text window,
> > the first keypress will be lost.  This is insane.
> 
> OK.  So it takes one event (does Windows call them "events"?) before
> focus is given to the new text window.  

I'm sure it's not quite that simple.  By the time I press a key, at least
a dozen events must have been sent to that window (WM_CREATE, WM_PAINT,
WM_SETFOCUS, ...).  I'm not quite sure, but it *seems* that it also makes
a difference if I move the mouse around a bit before hitting that key.

> first event is something other than a keypress.  Or maybe there is an
> explicit "gain focus" call?

There is --- it just doesn't seem to take effect.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

[Franco F. <ffr...@Ca...>]

Gnuplot team,

I also found that the first key is missing when starting gnuplot, when
I compiled the CVS source. I first noticed it for version 4.0.2.
But it is not only the first keystroke, also the commands from the pull
done window are missing the first character. 

On top of this it depends on how gnuplot is launched and if the mouse
pointer is moved and or inside the new gnuplot window.
(also noticed by Daniel J Sebald)

I have done some experiments with the latest CVS from yesterday, and 
compiled this with replacing some files with files from the source tar
ball of 4.0.0.

If I replace mouse.c .h and readline.c  I get still the same behavior.
This is not what Hans-Bernard Broeker found, he wrote in this list

On Sunday 04 July 2004 07:46 am, Hans-Bernhard Broeker wrote:
> Warning:  wgnuplot now tends to lose the first keypress after
starting
> the program.  This did not happen with 4.0.0, and is fixed by
back-dating
> mouse.[ch] and readline.c to that state.



If I replace wtext.c .h and all the other source code is from the CVS
from yesterday, the problem with the first character are gone.
So in mine opion it is not mouse.c or readline.c but wtext.c with was
modified to remove a very old bug, but introduced a new bug.

Franco Fritschij

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

Franco Fritschij wrote:

> If I replace wtext.c .h and all the other source code is from the CVS
> from yesterday, the problem with the first character are gone.
> So in mine opion it is not mouse.c or readline.c but wtext.c with was
> modified to remove a very old bug, but introduced a new bug.

Dietmar and I also reached this conclusion in the meantime.  The new bug 
apparently crept in between version 4.0.1 and 4.0.2, in wtext.c. But 
even after looking at the diffs for quite some time, I still have no 
idea what may be broken.  The changes are numerous, but AFAICS, they're 
all benign: whitespace changes, re-indentation, comments moved around a 
bit, and such things.  The only somewhat suspicious ones I can see are 
the changes to move return and break commands into the blocks enclosing 
code for one case of a switch().

Any assistance in solving this puzzle would be glady appreciated.
-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>
> Any assistance in solving this puzzle would be glady appreciated.



I think I may have found it... or one problem anyway.

I'm doing a "diff -w" and this one is in question:

<         while((nYinc || nXinc) && !PtInRect(&rect, pt)
<               && (GetAsyncKeyState(VK_LBUTTON) < 0));
<         } /* moved inside viewport */
<         break;
---
 >               while( (nYinc || nXinc) && !PtInRect(&rect, pt) &&
 >                 (GetAsyncKeyState(VK_LBUTTON) < 0) );
1425a1402,1403
 >             }
 >             break;

As with some other case statements, the "break" was moved inside the 
curley bracket thinking that it was like the others.  But in this case 
the {} is not for defining new variables, it is for an if(){} statement, 
I believe.  Does that seem like it could be the problem?

Dan

Re: Keyboard input losses also on MS Windows

[Daniel J S. <dan...@ie...>]

I can't compile those files, but another check you could do is to 
generate the assembly file for both (non-annotated) and do a diff on the 
two generated files. -- Dan


Daniel J Sebald wrote:

> Hans-Bernhard Broeker wrote:
>
>>
>> Any assistance in solving this puzzle would be glady appreciated.
>

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Wed, 7 Jul 2004, Daniel J Sebald wrote:

> As with some other case statements, the "break" was moved inside the 
> curley bracket thinking that it was like the others.  But in this case 
> the {} is not for defining new variables, it is for an if(){} statement, 
> I believe.  Does that seem like it could be the problem?

Yep, that was the one.  CVS head is fixed already.  The 4.0 branch will
receive the fix right away.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.