Re: [Plplot-devel] Linux OnCreate delay bug -- solution

2017-01-04 Thread Alan W. Irwin 
On 2017-01-04 20:08-0500 Pedro Vicente wrote:

>>> Yes that is the expected output, although the window titles should be 
>>> different. But actually it may be nicer to at least use 2 different curves. 
>>> An easy change. What do you think?
>
> I don't have an opinion on the plot itself, but regarding the 
> test_c_wxwidgets test, it would be a good idea to put a simple
> sleep(1)
> betwwen each test so we can see that it's doing what it should do

Hi Pedro:

That workaround would work for both -dev wxwidgets (or more likely the
wxPLViewer application that that device communciates with) and -dev
wingcc.  But since a common script is used for all interactive device
tests, that workaround would put an unnecessary delay into the results
for -dev xwin, tk, xcairo, and qtwidget. Therefore in this case I
prefer the definitive fix for these -np issues for wxPLViewer and -dev
wingcc.

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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Alan W. Irwin 
On 2017-01-05 00:54- p.d.rosenb...@gmail.com wrote:

> 1. Yes [two plots are] expected output, although the window titles
should be different. But actually it may be nicer to at least use 2
different curves. An easy change. What do you think?

Good idea.  So, yes please!

> 2. Will do [README.release paragraph] plus this all really needs properly 
> adding to the docs. I will try to do that asap.

Thanks.  README.release paragraph is release-essential.  DocBook update
concerning wxwidgets is a "would-be-wonderful".

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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Pedro Vicente 
>> Yes that is the expected output, although the window titles should be 
>> different. But actually it may be nicer to at least use 2 different curves. 
>> An easy change. What do you think?

I don't have an opinion on the plot itself, but regarding the test_c_wxwidgets 
test, it would be a good idea to put a simple
sleep(1) 
betwwen each test so we can see that it's doing what it should do

I tried on my linux 16.04, same results as CentOS (I don'have the 14.04 and 
debian anymore)
-Pedro
  - Original Message - 
  From: p.d.rosenb...@gmail.com 
  To: Alan W. Irwin ; Pedro Vicente ; PLplot development list 
  Sent: Wednesday, January 04, 2017 7:54 PM
  Subject: RE: Linux OnCreate delay bug -- solution


  That looks promising 

   

  To answer your questions Alan (sorry for top posting, but I'm on my phone)

   

1.. Yes that is the expected output, although the window titles should be 
different. But actually it may be nicer to at least use 2 different curves. An 
easy change. What do you think?
2.. Will do, plus this all really needs properly adding to the docs. I will 
try to do that asap.
   

   

   

  Sent from my Windows 10 phone

   

  From: Alan W. Irwin
  Sent: 04 January 2017 19:17
  To: Phil Rosenberg; Pedro Vicente; PLplot development list
  Subject: Re: Linux OnCreate delay bug -- solution

   

  On 2017-01-04 13:04-0500 Pedro Vicente wrote:

   

  > Hi Phil

  > 

  > I got a good plot on CentOS, below output.

  > I'll test other Linux later

   

  > 

  >> So what I

  >> would propose is that for this release we attempt to not add or remove

  >> anything from the API and just stick with an example that  works with

  >> what we've got. Then after this release we can add non-template

  >> classes for wxFrame, wxDialog and wxPanel which can be used really

  >> easily by our users and we have time to test them and make sure the

  >> API for their use is stable before the next release.

  >> 

  >> Does that seem sensible?

  > 

   

  To Phil and Pedro:

   

  @Phil:

   

  The test_c_wxwidgets and test_wxPLplotDemo targets worked without

  issues here.  So we now have three good tests on Linux and one good

  test on Windows.  So this indeed seems promising as a solution to

  this release critical bug, and I thank you for this timely

  release-critical bug fixing.

   

  @Both:

   

  To finish off this topic for the release I need some more from both

  of you.

   

  @Phil:

   

  1. It sounded from your description that you were changing the example

  to try two different methods of generating those plots so it makes

  sense that test_wxPLplotDemo now produces two identical plots for me,

  but please confirm that the two plots I observed are the intended

  effect.

   

  2. Please commit a change to README.release describing what you have

  done to deal with this bug equivalent to what Pedro wrote up for his

  solution.

   

  @Pedro: I think your current CentOS test is equivalent to just

  building the test_wxPLplotDemo target?  Please extend that test to

  building the test_c_wxwidgets target as well. You were already

  planning to test Phil's solution on all the Linux platforms accessible

  to you, but please do the full test (build both the test_wxPLplotDemo

  and test_c_wxwidgets targets) for all Linux platforms.  And similarly

  for your Windows platforms.  There, the convenient test_* targets

  won't work so you will have to do the equivalent by hand (run

  wxPLplotDemo and run several C examples with -dev wxwidgets). Finally,

  please also test your own software projects that link with the

  plplotwxwidgets library on all platforms where you expect your own

  software projects to currently work.  (I assume that is just Windows,

  but please test on at least one Linux platform as well if you

  expect your software to work on both Windows and Linux.)

   

  Every tested platform that you add gives us just that much further

  confidence that Phil's solution is robust for this release, and I

  thank you in advance for all this essential testing work for our

  release.

   

  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!

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

