Hi Hazen This seems like a good plan to me. I agree with most things. To me the core role of plplot is to take "plot instructions" and convert them to "drawing instructions" for whichever device we are rendering to. I have found rewriting the wxWidgets driver challenging as there are a lot of things that I just didn't realise PLplot did. I still won't pretend to full understand the aspect ratio code properly. I feel I think like you that many of the interactive features such as mouse input capture are better done by the calling application, rather than by PLplot. However I also feel that it is potentially quite useful for someone who doesn't want to learn the intricacies of GUI programming to be able to write a console application which will display plots.
I guess this mentality is where I am trying to take the wxWidgets driver. Now the plplot library for wxWidgets works in two modes. The first is that in a native wxWidgets application PLplot is given a canvas and draws on it. This works essentially the same as any non-interactive driver, where we pass in a file name rather than a canvas. In the second mode, if the calling application doesn't have a canvas to pass in (e.g. a console application) then PLplot stores all the commands in a the buffer then sends them to a totally separate application to render. This means that PLplot contains no message loop code or any of those complexities. The core code just draws stuff. But then we add on the other interactive functionality and it becomes more complex. But that was my ethos anyway. But yes I think that you are probably correct that a discussion about what PLplot should and should not do and an opportunity to introduce these backwards incompatible changes would be good. I would also like to add thread safety to the list of things we should consider if we are looking at restructuring the library. Phil On 20 March 2015 at 12:46, Hazen Babcock <hbabc...@mac.com> wrote: > > Hello, > > Since we are considering a number of changes, such as fixing error > handling, that would break backwards compatibility anyway I propose that > we think a bit about all the other things that we might like to change, > perhaps bringing us to version 6 of PLplot. So, my proposals in no > particular order: > > 1. Error handling as has been previously discussed on the list. I > believe that the standard these days is that the return value of all the > API functions is either success or some sort of error code. API > functions that used to return a value would be changed to pass values > back via a pointer based mechanism. > > 2. "Do one thing and do it well". PLplot has grown somewhat organically > over the years and now might be a good time to consider what exactly is > core (which I think of as just plotting), and what might be better off > outside of PLplot. This would not necessarily mean just deleting things > as non-core functionality could instead be moved to auxiliary libraries. > Two examples: > > A. Consider removing the non-plotting related functions from the core > API. For example, PLplot includes it's own random number generator. I > know we use this for testing the examples, but this random number > generator could be moved into a separate auxiliary library that is just > used for the examples? Another example is that PLplot includes routines > for command line input of integers and floats. We should take a hard > look at what is in the API and decide what is truly plotting related and > what is not. > > B. No interactive drivers. I'm not proposing that we just delete them, I > just feel that the structure is wrong. For example, I think Phil was > struggling with this a lot when he was working on the wxwidgets driver. > Things might work better if the "interactive drivers" were instead > standalone libraries that use PLplot to do graphing, rather than built > into PLplot core. This way they would also serve as examples of how to > integrate PLplot into one's own applications, and they could be made > considerably nicer (with menus, etc.) without effecting PLplot core at > all. The interactive demos (and other programs that wanted to use them) > would work by starting the appropriate driver, getting the appropriate > context from the driver, passing this to PLplot to do the plotting, then > return control to the driver for interaction, in a fashion similar to > the way our current ext drivers work. One downside would be that we > might have to separate the interactive examples from the non-interactive > examples as they would now work fundamentally differently. Integration > into environments like octave would also involve some extra steps, you'd > now have to start your interactive environment of choice, get a plotting > context and pass this to PLplot for plotting. > > 4. Use floating point coordinates for drawing operations. I think this > would simplify things somewhat, at least from a driver perspective as > there would be no need for the down-scaling that we are currently doing > to make nice plots with the more modern drivers. > > 5. Use a library (Freetype?) for rendering text instead of delegating > this to the driver? The driver would instead be responsible for the > display of the resulting bitmaps. This would finally solve the problem > of the text looking slightly different on all the drivers. It would also > make writing new drivers easier as text handling is far and away the > most difficult thing to implement correctly. Maybe this would not work > so well with pdf and postscript drivers, so we'd need to preserve the > driver rendered text option? > > 6. Change legend and colorbar API. Sensible defaults would be stored in > the plstream. You could change these defaults as desired with a few > different functions rather than rolling everything into a single > function. This would also make later changes to this part of the API > less disruptive. > > best, > -Hazen > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
