Re: Interactive terminals : behaviour on window resizing

[<tim...@en...>]

[cc-ing to the mailing list, to keep the thread consistent]

> Timoth=E9e Lecomte wrote:
>> I would like to discuss what is the expected behaviour of the
>> interactive
>> terminals when the user resizes the windows.
>
> I don't think there is any formalized expectation beyond "try to make a=
s
> much sense as possible".

Sure, I completely agree !

>
>> The X11 terminal is resizing the plot by scaling everything on it exce=
pt
>> the font size and the linewidths. Thus, if the user makes the window
>> smaller, ticks labels may overlap, the plot box gets closer to the
>> window's edges and may overlap the labels, etc.
>> If another plot command is issued, the ratio is kept, so that the
>> position
>> of the box doesn't change for example.
>
> I'm not quite sure which "ratio" you're referring to there.

I mean the global aspect of the plot (box position, overlapping if any
because of the rescaling), as opposed to the situation described just
below.

>
>> If 'set term x11; replot' is issued, the window size seems to be probe=
d,
>
> Yes.  There's a back channel from gnuplot_x11 to gnuplot (the same one
> usually used for mouse interaction) which is used to inform the core
> about the actual geometry of the plot.  IIRC, it's supposed to used not
> only if you 'set term x11', but actually on each new plot.

At least for me with a CVS version picked up one month ago, the new windo=
w
size is taken into account when you do 'set term x11', but not for a
simple new plot.

>
>> The Windows terminal behaves similarly, except that term->xmax and
>> term->ymax seem to be stored at once on startup only, so that 'set ter=
m
>> win; replot' won't change the layout of the plot at all.
>
> Win.trm's internal coordinates have no relation to the GUI window's
> size.  The transformation between these artificial coordinates and
> screen pixels is handled by the graphical output layer.

Ok, thanks for the details.


>> I can imagine two other possibilites for the plot behavior when the us=
er
>> changes the window's size :
>>
>>   1) really scale everything - including the font size
>
> That would be manifestly wrong.  Font size is specified by the user, an=
d
> it's absolute.  It's not supposed to change just because you changed th=
e
> size of the plot.

You're right.
At least, thinking of it as a value relative to the window size leads to
inconsistencies when gnuplot's core is informed of a new geometry for a
new plot.

>
>>   2) don't scale anything and just display the plot centered in the
>> window
>> if it is smaller than the window, and if it is bigger add scrollbars o=
n
>> the edges of the window.
>
> Seems like you're missing the most obvious possibility:
>
> 3) Leave it to the core engine to re-layout the entire plot for the new
> window size, i.e. automatically trigger a "replot".
>
> The reason we're not doing that is that it's not always (easily)
> possible, because of 'multiplot' and because data may no longer be
> available.

That is the underlying problem (I experienced it, and I aknowledged it at
the end of my first message).


>> The second solution (don't scale anything) has the advantage to be
>> faster,
>> as it has basically no complex operation at all to be done when the
>> window's size changes.
>
> And it has the major disadvantage that if the user makes the window
> smaller than it originally was, part of the plot will now be invisible.

Yes, but as mentioned in my reply to Ethan's message, it's the way most
other applications work. I am not saying it is the optimal solution, but
it may be better that the current one.

For my wxt terminal, it would just imply (for example) a new button 'fit
to window' that the user would have to click on to inform gnuplot of the
new geometry.


> Ultimately, if the plot is a multiplot, *nothing* can really be done
> that would get us a sensible plot that doesn't explicitly violate at
> least some of the explicit or implicit requests issued by the user.
> Either the font size will be wrong, or the layout will no longer be
> adjusted to the font size, or the layout will be fundamentally differen=
t
> from what size, origin and margin were set to.
>
> For short, it's generally an impossible mission.  "replot" is correct i=
f
> it can be done --- but sometimes it just isn't.

Agreed. So a long-run goal could be to rework this.