2017-01-04 Thread p.d.rosenberg 
That looks promising 

To answer your questions Alan (sorry for top posting, but I'm on my phone)

1. Yes that is the expected output, although the window titles should be 
different. But actually it may be nicer to at least use 2 different curves. An 
easy change. What do you think?
2. Will do, plus this all really needs properly adding to the docs. I will try 
to do that asap.



Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 04 January 2017 19:17
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: Re: Linux OnCreate delay bug -- solution

On 2017-01-04 13:04-0500 Pedro Vicente wrote:

> Hi Phil
>
> I got a good plot on CentOS, below output.
> I'll test other Linux later

>
>> So what I
>> would propose is that for this release we attempt to not add or remove
>> anything from the API and just stick with an example that  works with
>> what we've got. Then after this release we can add non-template
>> classes for wxFrame, wxDialog and wxPanel which can be used really
>> easily by our users and we have time to test them and make sure the
>> API for their use is stable before the next release.
>> 
>> Does that seem sensible?
>

To Phil and Pedro:

@Phil:

The test_c_wxwidgets and test_wxPLplotDemo targets worked without
issues here.  So we now have three good tests on Linux and one good
test on Windows.  So this indeed seems promising as a solution to
this release critical bug, and I thank you for this timely
release-critical bug fixing.

@Both:

To finish off this topic for the release I need some more from both
of you.

@Phil:

1. It sounded from your description that you were changing the example
to try two different methods of generating those plots so it makes
sense that test_wxPLplotDemo now produces two identical plots for me,
but please confirm that the two plots I observed are the intended
effect.

2. Please commit a change to README.release describing what you have
done to deal with this bug equivalent to what Pedro wrote up for his
solution.

@Pedro: I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?  Please extend that test to
building the test_c_wxwidgets target as well. You were already
planning to test Phil's solution on all the Linux platforms accessible
to you, but please do the full test (build both the test_wxPLplotDemo
and test_c_wxwidgets targets) for all Linux platforms.  And similarly
for your Windows platforms.  There, the convenient test_* targets
won't work so you will have to do the equivalent by hand (run
wxPLplotDemo and run several C examples with -dev wxwidgets). Finally,
please also test your own software projects that link with the
plplotwxwidgets library on all platforms where you expect your own
software projects to currently work.  (I assume that is just Windows,
but please test on at least one Linux platform as well if you
expect your software to work on both Windows and Linux.)

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
release.

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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Alan W. Irwin 
On 2017-01-04 16:21-0500 Pedro Vicente wrote:

> I did [on CentOS]
> make VERBOSE=1 test_c_wxwidgets >& out.txt &
>
> there were no plots, just black and grey windows that quickly showed and 
> disappeared
>
> output is attached

