RE map0 vs. 1, with the understanding that I have no idea what I am talking about, the maps are global, right? Could the answer be to pass a function pointer instead of the array? That would get around the void pointer because the common denominator would instead be a function that translates colors, not the colors themselves. There would hopefully be only two of them that are part of the library and hide any details.
Sorry if that's missing the point(er). Bill -----Original Message----- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Tuesday, September 28, 2010 1:03 PM To: Hezekiah M. Carty Cc: PLplot development list Subject: Re: [Plplot-devel] Volunteer requested to implement legend-drawing capability for the PLplot core library. On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote: > On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin > <ir...@beluga.phys.uvic.ca> wrote: >> On 2010-09-25 15:32-0700 Alan W. Irwin wrote: >>> and then move on to designing and >>> implementing the cmap1 part of that API (after reviewing your ideas >>> on >>> that) by early next week assuming it fits in nicely with pllegend. >> >> I plan to start on the cmap1 part tomorrow (Sunday). I feel >> confident the end result will be a powerful legend capability for >> PLplot that should satisfy virtually everybody's legend needs. >> > > Aside from the question about the cmap[01]_colors, cmap_patterns, > cmap_scales questions I brought up in the 5.9.7 release thread, my > main concerns come down to types: > > 1. text_justification is defined as a PLINT, but from the doxygen > documentation it looks like it should be a PLFT. Good catch! Fixed as of revision 11230. > 2. With support for cmap1 elsewhere in pllegend, would it be > reasonable to add support for cmap1 line and symbol colors? Yes. > Do people > generally use cmap1 for line or symbol plots? I think we only have one instance of that in our examples so users may not have picked up on this possibility, but it has long been the case that plcol0 and plcol1 could be used interchangably so perhaps we should arrange that for pllegend as well. To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt flag is set, _all_ color indices are interpreted as PLFLT cmap1 values in the range from 0. to 1., but otherwise they are interpreted as PLINT cmap0 index values. One potential downside to having cmap0 and cmap1 alternatives for all colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 arguments such as the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments. Could we just use generic pointer (void *) arguments to stand in for either kind of cmap index/value to halve the number of color arguments? I have very little experience with using void *, so if you think this idea would work, could you illustrate what to do with a commit that replaces the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer argument? Then I could propagate that idea to all our other color arguments, e.g., bg_color, text_colors, line_colors, symbol_colors (which are currently restricted to just cmap0). Are there any downsides to using generic pointers for something like this? For example, will such pointers make it difficult to propagate pllegend to some of our languages? Whatever we decide to do here, I think we should be consistent. So if you don't think it is a good idea to provide both cmap0 and cmap1 alternatives for all colour arguments (through generic pointers), then I think we should probably consistently use cmap0 arguments for all colors, i.e., drop the PLFLT * cmap1_colors argument and replace the current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with PL_LEGEND_DISCRETE_COLOR. > 3. In the 5.9.7 release thread you mentioned the ability to skip > entries when using pllegend interactively. Could this be specified > explicitly? Should there be a PL_LEGEND_NONE option defined (= 0 I > think) for opt_array? This isn't strictly necessary as passing 0 > would do the same thing, but it would make the intent of code using > this skipping functionality a bit easier to see. PL_LEGEND_NONE > wouldn't need a special case in the pllegend implementation, just a > #define along with the other PL_LEGEND_* options. Good catch. Fixed as of revision 11230. > > I like pllegend in its current state overall. I do, however, think > that it is worth encouraging the PLplot developers and interested > users to try out the pllegend API post-5.9.7 before we commit to > keeping the API as-is. In particular, some real-world use and a > plcolorbar implementation may expose other options we would like to > provide in pllegend. Agreed. (See my post in the 5.9.7 thread on this issue.) So it appears the only outstanding issue is issue 2, mentioned above. Your quick feedback on that (especially the generic pointer possibility to halve the colour arguments) would be much appreciated. 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 ------------------------------------------------------------------------------ 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
