Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2006-04-14 13:45:49
|
Some ideas about "screen" terminals, for discussion: Users, scripts and driving programs have to take care where they are, and use "set term x11" or "set term windows" accordingly. The portable solution for "terminal recovery" is "set term pop". However, you cannot do "set term MY_OS_SCREEN 5". My reflections: - There is no advantage for users to have both wxt and x11, wxt and win in one gnuplot executable. - Executable called "wxgnuplot" would use wxterminal by default, all others the OS native (even when wx being compiled in). - When wx terminal is built-in, then x11 or win terminals are not compiled in, but their "set term ..." are redirected to wxt. Then, using "set term x11", "set term win", "set term wxt" does always the same thing whereever you run the given script. - There can be a unique dummy screen terminal name e.g. "set term screen" that "hides" these "set term some_OS_screen_terminal". - It is only the OS/2 gnuplot which can have both x11 and pm in simultaneously. However, wxt is not working there (or at least untested). Or some functionality like that. I hope you caught the point. Please think about it. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-14 15:26:12
|
On Friday 14 April 2006 06:45 am, Petr Mikulik wrote: > Some ideas about "screen" terminals, for discussion: > > Users, scripts and driving programs have to take care where they are, > and use "set term x11" or "set term windows" accordingly. If it is supposed to be a portable script, it should not assume anything about the local default terminal. That is what the environmental variable GNUTERM is for. I do take your point about about multiple numbered plot widows, though. So yes, perhaps "set term screen <num>", where "screen" is taken from GNUTERM, and <num> is ignored for terminals that don't support multiple windows. > - There is no advantage for users to have both wxt and x11, > wxt and win in one gnuplot executable. You can add aquaterm to that list. That may eventually be true, but we are not quite there yet. I'm a great fan of the new wxt terminal, and have been using it by default recently. But there are still some things that the x11 term can do that are not yet working in wxt, and I believe the same is true for the windows terminals (not sure, though, since I haven't tested a version with Bastian Maerkisch's new patches). > - Executable called "wxgnuplot" would use wxterminal by default, all others > the OS native (even when wx being compiled in). > > - When wx terminal is built-in, then x11 or win terminals are not compiled > in, but their "set term ..." are redirected to wxt. Then, using "set term > x11", "set term win", "set term wxt" does always the same thing whereever > you run the given script. > > - There can be a unique dummy screen terminal name e.g. "set term screen" > that "hides" these "set term some_OS_screen_terminal". > > - It is only the OS/2 gnuplot which can have both x11 and pm in > simultaneously. However, wxt is not working there (or at least untested). > > Or some functionality like that. I hope you caught the point. > Please think about it. > > --- > PM > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2006-04-14 15:48:12
|
> So yes, perhaps "set term screen <num>", where
> "screen" is taken from GNUTERM, and <num> is ignored for
> terminals that don't support multiple windows.
My main motivation: prepare infrastructure for a portable way of gnuplot
screen terminal capabilities. There will be a rewrite of gnuplot files for
octave, for example, so prepare gnuplot for this.
For example, we cannot live with Octave's figure.m implementation with
hardcoded "set term x11 5".
Screen terminals should be unified so that they are capable of
set terminal screen {<n>}
{title "<string>"}
{{no}enhanced}
{font <fontspec>}
{{no}persist}
{{no}raise}
{close}
on any OS. And you could do just once in a startup script:
set terminal defaultscreen x11
set terminal defaultscreen windows
set terminal defaultscreen pm
set terminal defaultscreen wxterminal
>That is what the environmental variable GNUTERM is for.
But it is not available from within gnuplot unless gnuplot supports new
string function getenv('GNUTERM')? Please notice that `echo GNUTERM` is not
available in wgnuplot.exe.
---
PM
|
|
From: <tim...@en...> - 2006-04-14 20:06:51
|
>> So yes, perhaps "set term screen <num>", where
>> "screen" is taken from GNUTERM, and <num> is ignored for
>> terminals that don't support multiple windows.
>
> My main motivation: prepare infrastructure for a portable way of gnuplo=
t
> screen terminal capabilities. There will be a rewrite of gnuplot files =
for
> octave, for example, so prepare gnuplot for this.
> For example, we cannot live with Octave's figure.m implementation with
> hardcoded "set term x11 5".
>
>
> Screen terminals should be unified so that they are capable of
> set terminal screen {<n>}
> {title "<string>"}
> {{no}enhanced}
> {font <fontspec>}
> {{no}persist}
> {{no}raise}
> {close}
I appreciate this initiative, but I have one remark concerning this synta=
x
: why should "close" be here ? It is very different from other entries fo=
r
'set terminal' which do not correspond to actions, but to settings.
I would prefer to see a new entry in the term table, for term->close(),
which could probably go along with new term->raise(), term->lower()
instead of the way these two calls are currently implemented directly in
command.c
Regards,
Timoth=E9e
|
|
From: Petr M. <mi...@ph...> - 2006-04-16 19:44:50
|
> I would prefer to see a new entry in the term table, for term->close(),
> which could probably go along with new term->raise(), term->lower()
> instead of the way these two calls are currently implemented directly in
> command.c
I had a proposal for
term->interactive(command)
flying around for some longer time, but I had never time to work on it. That
would be useful for actions like:
term->interactive("disable q hotkey")
term->interactive("make mousing menus disabled")
term->interactive("make mousing menus enabled")
term->interactive("raise 5")
term->interactive("close")
term->interactive("put ruler")
term->interactive("change cursor")
etc.
---
PM
|
|
From:
<br...@ph...> - 2006-04-18 17:53:22
|
Petr Mikulik wrote:
> term->interactive("disable q hotkey")
> term->interactive("make mousing menus disabled")
> term->interactive("make mousing menus enabled")
> term->interactive("raise 5")
> term->interactive("close")
> term->interactive("put ruler")
> term->interactive("change cursor")
The API entry as such may be a good idea. Passing it a command string
as indicated above, however, most emphatically is not. This is an
programming interface, not a user interface. I won't have a secondary
command parser stuck deep inside each of half a dozen terminal drivers.
The mess with all those term->option() parsers is quite bad enough
already --- let's not make that mistake again.
If what the call does can't be parametrized into a usable C datatype (a
couple of enums, one or two optional arguments, that kind of thing),
then this is not API design --- it's an attempt to get away without
actually doing any design.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-14 16:03:29
|
On Friday 14 April 2006 08:48 am, Petr Mikulik wrote:
> > perhaps "set term screen <num>", where "screen" is taken from
> > GNUTERM, and <num> is ignored for terminals that don't support multiple windows.
>
> For example, we cannot live with Octave's figure.m implementation with
> hardcoded "set term x11 5".
exactly
> Screen terminals should be unified so that they are capable of
> set terminal screen {<n>}
> {title "<string>"}
> {{no}enhanced}
> {font <fontspec>}
> {{no}persist}
> {{no}raise}
> {close}
I agree with this, but the mechanism is already in place:
set term pop
set termoption enhance font "Times,11" ...
We would just need to expand the list of keywords accepted by
'set termoption'. Hmm. "persist" might be a problem.
> >That is what the environmental variable GNUTERM is for.
>
> But it is not available from within gnuplot unless gnuplot
> supports new string function getenv('GNUTERM')?
What do you mean "available"?
The value of GNUTERM is stored as the terminal name on entry.
So if you immediately do a "set term push", then you have
saved whatever the GNUTERM default was and can recover it
later with "set term pop".
But yes, we could also copy it into a udv called GNUTERM.
That is so easy that I might as well just go ahead and add it :-)
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Petr M. <mi...@ph...> - 2006-04-16 19:22:03
|
>>> perhaps "set term screen <num>", where "screen" is taken from
>>> GNUTERM, and <num> is ignored for terminals that don't support multiple windows.
>
> exactly
>
>> Screen terminals should be unified so that they are capable of
>> set terminal screen {<n>}
>> {title "<string>"}
>> {{no}enhanced}
>> {font <fontspec>}
>> {{no}persist}
>> {{no}raise}
>> {close}
>
> I agree with this, but the mechanism is already in place:
> set term pop
> set termoption enhance font "Times,11" ...
I think it is much more logical to write
set term screen title "hello"
then doing those setting as
set term pop; set termoptions ...
BTW, "set term pop" for those things will fail if your "set term push"ed
terminal is postscript, for example. These commands are intended for saving
the *current* terminal e.g. before printing, not for restoring the default
screen terminal (yes it is available as "set term pop" would be undefined
otherwise).
Thus I propose, at the startup point of gnuplot, where the initial "set term
pop/push" is pushed, to "link" the "screen" terminal. Would a simple strcpy
suffice or how to associate them?
>> supports new string function getenv('GNUTERM')?
> What do you mean "available"?
> The value of GNUTERM is stored as the terminal name on entry.
> So if you immediately do a "set term push", then you have
> saved whatever the GNUTERM default was and can recover it
> later with "set term pop".
> But yes, we could also copy it into a udv called GNUTERM.
> That is so easy that I might as well just go ahead and add it :-)
I see you've added it ... I tried it ... However, this variable is undef if
user doesn't use GNUTERM env. variable. I think gnuplot's GNUTERM should
contain the name of the startup terminal then -- otherwise this variable
does not make any sense.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-14 21:23:59
|
On Friday 14 April 2006 01:06 pm, you wrote: > > I would prefer to see a new entry in the term table, for term->close(), That would be a bit confusing, because it would logically operate on the current terminal. The idea of "set term close <num>" is that it closes an old terminal plot window, while leaving the current one untouched. You could probably make it work, but I'm not thrilled about the semantics. > which could probably go along with new term->raise(), term->lower() > instead of the way these two calls are currently implemented directly in > command.c I would rather see all the 'raise' and 'lower' commands go away altogether. My position remains that an application program has no business raising or lowering my windows. But yes, a terminal entry point would be cleaner than the current special case coding in command.c -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-04-14 21:39:37
|
> On Friday 14 April 2006 01:06 pm, you wrote: >> >> I would prefer to see a new entry in the term table, for term->close()= , > > That would be a bit confusing, because it would logically operate on th= e > current terminal. The idea of "set term close <num>" is that it closes > an old terminal plot window, while leaving the current one untouched. > You could probably make it work, but I'm not thrilled about the semanti= cs. > >> which could probably go along with new term->raise(), term->lower() >> instead of the way these two calls are currently implemented directly = in >> command.c > > I would rather see all the 'raise' and 'lower' commands go away > altogether. > My position remains that an application program has no business raising= or > lowering my windows. But yes, a terminal entry point would be cleaner > than the current special case coding in command.c I agree with you, however regarding the recent discussions about the spacebar which is supposed to raise the gnuplot window, it seems that these functions which raise/lower windows are needed. I can imagine a similar syntax for "close" : "raise" =3D> raise all terminal windows "raise <n>" =3D> raise n-th terminal window "lower" =3D> lower all terminal windows "lower <n>" =3D> lower n-th terminal window "close" =3D> close all terminal windows "close <n>" =3D> close n-th terminal window Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-04-14 22:24:54
|
Petr Mikulik wrote: > Some ideas about "screen" terminals, for discussion: > Or some functionality like that. I hope you caught the point. > Please think about it. In the case of Linux, putting the terminal code into individual driver files (object files) might be nice. It would require some mechanism to install the driver in response to "set term". Then again, gnuplot is a relatively small program in todays software world even with all the terminal drivers inside. But if there were an imbedded application, it might be nice. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-14 23:20:54
Attachments:
termsizes.png
|
On Friday 14 April 2006 03:32 pm, Daniel J Sebald wrote: > > In the case of Linux, putting the terminal code into individual > driver files (object files) might be nice. But the screen terminal drivers are small, so you would not gain much (remember that gnuplot_x11 is a separate executable). The big terminals are hpglxxx and postscript. That is why I originally wanted to pull the prolog text out out of post.trm. Figure from last year attached. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-04-15 00:46:55
|
Ethan Merritt wrote: > On Friday 14 April 2006 03:32 pm, Daniel J Sebald wrote: > >>In the case of Linux, putting the terminal code into individual >>driver files (object files) might be nice. > > > But the screen terminal drivers are small, so you would not > gain much (remember that gnuplot_x11 is a separate executable). > > The big terminals are hpglxxx and postscript. > That is why I originally wanted to pull the prolog text out > out of post.trm. Oh yeah, I remember that now. Not worth it. > > Figure from last year attached. Consider putting this figure on the web page. Maybe a "statistics" subpage or something. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-16 20:43:18
|
On Sunday 16 April 2006 12:21 pm, Petr Mikulik wrote: > BTW, "set term pop" for those things will fail if your "set term push"ed > terminal is postscript, for example. I was under the impression that 'set term push/pop' was a stack, but I see that I was wrong. The truth is that I have never used this mechanism. > > But yes, we could also copy it into a udv called GNUTERM. > > That is so easy that I might as well just go ahead and add it :-) > > I see you've added it ... I tried it ... However, this variable is undef if > user doesn't use GNUTERM env. variable. I think gnuplot's GNUTERM should > contain the name of the startup terminal then -- otherwise this variable > does not make any sense. OK. But then the name "GNUTERM" is slightly misleading. Should it rather be "DEFAULT_TERMINAL" or something like that? By the way, saving the value of GNUTERM internally allows this rather neat trick, where the terminal options are kept also: [1] setenv GNUTERM "post eps solid color lw 2" [2] gnuplot ... gnuplot> set term <something_else> gnuplot> [... do a bunch of stuff ...] gnuplot> set macros gnuplot> set term @GNUTERM gnuplot> show term Terminal type set to 'postscript' Options are 'eps noenhanced defaultplex \ leveldefault color colortext \ solid dashlength 1.0 linewidth 2.0 butt \ palfuncparam 2000,0.003 \ "Helvetica" 14 ' -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2006-04-16 21:16:20
|
> I was under the impression that 'set term push/pop' was a stack, > but I see that I was wrong. It is one level deep, but allows for any number of pop's. >> I see you've added it ... I tried it ... However, this variable is undef if >> user doesn't use GNUTERM env. variable. I think gnuplot's GNUTERM should >> contain the name of the startup terminal then -- otherwise this variable >> does not make any sense. > > OK. But then the name "GNUTERM" is slightly misleading. > Should it rather be "DEFAULT_TERMINAL" or something like that? STARTUP_TERMINAL? --- PM |
|
From:
<br...@ph...> - 2006-04-18 17:58:35
|
Ethan A Merritt wrote: > On Sunday 16 April 2006 12:21 pm, Petr Mikulik wrote: > >> BTW, "set term pop" for those things will fail if your "set term push"ed >> terminal is postscript, for example. > > I was under the impression that 'set term push/pop' was a stack, > but I see that I was wrong. No. It is a stack. But it has a limitless bottom. I.e. 'set term pop' on an empty stack yields the default terminal, simply because the terminal cannot be set to "NULL". > Should it rather be "DEFAULT_TERMINAL" or something like that? And before we go ahead adding such intruders into the udv namespace, I think we should set a reserved prefix immediately. So far, we've only had FIT_* names reserved for extensions to fit (and no string vars among those). |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-18 18:39:07
|
On Tuesday 18 April 2006 10:59 am, Hans-Bernhard Br=F6ker wrote: > > Should it rather be "DEFAULT_TERMINAL" or something like that? >=20 > And before we go ahead adding such intruders into the udv namespace, I=20 > think we should set a reserved prefix immediately. So far, we've only=20 > had FIT_* names reserved for extensions to fit (and no string vars among= =20 > those). Also MOUSE_* (one of which is a string var) But yes, I agree there should be a single prefix reserved, or at worst a small number of them. Shall we say GPVAL_* ? Anything is OK with me, really. I'm also agreeable to changing MOUSE_X to GPVAL_MOUSE_X and so on, although the mouse variables were already in version 4.0 under their current names so it could break existing scripts. =20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From:
<br...@ph...> - 2006-04-18 19:31:16
|
Ethan Merritt wrote: > But yes, I agree there should be a single prefix reserved, > or at worst a small number of them. > > Shall we say GPVAL_* ? One possible problem: for some values, these values will actually constitute an alternative to "show <some setting>", for others, it would expose data that was never available outside the run time of the 'plot' command itself, or via explicit methods (writeback/recall for range ends). I.e. we may have to reserve all prefixes starting with GP to have an opportunity to later distinguish between GPSET_* and GPVAL_* > I'm also agreeable to changing MOUSE_X to GPVAL_MOUSE_X and so on, > although the mouse variables were already in version 4.0 under > their current names so it could break existing scripts. So deprecate MOUSE_*, but keep them working for 4.2, or maybe the entire 4.* series, if we ever make enough releases to form one ;-) |
|
From: Petr M. <mi...@ph...> - 2006-04-18 20:06:57
|
> Also MOUSE_* (one of which is a string var) Most of them are floats. > But yes, I agree there should be a single prefix reserved, > or at worst a small number of them. > > Shall we say GPVAL_* ? > Anything is OK with me, really. > > I'm also agreeable to changing MOUSE_X to GPVAL_MOUSE_X and so on, > although the mouse variables were already in version 4.0 under > their current names so it could break existing scripts. I propose to call those accessing gnuplot internals by GPVAL_ Proposals: floats: GPVAL_XMIN, GPVAL_YMIN, ... strings: GPVAL_TERM, GPVAL_TERMOPTIONS Those MOUSE_ should be kept -- they are results of an action (mouse click/hotkey), thus no gnuplot internal settings. And renames are bad things, anyway. --- PM |