As you can see for yourself there are no warnings or errors so that
looks promising.  However, you should skim those debug results (which
I did not do myself) to make sure there is nothing unexpected going
on for any of those examples that are run by that test.

Those "black and grey windows" are what I see here as well.  They are
apparently an artifact of the current wxPLViewer implementation where
nothing is displayed for that GUI until the buffer representing all
the plot activity for a particular page has been accumulated, then at
EOP that display is immediately removed again.  That is fine for
normal interactive use where you are clicking on the GUI to move
through the pages.  But the effect for the -np (no pause) option is
the page flashes on the screen for a microsec or so, and you end up
only seeing that weird effect.  If I recall correctly from when I was
testing on -dev wingcc on the Wine version of Windows there was a
similar weird effect with -np there (which was likely due to the same
cause).

As a low-priority item I have asked Phil to fix this -np issue for
-dev wxwidgets by following the buffer models used by -dev xwin, -dev
xcairo, and -dev qtwidget which display the buffer results as they
become available for the test_c_xwin, test_c_xcairo, and
test_c_qtwidget targets rather than waiting until the buffer has been
accumulated for the entire page. But since I plan to greatly improve
the efficiency of the IPC between -dev wxwidgets and wxPLViewer in any
case right after this release I may end up fixing the -np issue myself
at the same time since the two issues are likely closely related.  And
someone should similarly fix -dev wingcc.

But meanwhile even with these weird-looking results for the -np option
for -dev wxwidgets and -dev wingcc, that option is still extremely
useful for the interactive tests associated with building the
test_c_wxwidgets and test_c_wingcc targets because it means you test
several examples (rather than just one or two) for such obvious
run-time issues as segfaults, and you don't have to babysit the test
by constantly clicking on the GUI as the test goes through those
several examples.

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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Pedro Vicente 

Hi Alan


I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?


yes


Please extend that test to
building the test_c_wxwidgets target as well.


I did
make VERBOSE=1 test_c_wxwidgets >& out.txt &

there were no plots, just black and grey windows that quickly showed 
and disappeared


output is attached

-Pedro


On 2017-01-04 14:17, Alan W. Irwin wrote:

On 2017-01-04 13:04-0500 Pedro Vicente wrote:


Hi Phil

I got a good plot on CentOS, below output.
I'll test other Linux later





So what I
would propose is that for this release we attempt to not add or 
remove
anything from the API and just stick with an example that  works 
with

what we've got. Then after this release we can add non-template
classes for wxFrame, wxDialog and wxPanel which can be used really
easily by our users and we have time to test them and make sure the
API for their use is stable before the next release.
Does that seem sensible?




To Phil and Pedro:

@Phil:

The test_c_wxwidgets and test_wxPLplotDemo targets worked without
issues here.  So we now have three good tests on Linux and one good
test on Windows.  So this indeed seems promising as a solution to
this release critical bug, and I thank you for this timely
release-critical bug fixing.

@Both:

To finish off this topic for the release I need some more from both
of you.

@Phil:

1. It sounded from your description that you were changing the 
example

to try two different methods of generating those plots so it makes
sense that test_wxPLplotDemo now produces two identical plots for me,
but please confirm that the two plots I observed are the intended
effect.

2. Please commit a change to README.release describing what you have
done to deal with this bug equivalent to what Pedro wrote up for his
solution.

@Pedro: I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?  Please extend that test to
building the test_c_wxwidgets target as well. You were already
planning to test Phil's solution on all the Linux platforms 
accessible

to you, but please do the full test (build both the test_wxPLplotDemo
and test_c_wxwidgets targets) for all Linux platforms.  And similarly
for your Windows platforms.  There, the convenient test_* targets
won't work so you will have to do the equivalent by hand (run
wxPLplotDemo and run several C examples with -dev wxwidgets). 
Finally,

