On Monday, September 29, 2008 at 16:27:56 (-0400) Hezekiah M. Carty writes: > Would it be possible to add an internal function, not exposed in the > official API, which applies the transform itself, while keeping the > actual plsc->vpw* values unaltered from what the user provides? > > Looking through the src/ directory, all of the instances of vpwxmi, > vpwxma, vpwymi, vpwyma are values from plgvpw with the exception of > plwind.c, which is where they are set initially. I am not sure of the > proper naming convention, but perhaps a function named something like > plP_gvpw could be added to the internal PLplot API which adds the > offsets to the viewport limits, but leaves the internal representation > unchanged from what the user provides. Then this internal function > could continue to provide what plgvpw currently does, and plgvpw could > return the original user-provided limits. > > I have attached two potential patches to make such a change. They > both add a plP_gvpw function, exported through plplotP.h but not > plplot.h. The first (plP_gvpw-full.patch) replaces all internal > (src/*) calls to plgvpw with plP_gvpw. The second > (plP_gvpw-partial.patch) has the same content, except that the plgvpw > -> plP_gvpw replacement was only done in the label_box function in > plbox.c because that seems to be the only place where it is needed. > Only one of these patches should be applied if this proposal is > accepted. > > I am fairly certain that the above patches address all of the vpw* > variables in the PLplot source code. I looked at each occurrence of > vpwmi and they are all results of calls to plgvpw (or, after the above > patch(es), plP_gvpw). The function plgvpw is not used in any of the > examples. > > What do you think of this as a compromise? Nothing has to be > propagated to other language bindings, and the plgvpw functionality > becomes (I think) more intuitive.
I have to admit to being a little bothered by this change. The plP_gvpw private function is a good way to shield internal workings from this change, but begs the larger question: what should plgvpw() actually return? I can see three classes of opinion on the topic: 1. plgvpw() MUST return exactly what I specified in plwind() 2. plgvpw() MUST return exactly what the plot library's actually using 3. either is "good enough" There are good arguments for both 1 & 2. (2) is what we're using now, moving to (1) is the proposal. The people in category (1) could reverse the delta easily enough, as long as it was documented & didn't change. The people in category (2) could do the same, on old code that's long since been forgotten about. The vast majority in (3) will never notice. As a user, I'm in category (3), and don't *really* care either way. But be aware you are introducing a change that has the potential to change existing code behavior. -- Maurice LeBrun ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
