Hi Alan So I think here are my priorities, in no particular order:
1) wxWidgets Docs - the driver doc is currently well out of date and the binding docs are non-existent. I have rewritten the driver docs and started on the bindings. As you said in your release notes the docs are probably still a weak point and I'm a firm believer that a library is only as good as it's documentation - clever features are no god if the users don't know they exist or how to use them. 2) The fill bug where the whole plot gets accidentally filled - I can't remember if that still exits or if a workaround fix was added. 3) I have on my old to do list something about the selectable region in x03.3 not being implemented. I should look at that. 4) Plexit. I agree this really needs sorting. However I found at least one side effect that we would need to deal with - I'll send another email out immediately after this one. 5) I'll add that incorrect background colour to my list. 6) I would like to add some useful additional features to the wxPLplotstream API that are particularly wxWidgets relevant. This would be some additional overloaded constructors and perhaps some features for plotting - for example it would be nice to be able to set the actual font face so that in a wxWidgets application a programmer could use a font dialog to ask the user which font they would like to use and then use it. This isn't currently possible at the moment where we just set the family. I think that's most of it. We will see how fast I can make progress. Phil On 30 January 2017 at 05:36, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > To Phil and Pedro: > > Now that 5.12.0 has been released, I am writing a series of posts to > our active developers with this subject line. > > If either of you has any additional wxwidgets development in mind beyond > what I > discuss below, please let me know. > > For this release cycle I encourage both of you to continue your > efforts to deal with obvious wxwidgets bugs (such as the unexpected > black rather than expected white background color for the first page > of example 16) to complement the work I plan to do deal with the last > of the wxwidgets device driver efficiency issues on Linux. Your goal > should be that each of our C examples with -dev wxwidgets should > produce exactly the same results (except possibly for text size) as > given at <http://plplot.sourceforge.net>/examples.php>. > > It would be great if one of you got the currently retired wxpng file > device going again as an aid for such comparisons with other > file-based plot results. But even better would be if you implemented > a wxwidgets-based SVG device (see > <https://wiki.wxwidgets.org/WxSVGFileDC>). The reason I particularly > mention SVG as a file format is the generated results are written in > XML and therefore are straightforward to interpret and debug by visual > comparison of that XML result with other SVG (from -dev svg, -dev > svgcairo, or -dev svgqt) results for the same standard example. > > @Phil: We were all agreed (see the February 2016 thread with the > subject line "Error report system plus thread safety" that our current > use of calls to exit() or the equivalent plexit whenever an error > condition was encountered was an important issue for our > users using interactive environments, i.e., one PLplot error ==> takes > down entire interactive work without giving the user a chance to save > anything ==> one less user interested in using PLplot! > > During that thread you were strongly recommending using a > setjmp()/longjmp() C-based exception model because you are very > comfortable with using exception handling in C++ and the amount of > editing required to implement it would be much smaller than the return > code method. Although Hazen had a substantially more cautious > attitude, I was happy to go along with that C exception approach > rather than the alternative return code method because of my knowledge > of the extreme length of many of our call/caller graphs and the large > amount of the work it would be for us to check _all_ calls of _all_ > PLplot functions within our C library code for invalid return codes. > > <aside > A google search for the search terms <c error handling longjmp setjmp> > gives lots of hits. Phil, I would appreciate you looking at the top > several and letting me know which you think is the best for learning > about exception handling in C. > </aside> > > The final upshot of that thread was you planned to make a proof of > concept for us to look at (and help you propagate it to everywhere > else in our C code during this release cycle if we liked that proof of > concept). Anyhow, could you please implement that proof of concept > now? > > > 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