Re: gnuplot projects, terminal modules

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

 On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
>> 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.
>
> My list (in no particular order):

Thanks for participating in the discussion !


>
> 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

One interesting quote from Lars's list in the TODO file:

"- better documentation format; get rid of the doc2xxx utils
  [SGML. SGML. SGML]"

Maybe localization could be an additional motivation for this.


>
> 2) Transparency
> 	- mostly done, but needs to be implemented in win, aqua, [others?]
>
> 3) Mousing support for SVG
>
> 4) Mousing support for multiplot mode

This one is probably more difficult than it seems.


<...>


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

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. I
understood that some people were not liking to have the core have many
dependencies, so that's a way to overcome that. It may make
packagers/distributions' life easier too.

>
>> 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.
>
> Yes, that's a bit cleaner.
> But it's not like we extend the terminal API every week.

S you would suggest that I add term->raise_term_window directly in
struct termentry ?

In that case, my point is that:
- if I add it to the bottom, then it's one more #ifdef USE_MOUSE
- if I add it inside the current #ifdef USE_MOUSE, I have to add one '0'
manually to all drivers


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

You're miwing 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

>
>> 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 !
>
> 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?

So, that's point 1 in the above enumeration. It is not terminal-specific,
so it shouldn't be in the terminal code as it is now. The problem is that
it can only be done by linking to Xlib (from a Unix environment, of
course), and it was objected that we don't want to add a dependency on
Xlib to the core.


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

Right. I plan to commit it soon, just after a couple a cleanups here and
there.


>> Another interesting comment was the lack of
>> a powerful and broadly available (i.e. for many languages) plotting
>> library.
>
> 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.

Ok, let's discuss it in the separate post.

Thank you again for your comments.

Timothée

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