Re: [Plplot-devel] Your development plans for this release cycle

[Phil R. <p.d...@gm...>]

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...@be...> 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
> __________________________