On 2010-09-28 08:24-0400 Hezekiah M. Carty wrote: >>> 2) A different, but related, issue is colourbars for colour contour >>> plots. Support for this would also be good. >> >> I think a separate plcolorbar API for that capability should be worked >> on post-release. >> > > I'm not sure I'm following this portion of the API correctly - does > pllegend support some of this already? It looks like cmap0_colors, > cmap1_colors, cmap_patterns and cmap_scales are meant to support > something along these lines. If that is the case, then I still think > that these would fit better in the plcolorbar API. > > Or, as I'm starting to suspect, if provided, would each entry draw a > single block of a given color + pattern? If this is the case then I > think keeping this in pllegend seems reasonable. It would be nice to > have these options used in an example.
Yes a single discrete color block (of variable vertical size so the blocks can be separate or just touch or even overlap) per legend entry. So I think this API encompasses what you already do with your discrete color bar, but definitely not what you do with your continuous color bar. Separating out this discrete color block API into a separate function makes little sense to me because many of the calculations and a lot of the functionality are common with the lines and/or symbols functionality. In sum, the way I think of this is that pllegend is our discrete legend API, while plcolorbar will be our continuous legend API. For now you can easily try out this color block functionality in example 4. It's all set up. All you have to do is fiddle with the opt_array options. > >>> >>> 3) I'm not quite sure from the examples or what you have said whether >>> a legend outside the plot is possible, but I certainly think it >>> should be. >> >> Yes, that capability is available now. In fact, the legend x,y >> position and plot_width are now expressed in normalized sub-page >> coordinates rather than normalized viewport coordinates as before. >> > > Sounds good to me! > >>> >>> Overall I think the current API is probably fit for most uses. >> >> Thanks for your review. >> > > While I agree with this, I do think it is worth leaving the pllegend > API flexible through the post-5.9.7 development cycle. I like the API > overall, but given how high-level this function is compared to most of > PLplot's C API I think extra time to try out pllegend before > committing to the current API would be useful. > > I will try to get the OCaml pllegend binding working before the 5.9.7 > release for testing. I would rather have to change the binding than > realize a month later that we are missing some key functionality (like > the missing rotation support in plarc!). Good point. So I suggest (to answer Arjen's question as well) we postpone pllegend propagation to other languages or examples until after the 5.9.7 release except possibly to OCaml and/or octave to compare with existing legend capabilities for those two languages. Ideally, (once I answer your further posted questions about API specifics) we will have finalized the pllegend API before 5.9.7, but if we have to make changes later after some further experience, I am open to that as well so long as that is accompanied by the appropriate SOVERSION bump to libplplotd to force users to recompile and also an API change warning in the release notes. By the way, I think that is the approach we should take with further plarc rotation changes as well after 5.9.7 is released. After all, a plarc API change won't affect that many users since it is relatively new functionality. The only real difference with some hypothetical pllegend API change post 5.9.7 is in the former case there is extra work to do because we would have to tweak all plarc functionality in languages and examples, but in the latter case we are holding back on doing language propagation (see above remarks) to avoid that work if there is an additional API change for pllegend. I hasten to add I don't think any plarc rotation API change should be done _before_ the 5.9.7 release because we are too close to that release to insure there are no screwups in the required dependent propagation changes. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
