gnuplot projects, terminal modules

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

Dear gnuplot enthusiasts,

Since 4.2 is out, I would like to start discussing some things I have in
mind for 4.3/4.4.

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=detail&atid=302055&aid=1571443&group_id=2055

There is a preliminary step chich is the acceptance of the first two
patches (plugin1.diff and plugin2.diff) which rework the interactive
commands of the terminal structure in order to make it more extensible.

Currently, we have:
term->waitforinput
term->put_tmptext
term->set_ruler
term->set_cursor
term->set_clipboard

This is a nice interface for mousing-related commands, but as it was
pointed out earlier, it is not easily extensible to new commands, since
new entries have to be addded at the end of the term structure, and this
can painful to maintain with the large amount of terminals that we have.
Petr (if I remember correctly) proposed to add something like:

term->interactive("some command")

and it was objected that it adds another parsing layer...

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 = 0, making it
easier to extend the terminal API for interactive commands.

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:

term->inter->raise_term_window

I'd really like to commit this code, not to have to maintain it for too long.

Then there is the modular terminal architecture that may deserve some more
discussion. It's implemented in plugin5.diff and I'd be pleased to listen
to your comments. See the patch page for details.


What are my other short-term projects ?
- commit the cairopdf terminal, eventually replacing the current pdf
terminal. It is really working nicely.
- after the modular terminal architecture has settled, I'd like to finish
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à! No more code duplication without adding a Xlib dependency on the
core !

What are my long-term projects ?
In a release article for 4.2 that was published in a french web site
(http://linuxfr.org/2007/03/07/22168.html), the most frequent comment was
that a GUI would be appreciated as an alternative to the
script/command-line interface. Another interesting comment was the lack of
a powerful and broadly available (i.e. for many languages) plotting
library. I think gnuplot could be modified to achieve this goals if its
parser was written as a layer above a real API. It looks like it is what
can be found in the TODO file:

"longer term

- break it into four layers:
  : low level graphics  (some of term.c)
  : plotting code, reading the setshow.h global variables
  : parsing code - read a string, and parse and execute it
  : front end, interact with terminal / gui"

So, I think I'll try to work on this. I have a couple of milestones in
mind, starting from the rewrite of the term->options functions so that the
parser is not called from the terminals. Then maybe extract an API for the
set/show functions to separate them from the parsing code.

Well, that's it. Don't forget to comment on the modular architecture, and
thanks for reading.

Best regards,

Timothée