On Tue, Sep 28, 2010 at 1:00 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2010-09-28 08:24-0400 Hezekiah M. Carty wrote: > >> 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. >
This actually provides a different kind of functionality than what the OCaml colorbar support provides, so I'm glad you added it! The "discrete" characteristic I was referring to is meant as the difference between, for example, plimage (continuous color scale) and plshade (discrete color intervals). >> >> 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. > I agree. I'll try to get pllegend wrapped for OCaml before the 5.9.7 release, and I will wait on any plarc alterations until after the release. Hez ------------------------------------------------------------------------------ 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
