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
