Hi Hez:
A further IMPORTANT question: I have just been taking a look at the
plcolorbar implementation in the swig-related languages and I have a
question about the new arguments you introduced in revision 12235,
which are currently typed const char *labels[] and const char
*axis_opts[]. I would like to keep the proliferation of types to be
as narrow as possible for the PLplot API. For similar purposes
(passing an array of pointers to strings) and after considerable
discussion on list, we decided to use the type const char * const *
for the appropriate pllegend arguments. So would you be willing to go
along with that type in this case as well, i.e.,
const char * const *labels and
const char * const *axis_opts?
If so it makes _all_ language bindings of plcolorbar and associated
use of plcolorbar trivial to implement since developers can just copy
how they interfaced the array of pointers to strings arguments from
pllegend to plcolorbar. Of course, this proposed API change also
implies C and (presumably) OCaml changes, but I will handle the C
changes if you will take responsibility for the OCaml ones.
More below in the context of your answers to my previous questions.
On 2013-05-01 06:09-0400 Hezekiah M. Carty wrote:
> On Wed, May 1, 2013 at 1:34 AM, Alan W. Irwin
> wrote:
>> These are important questions which I hope both Andrew and Hez will
>> answer to the best of their knowledge.
>>
>> What is the status of plcolorbar? Has that API been finalized?
>>
>
> I'd like some feedback before saying it's finalized. I have used
> plcolorbar a lot (through the OCaml bindings) and have been pretty
> happy with it. There at least one addition which I think would be
> useful but I don't know if it is worth adding:
>
> We could add displacement, position and justification options for axis
> labels such as what is available when using plmtex directly. This is
> useful, for example, if you have two different unit systems labeled on
> each vertical axis on a vertically oriented color bar. A work-around
> is available with the current interface if you use a single label and
> manually adjust the text to be centered appropriately around the bar.
> One option is to add the parameters now (a few additional PLFLT
> arrays) so you can do your binding propagation work. The
> implementation of the feature in the C plcolorbar code could be
> carried out separately from the API propagation.
I don't have a lot of complex plcolorbar needs in my research, but it
does sound like the further API change that you propose would be
useful to you and others with more complex plcolorbar needs. So I
suggest you just go ahead and make the change. We are still
officially in the experimental stage for the plcolorbar functionality
and API so let's take advantage of that grace period and make sure the
API is right rather than having to change the API later with all the
backwards incompatiblity issues that are raised by that.
Furthermore, I suggest you do the plcolorbar implementation and API
changes simultanously since experience shows it is hard to
anticipate all API needs until you actually have some working code to
test. If your time constraints allow it, it would be ideal if you
could finish off this last implementation and API change to plcolorbar
in the next few days.
>
>> If finalized, what further changes (if any) do you propose for C
>> examples 16 and 33? My impression is 16 is done, and 33 just needs
>> one change so that the plcolorbar part of it is changed from optional
>> execution to always executed. If you confirm my impression, please
>> commit that one C example 33 change so it can be propagated
>> to the rest of the languages.
>>
>
> I think C example 16 is fine the way it is.
I agree.
> C example 33 with the colorbar option enabled is very verbose. I'm ok
> with leaving that verbosity in place but it would leave a huge number
> of pages in that example. Again, I would like feedback regarding
> whether the number of cases covered in this example (which still
> doesn't show all of what plcolorbar can do!) is reasonable.
No question, there are a lot of pages there, but as you say there is a
lot of plcolorbar functionality to test/demonstrate. Having an
incomplete example is bad because that means some of the plcolorbar
API will be untested not only in C but when the example is propagated
to other languages. Therefore, I encourage you to add more pages to C
example 33 until you feel it is a good, comprehensive test of the
plcolorbar API. Also, it appears to me we are currently testing most
of the optional plcolorbar functionality for that example with rather
compact code so despite the large number of pages being generated by
that compact code, I think the propagation efforts will actually not
require an onerous amount of editing work for the various example 33
implementations.
Giving what you had said about the status of plcolorbar and associated
examples, I will immediately concentrate today on propagat
