Re: [Plplot-devel] Issues with locate mode for the non-IPC3 case

[Alan W. Irwin]

On 2017-10-08 12:54+0100 Phil Rosenberg wrote:


On 7 October 2017 at 02:14, Alan W. Irwin  wrote:

Hi Phil:

I just discovered on Linux that your IPC3 workaround does allow
-locate mode for example 1 to work perfectly for mouse clicks.  (IPC3
locate mode key hits are not implemented yet.) But I also think that
workaround should not be necessary, and the fundamental problem is
when I originally implemented IPC3 locate mode I used the non-IPC3
version of wxPlFrame::ReadTransmission to model what the IPC3 version
of that routine should do in locate mode, but it turns out that is a
flawed model!  So it is no wonder that you had to implement a
workaround to get locate mode to work at all for the IPC3 case.

Here are the current (master HEAD) problems with locate mode for the
non-IPC3 case as demonstrated when I run

examples/c/x01c -dev wxwidgets -locate

on Linux.

1. The initial wxPLViewer response is always a blank screen.

2. Furthermore, initial blind mouse clicking on the position of
viewports 2, 3, and 4 gets no response at all.  Blind clicking on the
(upper-left) position of viewport 1 does typically get a response (but
sometimes only after several clicks), and if I keep clicking
eventually the actual plot appears, and then after that clicking on
viewports 2, 3, and 4 finally begins to work.


Just tested the latest master head on Windows and it works perfectly.
Not sure why it would be different on Linux.


My own gut feeling is there is some general issue with the way events
are set up that is cause of these issues, but the bug is only exposed
on some platforms (similar to the Linux OnCreate delay bug that you
fixed in January this year just before the release of 5.12.0.)



3. In no case have I gotten key hits to work (even though there is
code to handle that case for the non-IPC3 version of
wxPlFrame::ReadTransmission).



You are correct, key presses don't work on Linux, that is due to a
difference between Linux and windows in ter,s of event capture that I
wasn't aware of when I wrote the viewer. It is on my fix list, but
feel free to add it to the bug tracker so I don't forget.


I was unaware until reading your above remark there was a difference
between Linux and Windows event capture.  However, given that is the
case is it possible you still need to make an adjustment for that
difference in order to solve Linux issues 1 and 2 as well?

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Issues with locate mode for the non-IPC3 case

[Phil Rosenberg]

On 7 October 2017 at 02:14, Alan W. Irwin  wrote:
> Hi Phil:
>
> I just discovered on Linux that your IPC3 workaround does allow
> -locate mode for example 1 to work perfectly for mouse clicks.  (IPC3
> locate mode key hits are not implemented yet.) But I also think that
> workaround should not be necessary, and the fundamental problem is
> when I originally implemented IPC3 locate mode I used the non-IPC3
> version of wxPlFrame::ReadTransmission to model what the IPC3 version
> of that routine should do in locate mode, but it turns out that is a
> flawed model!  So it is no wonder that you had to implement a
> workaround to get locate mode to work at all for the IPC3 case.
>
> Here are the current (master HEAD) problems with locate mode for the
> non-IPC3 case as demonstrated when I run
>
> examples/c/x01c -dev wxwidgets -locate
>
> on Linux.
>
> 1. The initial wxPLViewer response is always a blank screen.
>
> 2. Furthermore, initial blind mouse clicking on the position of
> viewports 2, 3, and 4 gets no response at all.  Blind clicking on the
> (upper-left) position of viewport 1 does typically get a response (but
> sometimes only after several clicks), and if I keep clicking
> eventually the actual plot appears, and then after that clicking on
> viewports 2, 3, and 4 finally begins to work.

Just tested the latest master head on Windows and it works perfectly.
Not sure why it would be different on Linux.
>
> 3. In no case have I gotten key hits to work (even though there is
> code to handle that case for the non-IPC3 version of
> wxPlFrame::ReadTransmission).
>

You are correct, key presses don't work on Linux, that is due to a
difference between Linux and windows in ter,s of event capture that I
wasn't aware of when I wrote the viewer. It is on my fix list, but
feel free to add it to the bug tracker so I don't forget.

> My guess is most or all of symptoms 1 and 2 are due to some screwup
> with the way events are being handled in the non-IPC3 case, and I
> likely propagated those same problems to the IPC3 side of things when
> I implemented the IPC3 version of locate mode. I have no explanation
> as to why hitting keys gets no response (symptom 3) for the non-IPC3
> case.
>
> In any case, I hope you are willing to fix the above set of non-IPC3
> issues because once they are solved I believe I should be able to
> quickly follow up with a reliable IPC3 variant using your corrected
> non-IPC3 implementation as a model.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel