Re: Interactive terminals : behaviour on window resizing

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

> Timoth=E9e Lecomte wrote:
> [Don't rescale anything.]
>
>> Yes, but as mentioned in my reply to Ethan's message, it's the way mos=
t
>> other applications work.
>
> We have to be careful what kind of applications we compare to, here.
> There are two major classes.   One class holds those apps where the GUI
> window is just a peep-hole through which you look at a small part of a
> much large document: a "viewport".  This is the case for all text
> processors, spreadsheets, and lots of others.  Here, zooming and GUI
> window resizing can be (and usually are) treated as separate user
> commands.
>
> The other class of applications have GUI windows that *by definition*
> show their content in its entirety.  Media players and all kinds of use=
r
> interface dialogs, e.g. In such programs, a resize of the window
> forcibly triggers a redraw from scratch, often with a re-layout.

I had forgotten the media players and similar applications. You're right,
gnuplot belongs to this category.


> Some apps are mixtures between these two basic cases.  E.g. in a web
> browser, vertical resize will just show you more of the page, but
> horizontal resize triggers redraw and changes the layout.  Acroread
> changes behaviour depending on which "zoom" mode you selected.
>
> The problem we're facing with gnuplot is that we're firmly in the secon=
d
> category: we have a 1:1 relationship between the GUI window and the plo=
t
> that's shown in it.   So we never actually zoom into the graphic, but w=
e
> re-do the plot.  Except in those cases where we can't.  Then we just
> have to decide among several equally bad alternatives.
>
> Particularly in case of a multiplot, I don't think there's *anything*
> useful that can be done.  So we could
>
> 1) bluntly refuse to resize the GUI window --- just inform the GUI that
> this window is non-resizable until further notice
>
> 2) allow resize, but don't try to redraw --- just blank the window.
>
> 3) do what we do now: i.e. replay the series of term API operations
> stored by the GUI window handler, with re-mapped coordinates.
>
> 4) (only for non-multiplots, may need mousing turned on): send a
> 'replot' command back to gnuplot through the mouse command channel
>
>> For my wxt terminal, it would just imply (for example) a new button 'f=
it
>> to window' that the user would have to click on to inform gnuplot of t=
he
>> new geometry.
>
> We don't need such a button.  That must the one-and-only behaviour.
> Zooming into a plot such that only part of it is visible is just
> useless.  A plot only makes sense if you can see all of it.
>

I like the idea to do 'replot' automatically whenever it's possible, and
to handle multiplot (and other possible problematic situations)
separately.

Then, for the multiplot case, the option 3 which corresponds to the
current situation is probably the best. However, remains here the questio=
n
of the way the coordinates are remapped. My proposal is to scale
everything in the plot (including font size and linewidths) with the
window size, and to keep the global 1:1 aspect ratio by leaving blanks on
the top+bottom or left+right of the plot.

In practise, it would probably imply a new mousing command like
'GE_sizechanged' which would either do 'replot' if it is possible or fall
back to a new terminal routine 'term->scale()'.

Timoth=E9e