please also test your own software projects that link with the
plplotwxwidgets library on all platforms where you expect your own
software projects to currently work.  (I assume that is just Windows,
but please test on at least one Linux platform as well if you
expect your software to work on both Windows and Linux.)

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
release.

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
__


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org//data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake 
-H/data/home002/pvicente/dev/plplot-plplot 
-B/data/home002/pvicente/dev/plplot-plplot/build --check-build-system 
CMakeFiles/Makefile.cmake 0
make -f CMakeFiles/Makefile2 test_c_wxwidgets
make[1]: Entering directory `/data/home002/pvicente/dev/plplot-plplot/build'
/data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake 
-H/data/home002/pvicente/dev/plplot-plplot 
-B/data/home002/pvicente/dev/plplot-plplot/build --check-build-system 
CMakeFiles/Makefile.cmake 0
/data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake -E 
cmake_progress_start /data/home002/pvicente/dev/plplot-plplot/build/CMakeFiles 
49
make -f CMakeFiles/Makefile2 examples/CMakeFiles/test_c_wxwidgets.dir/all
make[2]: Entering directory `/data/home002/pvicente/dev/plplot-plplot/build'
make -f include/CMakeFiles/plhershey-unicode-gen.dir/build.make 
include/CMakeFiles/plhershey-unicode-gen.dir/depend
make[3]: Entering directory `/data/home002/pvicente/dev/plplot-plplot/build'
cd /data/home002/pvicente/dev/plplot-plplot/build && 
/data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake -E 
cmake_depends "Unix Makefiles" /data/home002/pvicente/dev/plplot-plplot 
/data/home002/pvicente/dev/plplot-plplot/include 
/data/home002/pvicente/dev/plplot-plplot/build

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

2017-01-04 Thread Alan W. Irwin 
On 2017-01-04 13:04-0500 Pedro Vicente wrote:

> Hi Phil
>
> I got a good plot on CentOS, below output.
> I'll test other Linux later

>
>> So what I
>> would propose is that for this release we attempt to not add or remove
>> anything from the API and just stick with an example that  works with
>> what we've got. Then after this release we can add non-template
>> classes for wxFrame, wxDialog and wxPanel which can be used really
>> easily by our users and we have time to test them and make sure the
>> API for their use is stable before the next release.
>> 
>> Does that seem sensible?
>

To Phil and Pedro:

@Phil:

The test_c_wxwidgets and test_wxPLplotDemo targets worked without
issues here.  So we now have three good tests on Linux and one good
test on Windows.  So this indeed seems promising as a solution to
this release critical bug, and I thank you for this timely
release-critical bug fixing.

@Both:

To finish off this topic for the release I need some more from both
of you.

@Phil:

1. It sounded from your description that you were changing the example
to try two different methods of generating those plots so it makes
sense that test_wxPLplotDemo now produces two identical plots for me,
but please confirm that the two plots I observed are the intended
effect.

2. Please commit a change to README.release describing what you have
done to deal with this bug equivalent to what Pedro wrote up for his
solution.

@Pedro: I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?  Please extend that test to
building the test_c_wxwidgets target as well. You were already
planning to test Phil's solution on all the Linux platforms accessible
to you, but please do the full test (build both the test_wxPLplotDemo
and test_c_wxwidgets targets) for all Linux platforms.  And similarly
for your Windows platforms.  There, the convenient test_* targets
won't work so you will have to do the equivalent by hand (run
wxPLplotDemo and run several C examples with -dev wxwidgets). Finally,
please also test your own software projects that link with the
plplotwxwidgets library on all platforms where you expect your own
software projects to currently work.  (I assume that is just Windows,
but please test on at least one Linux platform as well if you
expect your software to work on both Windows and Linux.)

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
release.

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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Pedro Vicente 
Hi Phil

I got a good plot on CentOS, below output.
I'll test other Linux later


12:40:53: Debug: wxPLplotwindow::wxPLplotwindow
12:40:53: Debug: wxPLplotwindow::wxPLplotwindow
12:40:53: Debug: frame->Create
12:40:53: Debug: Plot() Yielding
12:40:53: Debug: wxPLplotwindow::OnCreate
12:40:53: Debug: plD_init_wxwidgets(): enter
12:40:53: Debug: wxPLDevice(): enter
12:40:53: Debug: wxPLDevice(): gc done
12:40:53: Debug: wxPLDevice(): m_interactiveTextGcdc done
12:40:53: Debug: wxPLDevice(): SetDC done
12:40:53: Debug: wxPLDevice(): leave
12:40:53: Debug: plD_init_wxwidgets(): leave
12:40:53: Debug: wxPLplotwindow::OnCreate
12:40:53: Debug: plD_init_wxwidgets(): enter
12:40:53: Debug: wxPLDevice(): enter
12:40:53: Debug: wxPLDevice(): gc done
12:40:53: Debug: wxPLDevice(): m_interactiveTextGcdc done
12:40:53: Debug: wxPLDevice(): SetDC done
12:40:53: Debug: wxPLDevice(): leave
12:40:53: Debug: plD_init_wxwidgets(): leave
12:40:54: Debug: Plot()
12:40:54: Debug: Plot()

>So what I
> would propose is that for this release we attempt to not add or 
> remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?


yes, sounds good, thanks
-Pedro



On 2017-01-04 09:26, Phil Rosenberg wrote:
> Hi All
>
> Right I'm back with sensible access to all my systems and back into 
> my
> usual routine.
>
> So, here goes
>
> On 28 December 2016 at 05:00, Pedro Vicente
>  wrote:
>> One small caveat is that I think you can only instantiate the 
>> template with
>> a class that has this Create()
>> signature
>>
>> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
>> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>>
>> which is of course , wxFrames, the current use.
>> Probably dialogs too, but maybe not things like buttons and other 
>> GUI
>> elements.
>> But I assume that the vast majority of users, if not all, draws the 
>> plot in
>> "regular" windows?.
>
> You are indeed correct about this. The other very major category that
> I think doesn't have this signature is wxPanels and we absolutely 
> must
> maintain compatibility for this class. In fact it is more important
> for this class than any other, because you could create always create
> a wxPanel and put it as the only element of a wxFrame, wxDialog,
> wxPage etc
>
> So what I have done is modify the example so that we now generate two
> wxFrames with identical plots, but in slightly different ways.
>
> In one I have used the wxPlDemoFrame and moved most of the
> initialisation code into its constructor and then this frame is set 
> up
> to capture idle events. When it captures idle events it checks
> everything is ready and calls Plot() (setting a flag so this only
> happens once).
>
> In the other I show how a frame can be created without using
> inheritance, with the caveat that Show() must be called and we must
> then wait for the wxEVT_CREATE event to be processed before we do any
> plotting.
>
> If I have this right then these methods should be totally general and
> should allow any of the constructors for any of the different 
> wxWindow
> derived classes to be used. Which is good.
>
> However, you are very correct Pedro that mostly people are likely to
> want to derive from classes such as wxFrame, wxDialog and wxPanel. I
> think it makes sense to create those classes for our users so that
> they can use those in as few lines of code as possible. So what I
> would propose is that for this release we attempt to not add or 
> remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?
>
> So I have just committed the changes I mentioned above. Pedro and
> Alan, if you have time to test them on your Linux systems that would
> be good. I've tested on my Windows system and I'm about to do so on 
> my
> Linux system too.
>
> Phil

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Phil Rosenberg 
Just to add that I've just tested on my Ubuntu 16.04 system logging on
remotely using Cygwin ssh and X11 server and n my work CentOS system
logging on directly. Everything seems fine! Hopefully you will both
get the same results Pedro and Alan.

Phil

On 4 January 2017 at 14:26, Phil Rosenberg  wrote:
> Hi All
>
> Right I'm back with sensible access to all my systems and back into my
> usual routine.
>
> So, here goes
>
> On 28 December 2016 at 05:00, Pedro Vicente
>  wrote:
>> One small caveat is that I think you can only instantiate the template with
>> a class that has this Create()
>> signature
>>
>> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
>> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>>
>> which is of course , wxFrames, the current use.
>> Probably dialogs too, but maybe not things like buttons and other GUI
>> elements.
>> But I assume that the vast majority of users, if not all, draws the plot in
>> "regular" windows?.
>
> You are indeed correct about this. The other very major category that
> I think doesn't have this signature is wxPanels and we absolutely must
> maintain compatibility for this class. In fact it is more important
> for this class than any other, because you could create always create
> a wxPanel and put it as the only element of a wxFrame, wxDialog,
> wxPage etc
>
> So what I have done is modify the example so that we now generate two
> wxFrames with identical plots, but in slightly different ways.
>
> In one I have used the wxPlDemoFrame and moved most of the
> initialisation code into its constructor and then this frame is set up
> to capture idle events. When it captures idle events it checks
> everything is ready and calls Plot() (setting a flag so this only
> happens once).
>
> In the other I show how a frame can be created without using
> inheritance, with the caveat that Show() must be called and we must
> then wait for the wxEVT_CREATE event to be processed before we do any
> plotting.
>
> If I have this right then these methods should be totally general and
> should allow any of the constructors for any of the different wxWindow
> derived classes to be used. Which is good.
>
> However, you are very correct Pedro that mostly people are likely to
> want to derive from classes such as wxFrame, wxDialog and wxPanel. I
> think it makes sense to create those classes for our users so that
> they can use those in as few lines of code as possible. So what I
> would propose is that for this release we attempt to not add or remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?
>
> So I have just committed the changes I mentioned above. Pedro and
> Alan, if you have time to test them on your Linux systems that would
> be good. I've tested on my Windows system and I'm about to do so on my
> Linux system too.
>
> Phil

--
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] Linux OnCreate delay bug -- solution

2017-01-04 Thread Phil Rosenberg 
Hi All

Right I'm back with sensible access to all my systems and back into my
usual routine.

So, here goes

On 28 December 2016 at 05:00, Pedro Vicente
 wrote:
> One small caveat is that I think you can only instantiate the template with
> a class that has this Create()
> signature
>
> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>
> which is of course , wxFrames, the current use.
> Probably dialogs too, but maybe not things like buttons and other GUI
> elements.
> But I assume that the vast majority of users, if not all, draws the plot in
> "regular" windows?.

You are indeed correct about this. The other very major category that
I think doesn't have this signature is wxPanels and we absolutely must
maintain compatibility for this class. In fact it is more important
for this class than any other, because you could create always create
a wxPanel and put it as the only element of a wxFrame, wxDialog,
wxPage etc

So what I have done is modify the example so that we now generate two
wxFrames with identical plots, but in slightly different ways.

In one I have used the wxPlDemoFrame and moved most of the
initialisation code into its constructor and then this frame is set up
to capture idle events. When it captures idle events it checks
everything is ready and calls Plot() (setting a flag so this only
happens once).

In the other I show how a frame can be created without using
inheritance, with the caveat that Show() must be called and we must
then wait for the wxEVT_CREATE event to be processed before we do any
plotting.

If I have this right then these methods should be totally general and
should allow any of the constructors for any of the different wxWindow
derived classes to be used. Which is good.

However, you are very correct Pedro that mostly people are likely to
want to derive from classes such as wxFrame, wxDialog and wxPanel. I
think it makes sense to create those classes for our users so that
they can use those in as few lines of code as possible. So what I
would propose is that for this release we attempt to not add or remove
anything from the API and just stick with an example that  works with
what we've got. Then after this release we can add non-template
classes for wxFrame, wxDialog and wxPanel which can be used really
easily by our users and we have time to test them and make sure the
API for their use is stable before the next release.

Does that seem sensible?

So I have just committed the changes I mentioned above. Pedro and
Alan, if you have time to test them on your Linux systems that would
be good. I've tested on my Windows system and I'm about to do so on my
Linux system too.

Phil

--
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