Re: gnuplot projects, terminal modules

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

On Thursday 08 March 2007 04:53, Timoth=E9e Lecomte wrote:
> Dear gnuplot enthusiasts,
>=20
> Since 4.2 is out, I would like to start discussing some things I have in
> mind for 4.3/4.4.

My list (in no particular order):

1) Continued work on internationalization
	- better use and documentation of LOCALE settings
	- support UTF-8 in as many terminal types as possible
	- better mechanism for integrating and maintaining localized documentation

2) Transparency
	- mostly done, but needs to be implemented in win, aqua, [others?]

3) Mousing support for SVG

4) Mousing support for multiplot mode

5) generate and plot 3D isosurface from 4D data
   color-mapping a 5th value onto that surface gets us up to 5D data
	- splot "4D-data" using 1:2:3:4 with isosurface at <value>
	- splot "5D-data" using 1:2:3:4:5 with isosurface at <value>

Other projects that I'd like to see done, but I'm not the best person to
evaluate or coordinate it:

1) Updates to the "fit" subsystem
	-  1294507    Fitting using CERN Minuit routines
	-  1445064    Gnuplot fitting improvements

2) Fix up the "history" command (Dan Sebald was working on this)

> First, I'd like to see the terminal module architecture that I proposed as
> a patch in sourceforge to settle:
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D302055&aid=3D157144=
3&group_id=3D2055

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.

> 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
>=20
> 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.

> And in plugin2.diff, I move the ugly terminal-specific code in
> raise_lower_command() (command.c) to where it belongs, in the terminals.
> This is done by introducing:
>=20
> 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 command
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.

> the patch "[ 1474309 ] Bind <space> to builtin_raise in mouse.c". Instead
> of moving the "raise console" code into the core, it could be moved to a
> dummy terminal (like estimate.trm), which would be built as a module.
> Voil=E0! No more code duplication without adding a Xlib dependency on the
> core !

But that isn't going to make it any easier to figure how to do it in the
first place.  Also, does this mean you are thinking that one
terminal driver would call into another terminal driver?  Or is this
an alternative to the term->inter->raise_term_window() mechanism you
just mentioned above?

> What are my other short-term projects ?
> - commit the cairopdf terminal, eventually replacing the current pdf
> terminal. It is really working nicely.

Absolutely.  This will be really great.  The main hangup is the same
as for the initial wxt terminal introduction - it isn't straightforward
to build it on most machines yet, because the cairo library requirement
is too bleeding edge.  But that's not a problem in the longer term.

> Another interesting comment was the lack of
> a powerful and broadly available (i.e. for many languages) plotting
> library.=20

There's a reason for that.  Such libraries are not very useful,
and tend to die a lingering death from lack of users.
Additional comments in a separate post.

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742