Re: gnuplot projects, terminal modules

[Ethan M. <merritt@u.washington.edu>]

On Thursday 08 March 2007 14:35, Timoth=E9e Lecomte wrote:
> > 4) Mousing support for multiplot mode
>=20
> This one is probably more difficult than it seems.

At least in x11 it should not be fairly easy. Gnuplot_x11 already
stores plot bounds and axis scaling information, used to echo back
the mouse coordinates based on the current cursor coordinates in
the window.  To make mouse coordinates work for multiplot, one just
needs a  pre-test on the cursor coordinates to see which scaling
table should be used.  So I think echoing the appropriate mouse
coordinates for various subplots on the screen would be easy.
The difficult part would be to do something like zooming a subplot;
as currently implemented, that would require going back to the
original plot command and the original data, both of which are
long gone.  =20

On the other hand, you may get zooming for free in svg, because the
viewer handles it. ... assuming that we get mousing to work in
svg at all.

But I really have not looked at the mousing code of the other
mousing terminals, so I can't say whether the x11 solution applies
to them as well.  =20


> >> First, I'd like to see the terminal module architecture that I proposed
> >
> > Is there any technical benefit to this work?
> > I have the impression, perhaps incorrect, that it is being entirely
> > driven by distaste for linking to libreadline.
>=20
> This has nothing to do with readline, it's for the _terminal_, like wxt or
> gd, to be built as external modules and to be loaded at run-time.

Ah. Light dawns. I totally mis-understood.  Sorry.
OK, I'll have a look at it.


> >> What I implement in the plugin1.diff and plugin2.diff is the an
> >> in-between
> >> interactive structure:
> >> term->inter->waitforinput
> >> term->inter->put_tmptext
> >> term->inter->set_ruler
> >> term->inter->set_cursor
> >> term->inter->set_clipboard
> >>
> >> so that non-interactive terminals just have term->inter =3D 0, making =
it
> >> easier to extend the terminal API for interactive commands.
> >
> > Yes, that's a bit cleaner.
> > But it's not like we extend the terminal API every week.
>=20
> S you would suggest that I add term->raise_term_window directly in
> struct termentry ?

Not at all. I was just commenting that extending the terminal
API doesn't happen very often, so it doesn't seem like a high
priority to rearrange things to make it easier.  Nice, but not
high priority.

> term->inter->raise_term_window()

> > Please remind me where we ended up in previous discussions.
> > I thought this turned out to be something that cannot be done in the
> > terminal driver at all, because at the time you want to issue the comma=
nd
> > you may have a different terminal active.  I tried implementing it x11,
> > and what happened was the all the raise/lower events got queued up and
> > executed in a batch the next time an x11 window pipe was the active
> > input stream.  That's clearly no good.  I attempted to work around
> > this with a patch to continue accepting input from the previous
> > interactive terminal, but that didn't work very well either.
>=20
> You're mixing two opposite features:
> 1- 'raise console (xterm, konsole, ...)' which is bound to the spacebar in
> any interactive terminal. This cannot be moved as a function in struct
> termentry for the reason you just explained
> 2- I'm talking about 'raise terminal (wxt, x11, ...)' which is the 'raise'
> or 'lower' command (see 'help raise'). It makes sense to have act on the
> current active terminal, and to move the code to the terminal instead of
> command.c

No. I'm not talking about 'raise console' at all.  I don't care about
that, and would never use it :-)
I'm talking about the case where you have a dozen x11 windows on your screen
with old plots in them, and you want to raise plot #5, but don't remember
which window that is.  I gather from Petr's comments that this is typical
in an Octave session.  How do you send a "raise" command to an existing
x11 window when it's not the currently active terminal?  The current
terminal may still be x11, but a different window.  Even worse if the
current terminal is post or png or something like that.  I'm not saying
it's impossible, but my simple-minding attempt to do it inside the x11=20
driver didn't work.

=2D-=20
Ethan A Merritt