[Octave-bug-tracker] [bug #52184] 'position' axes property value is incorrect when using gnuplot toolkit

[Etienne Dechamps]

Follow-up Comment #6, bug #52184 (project octave):

> Nonetheless, there is no type of 'data'-relative specification. Why? I don't
know. It seems that would be useful thing to have. 

I wholeheartedly agree :) It would directly solve my original problem and
remove the need for that data_annotation() function that I tried to write.

> But I will point out that 'data' isn't probably the best nomenclature for
that because there can be multiple axes on a plot, so the question is what
"data" are we referring to if the axes are totally different scale and range?
So, rather than "data", maybe a type 'axes' makes more sense with some
reference to the axes object. 

Sure. Honestly, the function that I presented is just something I hacked
together in a few minutes so that I can get stuff done; I'm well aware it
would have problems with more... "exotic" plot types. If it were to be done
more seriously, it would certainly have to be made more generic and flexible
with regard to a variety of scenarios.

> It's already set for 'data', but as I see it, it's acting like "normalized"
in the plot. So, gnuplot toolkit has a 'data' units option, but it doesn't
seem to be working right now. 

Oh, interesting. Maybe I should file a separate bug to sort this stuff out.

> What's funny is that your fail-example can be made to work in gnuplot
toolkit with the following: 

Yep, that's the workaround I was referring to: explicitly overriding the
position, i.e. pulling gnuplot out of "auto" mode (or whatever it's called)
and specifying coordinates manually. You'll notice that as soon as you do that
then gnuplot is not "smart" when it comes to the use of canvas space - when
left to its own devices it will fill out as much as the figure space as
possible, but that stops as soon as you specify a position manually.

> Anyway, let me know your thoughts on the annotation specification relative
to an "axes". Such an internal code addition seems the easiest route to me,
i.e., all toolkits have the property. 

A thousand times yes, that would make my life so much easier. (I know from
experience that this is something that gnuplot supports when operating gnuplot
directly, by the way.) 

> It seems the bug here is simply that you want the gnuplot plot box position
to look similar to the smaller width/height of the FLTK and Qt plots.
Correct?

Well, no. gnuplot's behavior with respect to where it draws the axes is
perfectly fine and it does an excellent job at using all the available space
when left to figure this stuff out on its own. I do not want to change that.

What I would have liked is for the 'position' property of the axes to give a
correct answer when using gnuplot, even when it is not set explicitly. But it
looks like that's not going to happen.

> There's no way to modify gnuplot manually within the plot and feed back
coordinates to the toolkit.

I'm not sure I understand what you mean by that.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52184>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/