Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2005-07-18 12:32:00
|
By default, all mouseable interactive terminals switch on mouse by default, and do it also when driven via pipe (OS/2, Windows, ...). The only exception is the X11 terminal when gnuplot runs in pipe. Thus, it is not compatible to other defaults. "help mouse x11" writes: X11 mouse support is turned on by default if standard input comes from a terminal (tty). Mouse support is turned off if standard input does not come from a tty, e.g. a pipe. If you want to use mouse support while writing to gnuplot from a pipe, the mouse must be turned on *before* starting the x11 driver, e.g. immediately after startup with the explicit command `set mouse`. Does somebody remember why gnuplot-x11 behaves like that? I think this is a relict nowadays. I propose to switch on mouse also for this combination. That would make many people happy and gnuplot behaviour compatible. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-18 19:48:56
|
On Monday 18 July 2005 05:31 am, Petr Mikulik wrote: > By default, all mouseable interactive terminals switch on mouse by default, > and do it also when driven via pipe (OS/2, Windows, ...). The only exception > is the X11 terminal when gnuplot runs in pipe. Are there any mousable terminals other than those three? > I propose to switch on mouse also for this combination. > That would make many people happy and gnuplot behaviour compatible. I do not know the history of this choice, but changing to a default of "on" would be OK by me. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-07-20 12:24:16
|
>> and do it also when driven via pipe (OS/2, Windows, ...). The only exception >> is the X11 terminal when gnuplot runs in pipe. > > Are there any mousable terminals other than those three? ggi (I never tried) I wonder that Aqua does not have mousing capability. >> I propose to switch on mouse also for this combination. >> That would make many people happy and gnuplot behaviour compatible. > > I do not know the history of this choice, but changing to a default of > "on" would be OK by me. Let's do it. Would it be sufficient to remove "mouse_setting.on || " from below or something more is necessary? #define X11_ALLOW_EVENTS (mouse_setting.on || isatty_state) --- PM |
|
From: Petr M. <mi...@ph...> - 2005-07-29 08:47:34
|
>>> I propose to switch on mouse also for this combination.
>>> That would make many people happy and gnuplot behaviour compatible.
It looks that with this this removal from plot.c
#ifdef PIPE_IPC
/* isatty_state is set here and nowhere else! (used in term/x11.trm) */
isatty_state = interactive;
if (!isatty_state) {
/* stdin is not from a tty --> Turn mouse off.
* can be turned on again, e.g. if the user
* wants to write on a pipe to gnuplot */
mouse_setting.on = 0;
}
#endif
I can also remove all other occurencies of the variable "isatty_state" which
is not used for any other purpose.
---
PM
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-29 11:47:34
|
Petr Mikulik wrote:
> It looks that with this this removal from plot.c
>
> #ifdef PIPE_IPC
> /* isatty_state is set here and nowhere else! (used in term/x11.trm) */
> isatty_state = interactive;
> if (!isatty_state) {
> /* stdin is not from a tty --> Turn mouse off.
> * can be turned on again, e.g. if the user
> * wants to write on a pipe to gnuplot */
> mouse_setting.on = 0;
> }
> #endif
>
> I can also remove all other occurencies of the variable "isatty_state"
Then you didn't look very close, or you're silently assuming the context
of an already modified source tree. The primary user of this variable
is x11.trm, in the shape of macro X11_ALLOW_EVENTS. At least, it still
was in the CVS source as of yesterday.
|
|
From: Petr M. <mi...@ph...> - 2005-07-29 11:54:59
Attachments:
no-isatty_state.diff
|
>> It looks that with this this removal from plot.c
>>
>> #ifdef PIPE_IPC
>> /* isatty_state is set here and nowhere else! (used in term/x11.trm) */
>> isatty_state = interactive;
>> if (!isatty_state) {
>> /* stdin is not from a tty --> Turn mouse off.
>> * can be turned on again, e.g. if the user
>> * wants to write on a pipe to gnuplot */
>> mouse_setting.on = 0;
>> }
>> #endif
>>
>> I can also remove all other occurencies of the variable "isatty_state"
>
> Then you didn't look very close, or you're silently assuming the context of
> an already modified source tree. The primary user of this variable is
> x11.trm, in the shape of macro X11_ALLOW_EVENTS. At least, it still was in
> the CVS source as of yesterday.
I did, but I didn't want to enclose the full patch. That variable is used
only if set in the above code in plot.c to be removed.
I enclose the complete patch.
---
PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-29 20:10:12
|
On Friday 29 July 2005 04:54 am, Petr Mikulik wrote:
> >> It looks that with this this removal from plot.c
> >>
> >> #ifdef PIPE_IPC
> >> /* isatty_state is set here and nowhere else! (used in term/x11.trm) */
> >> isatty_state = interactive;
> >> if (!isatty_state) {
> >> /* stdin is not from a tty --> Turn mouse off.
> >> * can be turned on again, e.g. if the user
> >> * wants to write on a pipe to gnuplot */
> >> mouse_setting.on = 0;
> >> }
> >> #endif
> >>
> >> I can also remove all other occurencies of the variable "isatty_state"
That looks correct to me.
[it doesn't matter now, but...]
The original logic of having a global variable "isatty_state" escapes me.
There was already a global "interactive", and the only initialization of
isatty_state is the one shown above. I fail to see how having two
globals is an improvement over just using the one that was there already.
If we get rid of isatty_state in x11.trm, then the only two remaining
drivers that refer to the global "interactive" flag are
post.trm:
if ((lf && lf->interactive) || interactive)
PS_load_fontfile(new_ps_fontfile,FALSE);
amiga.trm:
doesn't do anything in term->text or term->suspend
if (!interactive)
The postscript use looks dubious to me. Why would we not want to
load a font file in non-interactive mode?
(Harald, do you remember this?)
The amiga code we can do away with by dropping amiga support :-)
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
