gnuplot-beta — Developers and beta testers of new gnuplot code

Re: new command: raise

[Petr M. <mi...@ph...>]

> > Would it be possible to configure Gnuplot's compilation so that
> > it can figure out which terminal should be the "interactive" one?

That's clear how do you compile gnuplot.
#ifdef OS2 => PM is interactive
#ifdef X11 => X11 is interactive
#ifdef _Windows => windows is interactive

> That is where I am still confused about Petr's suggested
> "raise" function.  Suppose your gnuplot session has both a
> of pm window active and an X11 window active.  If you type "raise",
> how is it supposed to know which window you are talking about?

With all of them. It will raise all of them -- all are interactive.

> Petr also suggests that the default is to raise all windows at
> the same time. Maybe I am misunderstanding, because I don't
> see why this is useful.  If the windows are obscuring each other
> already, then sending them all a raise command will still result
> in the same amount of overlap.  What have you gained?

No each other already, but other windows are overlaping all or some of them.
I.e. you have running gnuplot or octave with gnuplot windows, now you have a
look to a man page, then to web browser, and you want to see again all your
plots ... so you want to raise all of them. That's what "raise" command
helps to achieve with zero user effort.

Look this way: Origin and similar graph apps have a common "desktop" for all
windows, so raising Origin will raise its desktop with all windows. Nedit
has menu which list all open Nedit editor windows. Most graphical apps have
"Tile" and "Cascade" functions.
  So gnuplot takes the most easiest way to do just "raise" for all of its
windows.

> Now wanting to send a command to one specific window - that I
> understand, although I still think it is more properly a function
> left to the window manager.

Window manager don't let you distinguish which gnuplot graphics window
belongs to which gnuplot console. (*you* would have to explicitly title such
windows *in advance* -- so it is very cumbersome)

---
Petr Mikulik

Re: new command: raise

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

Petr Mikulik wrote:
> >>   Thus, on any OS, there is no way to find which gnuplot terminal
> >> window belongs to which gnuplot console instance.

Hans-Bernhard Broeker wrote:
> > I'm not sure the application running
> >gnuplot through a pipe couldn't just send a GUI event to the window
> >manager or the main gnuplot window to raise the gnuplot window and all
> > of its children

Dan Sebald wrote:
> there would be a connection made between
> the app and the window, where gnuplot is a liason to help make
> the connection but then is removed from the picture.

Let me clarify Dan's point.   There are several conditions under
which the gnuplot core will close down its connection to the
outboard driver (gnuplot_x11), and later open a new connection
to a new instance of gnuplot_x11 if a new 'set term x11' command
is received.   In this case you have X11 terminal windows on the
screen which are no longer connected to the controlling gnuplot
terminal session at all.  The only way to interact with these windows
is via the mouse or via the window manager.  No command from the
gnuplot core can talk to them, or to the gnuplot_x11 instance that
is controlling them.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: new command: raise

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

On Monday 08 December 2003 10:22, Daniel J Sebald wrote:
>
> It sounds to me that the strategy here is to now break the
> terminals into two classes, the normal group of terminals and
> a visual GUI set of terminals, i.e., the terminal in which one
> is viewing interactively. =20

How would gnuplot know this?  I routinely pipe both png
and postscript output through a viewer so that I can use those
terminal types in an interactive session.

> The "raise" would only apply to the
> interactive terminal.  That means that the source code should
> have an addition terminal pointer, say interactive_term, that
> the raise command operates on.  (I'm also arguing that if you
> are going to go through this trouble, the function should be
> more than just raise... also minimize, maximize, close, hide, etc.)

I think this would be total bloat.   The whole *function* of=20
a window manager is to manage this stuff so that individual
applications do not have to.

I can't comment on what is needed when running under Windows
or OS2, but in the X11 environment I don't think any of this stuff
belongs in the application program.

> Would it be possible to configure Gnuplot's compilation so that
> it can figure out which terminal should be the "interactive" one?

That is where I am still confused about Petr's suggested=20
"raise" function.  Suppose your gnuplot session has both a
of pm window active and an X11 window active.  If you type "raise",
how is it supposed to know which window you are talking about?

Petr also suggests that the default is to raise all windows at
the same time. Maybe I am misunderstanding, because I don't
see why this is useful.  If the windows are obscuring each other
already, then sending them all a raise command will still result
in the same amount of overlap.  What have you gained?

Now wanting to send a command to one specific window - that I=20
understand, although I still think it is more properly a function
left to the window manager.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: new command: raise

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>>   Thus, on any OS, there is no way to find which gnuplot terminal window
>>   belongs to which gnuplot console instance. 
>>    
>>
>
>As I see it, _this_ would be the only real reason that a command from
>inside gnuplot would be needed.  I'm not sure the application running
>gnuplot through a pipe couldn't just send a GUI event to the window
>manager or the main gnuplot window to raise the gnuplot window and all of
>its children, but if that can't be done, then yes, a 'raise' command would
>be the way to go.
>

This issue about the GUI being directed to control raising of
the window came up in a different form when we discussed
the mouse and attaching functions to it.  Ethan implemented
a manner in which the mouse information can be directed
somewhere.  Before that we speculated if it would be possible
to "attach" some function to the mouse from an outside app.
In both these cases, there would be a connection made between
the app and the window, where gnuplot is a liason to help make
the connection but then is removed from the picture.

Dan

Re: new command: raise

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:

>>And so far I have not been clever enough to figure out how to make this
>>work *at all* under X11 unless X11 is in fact the current terminal type.
>>    
>>
>
>x11.trm would send "^" character to the pipe. Then 0 (all windows), or 1
>(one window) + number. Then gplt_x11.c would browse through the list of all
>windows and either raise all of them, or just that one explicitly specified.
>
>Is this possible to implement?
>

Implementing such a thing would be fairly easy.  But, I think
the point here was that in order to do this, the x11 terminal
would have to be the current terminal.  That is

set term x11
plot sin(x)
set term postscript
raise 1

might not work because after doing the "set term postscript"
the terminal pointer in not pointing to x11 anymore.

It sounds to me that the strategy here is to now break the
terminals into two classes, the normal group of terminals and
a visual GUI set of terminals, i.e., the terminal in which one
is viewing interactively.  The "raise" would only apply to the
interactive terminal.  That means that the source code should
have an addition terminal pointer, say interactive_term, that
the raise command operates on.  (I'm also arguing that if you
are going to go through this trouble, the function should be
more than just raise... also minimize, maximize, close, hide, etc.)
Would it be possible to configure Gnuplot's compilation so that
it can figure out which terminal should be the "interactive" one?

How about this idea?  Say the GUI-based terminals (x11,
Windows, pm, etc.) have an option called "interactive", e.g.,

set term x11 interactive

This will set the hypothesized interactive_term variable.  (If the
compilation is only for x11, perhaps interactive_term should have
a default of the x11 terminal.)  Then "raise" will send the required
terminal command to that, so that if one types "set term postscript",
any raise commands still go to the x11 terminal.  If interactive_term
is zero, then the command gets sent to the current terminal, which
in some cases will be an empty function.

Dan

Re: new command: raise

[Hans-Bernhard B. <br...@ph...>]

On Sat, 6 Dec 2003, Petr Mikulik wrote:

> 3. It must impact all screen terminals of the currently running gnuplot,
>    whatever is your currently selected terminal (I want to raise my PM
>    window even when generating a postscript file -- just to have a look).
>    Thus, the implementation I did for OS/2 and Windows is correct.
>    Further, there is no need for a new terminal API (yet) -- that OS,
>    which wants to support this, just adds its #ifdef.

I rather strongly think that there is a need to put this into the terminal
API definition.  Pause is not as similar as you make it out to be --- 
that one deals with the command line interface, not with the graphics
output.  Pause doesn't doesn't belong into the terminal interface, but
a prospective new command whose sole effect is to change the state of
terminal output (i.e. plot windows), definitely does.

>    Thus, on any OS, there is no way to find which gnuplot terminal window
>    belongs to which gnuplot console instance. 

As I see it, _this_ would be the only real reason that a command from
inside gnuplot would be needed.  I'm not sure the application running
gnuplot through a pipe couldn't just send a GUI event to the window
manager or the main gnuplot window to raise the gnuplot window and all of
its children, but if that can't be done, then yes, a 'raise' command would
be the way to go.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: new command: raise

[Petr M. <mi...@ph...>]

> >
> > 1. It must be easily/fastly typed, as "rep" for "replot" is
> >    => no such long commands as "s term x11" are acceptable
> >    In my proposal, "ra" for "raise" is perfect.
>
> I agree with you here, at least for interactive use.
> But I think we need to decide on the desired behaviour first,
> and then worry about how to trigger it.

The behaviour is to raise all screen windows.

With an additional option, e.g.
	raise one
it would raise only the last active window.

> available, I already contributed a proof-of-principle patch last
> Spring that allows you to define macros at the command level.
> So you could make "ra" a macro for "set term pm raise" if you
> wanted to save keystrokes.

That macro would be quite awful and require access to some compile-time
built-in constants:
  macro raise \
	if (gnuplot_for_os2) "set term pm raise"; fi; \
	if (gnuplot_for_windows) "set term windows raise"; fi; ...

> > 2. It must be portable. You should write the command and should have
> >    the same effect on whichever OS you work right now.
>
> I agree here, too, with the caveats that it must allow you to specify
> what window you are trying to raise.

You can specify a window if you want to raise just one.

> >    Thus no "set term pm raise", "set term windows raise", and
> >    "set term x11 raise", but a single command like "raise".
>
> I don't think you can avoid specifying the terminal type (see below),
> but I could be wrong.

I think you can.

> > 3. It must impact all screen terminals of the currently running gnuplot,
> >    whatever is your currently selected terminal (I want to raise my PM
> >    window even when generating a postscript file -- just to have a look).
>
> I strongly disagree.  I cannot see that I would ever want to have
> this command affect more than 1 window at a time.

In X11 window 1, I have a 'pm3d map' of experimental map.
In X11 window 2, I have a single scan through this map.
And now, I want to raise both.

> Furthermore, I am still concerned that for this to be generally useful
> you have to be able to specify which terminal it applies to.
> Can you not have both an X11 window and an os2/pm window open at the
> same time?

Yes, you can.
But you usually work either with X11 or with PM window.

> Certainly when I am generating figures I often have showing on my
> screen some windows that were generated directly by the X11 terminal
> driver, and some others that were generated by the gd driver piped
> through "set output '|display png:-'".
> Can you not have a similar situation under os2, with both x11 and
> pm windows on the screen at the same time?

Yes, you can. That's nice, isn't it?

> >    Notice that "pause" is implemented in exactly the same way -- plenty
> >    of #ifdefs (and if you don't know, it usually pops up a small pause
> >    window on OS/2 and Windows).
>
> Ugh. I would hate that.   Doesn't that small window get in your way?

On OS/2, you can choose to have
- a pause window
- a main menu item called "Continue" (that's the best for me)
- have to press <Enter> in gnuplot's prompt -- like on Unix, and with the
same drawback: it does not work with interactive programs

> Maybe, or maybe not.  I still think we need to decide first what the desired
> behaviour is.  It may or may not then be possible to implement it without
> calling a terminal driver.

There are several x11 windows open, so that gnuplot (or gnuplot_x11?) should
go through their list and raise them one after the other.

> > 2. the X11-specific "set term x11 <n> raise" is as long and non-portable
> >    that it is useless for the proposed functionality (OK, if you like,
> >    you can add this proposal, but independent from the "raise" command)
> Non-portable?   How is it any less portable than an OS2-specific command?

Non-portable command from user-point of view. Different command on different
OSes.

> > 5. If you still don't see how much useful "raise" command is, then load 3
> >    similar data into 3 instances of gnuplot, cover all windows by whatever
> >    other graphics windows, and then try to figure out who belongs to
> > whom...
>
> Thanks to Daniel, we now have a "title <blah blah blah>" option to
> set term x11.  So all my windows are labeled however I like.
> There is no problem figuring out which one is which. Maybe a simpler
> solution is to add this feature to the other screen-oriented terminal
> drivers? (I thought the pm terminal already had this?)

PM terminal has this.

But "title" does not help -- or makes it complicated. You would have to
always explicitly title every x11 plot, and if you forget, there is no help.


> > In other words, think of "raise" as of "replot" without replotting :-))
>
> Yes, I understand that, and I agree it is a good idea.
> It is the best specific implementation on which we apparently part ways.
>
> > Is it now clear what's the reason and necessity for just "raise" and not
> > anything else?
>
> If you can figure out a way to pass enough information to such a raise
> command, then I have no objection to adding it.  But it must at a minimum
> allow
> 	raise <n>
> to specify which window it is that you want to raise.

Ok, this can take X11's <n> argument; this option would be ignored for
Windows and PM terminals, but used by X11.

By default, all windows are raised.

> And so far I have not been clever enough to figure out how to make this
> work *at all* under X11 unless X11 is in fact the current terminal type.

x11.trm would send "^" character to the pipe. Then 0 (all windows), or 1
(one window) + number. Then gplt_x11.c would browse through the list of all
windows and either raise all of them, or just that one explicitly specified.

Is this possible to implement?

---
Petr Mikulik

Re: arrow head adjustment

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>>The question then is, will the terminal achieve the specified line
>>width, or will it only approximate it?  In the latter case, we are no
>>further along.
>>    
>>
>
>If the terminal doesn't do an accurate job, that's too bad.  I don't think
>it's worth bothering about such terminals in terms of how to manage nicely
>drawn arrows for them.  The risk of making already inaccurate outputs even
>worse are essentially negligible, I'd say.  If all else fails, they could
>still be fixed by reporting an effective linewidth of zero plot units, and
>thus reverting to the current behaviour.
>

That's a good idea.

Dan

Re: arrow head adjustment

[Hans-Bernhard B. <br...@ph...>]

On Sun, 7 Dec 2003, Daniel J Sebald wrote:

> In my opinion, if arrow tips were to be compensated for,
> it would be nice to have the formula at a high level  so that
> it doesn't need to be implemented multiple times in the
> various drivers.  Perhaps some drivers have an option for
> where the tip should land.  

I don't expect any of them does, at this time.  The majority of them rely
on the common fallback implementation term.c:do_arrow() for this.  It's
mainly the vector graphics file format drivers have their own
implementation.  cscope reports:

../term/debug.trm .*[^o]_arrow 245 DEBUG_arrow(sx, sy, ex, ey, head)
../term/dumb.trm .*[^o]_arrow 385 DUMB_arrow(sx, sy, ex, ey, head)
../term/eepic.trm .*[^o]_arrow 366 EEPIC_arrow(sx, sy, ex, ey, head)
../term/epslatex.trm .*[^o]_arrow 892 EPSL_arrow(xstart, ystart, xend, yend, head)
../term/fig.trm .*[^o]_arrow 771 FIG_arrow(sx, sy, ex, ey, head)
../term/gpic.trm .*[^o]_arrow 217 GPIC_arrow(sx, sy, ex, ey, head)
../term/grass.trm .*[^o]_arrow 618 GRASS_arrow(sx, sy, ex, ey, head)
../term/latex.trm .*[^o]_arrow 639 LATEX_arrow(sx, sy, ex, ey, head)
../term/latex.trm .*[^o]_arrow 650 best_latex_arrow(sx, sy, ex, ey, who, head)
../term/metafont.trm .*[^o]_arrow 466 MF_arrow(sx, sy, ex, ey, head)
../term/metapost.trm .*[^o]_arrow 675 MP_arrow(unsigned int sx, unsigned int sy, unsigned int ex, unsigned int ey, TBOOLEAN head)
../term/pstricks.trm .*[^o]_arrow 399 PSTRICKS_arrow(sx, sy, ex, ey, head)
../term/texdraw.trm .*[^o]_arrow 282 TEXDRAW_arrow(sx, sy, ex, ey, head)
../term/tgif.trm .*[^o]_arrow 569 TGIF_arrow(sx, sy, ex, ey, head)
../term/tpic.trm .*[^o]_arrow 628 TPIC_arrow(sx, sy, ex, ey, head)
../term/vws.trm .*[^o]_arrow 463 VWS_arrow(sx, sy, ex, ey, head)

To top it off, the current way arrow head options are handled is
atrocious.  There is *no* terminal API entry to pass arrow options
through, though there definitely should be.  While adding that, it
should be reasonably easy to pass on the line width to the arrow
drawing routines, too.  It *is* part of the arrow options structure,
after all.  term_api.h on arrow_style_type says:

typedef struct arrow_style_type {    /* contains all Arrow properties */
    int layer;                       /* 0 = back, 1 = front */
    struct lp_style_type lp_properties;
[...]

and the line width is part of struct lp_style_type.

> But it isn't worth doing unless there is some way of addressing
> the line width issue.  Getting back line width information might
> be tough.  However, would it be possible to slightly alter the
> terminal line command so that the line width is specified in plot
> units rather than the somewhat arbitrary "1, 2, 3, 4"?  

No.  That would break plot script compatibility, while being almost
certainly un-necessary.  As far as I'm aware, all terminal drivers already
do have default-line width == 1 terminal unit anyway (with exceptions for
the border line type that's usually 2 units wide).

> It could remain "1 2 3 4" from the users' perspective, but first
> translate those to plot units before calling the (*term)->linewidth()
> function.

That's none of the 'set term' command's business to do, nor does it have
the information needed for doing it.  I think not all terminals supporting
variable-width lines even *have* a linewidth option in their terminal
options to begin with. 

The only somewhat reasonable ways I see would be to add a new API function
term->get_linewidth() that reports the current width, in plot units, or to
append to the semantics of term->linewidth(), adding that it should modify
some global variable accordingly, which is initialized by the caller so
most implementations can remain unchanged.  This shouldn't be overly hard,
as term->linewidth() is only called in rather few places to begin with.  
According to cscope:
 
6 mouse.c      event_buttonrelease      1522 (term->linewidth) (border_lp.l_width);
7 term.c       term_apply_lp_properties  615 (*term->linewidth) (lp->l_width);
a term.c       test_term                1592 (*t->linewidth) (1.0);
b term.c       test_term                1717 (*t->linewidth) (1.0);
c term.c       test_term                1740 (*t->linewidth) ((float)(i));
d term.c       test_term                1754 (*t->linewidth) ((float)(1));

> The question then is, will the terminal achieve the specified line
> width, or will it only approximate it?  In the latter case, we are no
> further along.

If the terminal doesn't do an accurate job, that's too bad.  I don't think
it's worth bothering about such terminals in terms of how to manage nicely
drawn arrows for them.  The risk of making already inaccurate outputs even
worse are essentially negligible, I'd say.  If all else fails, they could
still be fixed by reporting an effective linewidth of zero plot units, and
thus reverting to the current behaviour.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: arrow head adjustment

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Fri, 5 Dec 2003, Daniel J Sebald wrote:
>
>  
>
>>Did anyone have any ideas for getting the
>>width of a line in terms of plot units from the
>>terminal?
>>    
>>
>
>I don't think there is any generic way of doing that.  There's an
>awful lot of copy-pasted code in the terminal drivers which just has
>different variable names, and no generic data structure for internal 
>variables even for cases like this that could use common basic routines
>like "do_linewidth_by_saving_value()" as their term->linewidth() API
>implementation. 
>
>It may not even be the case that all relevant drivers _have_ the linewidth
>stored in any variable in the first place.  PostScript-like ones could
>just have written out a postscript command that sets the linewidth and
>forgot about it...
>
>This may need a re-design of at least the arrow-drawing part of the 
>terminal API to work it out.
>

I think your assessment is correct.

In my opinion, if arrow tips were to be compensated for,
it would be nice to have the formula at a high level  so that
it doesn't need to be implemented multiple times in the
various drivers.  Perhaps some drivers have an option for
where the tip should land.  It might be wise to see how they
all perform before concluding on the best approach.

But it isn't worth doing unless there is some way of addressing
the line width issue.  Getting back line width information might
be tough.  However, would it be possible to slightly alter the
terminal line command so that the line width is specified in plot
units rather than the somewhat arbitrary "1, 2, 3, 4"?  It could
remain "1 2 3 4" from the users' perspective, but first translate
those to plot units before calling the (*term)->linewidth()
function.  The question then is, will the terminal achieve
the specified line width, or will it only approximate it?  In the
latter case, we are no further along.

Dan

Re: arrow head adjustment

[Hans-Bernhard B. <br...@ph...>]

On Fri, 5 Dec 2003, Daniel J Sebald wrote:

> Did anyone have any ideas for getting the
> width of a line in terms of plot units from the
> terminal?

I don't think there is any generic way of doing that.  There's an
awful lot of copy-pasted code in the terminal drivers which just has
different variable names, and no generic data structure for internal 
variables even for cases like this that could use common basic routines
like "do_linewidth_by_saving_value()" as their term->linewidth() API
implementation. 

It may not even be the case that all relevant drivers _have_ the linewidth
stored in any variable in the first place.  PostScript-like ones could
just have written out a postscript command that sets the linewidth and
forgot about it...

This may need a re-design of at least the arrow-drawing part of the 
terminal API to work it out.

Re: new command: raise

[Petr M. <mi...@ph...>]

Unfortunately, my short mail didn't present well the main idea behind.
So, here it is -- the command for raising:

1. It must be easily/fastly typed, as "rep" for "replot" is
   => no such long commands as "s term x11" are acceptable
   In my proposal, "ra" for "raise" is perfect.

2. It must be portable. You should write the command and should have
   the same effect on whichever OS you work right now.
   Thus no "set term pm raise", "set term windows raise", and
   "set term x11 raise", but a single command like "raise".

3. It must impact all screen terminals of the currently running gnuplot,
   whatever is your currently selected terminal (I want to raise my PM
   window even when generating a postscript file -- just to have a look).
   Thus, the implementation I did for OS/2 and Windows is correct.
   Further, there is no need for a new terminal API (yet) -- that OS,
   which wants to support this, just adds its #ifdef.

   Notice that "pause" is implemented in exactly the same way -- plenty
   of #ifdefs (and if you don't know, it usually pops up a small pause
   window on OS/2 and Windows).


Consequently:

1. there is no need to implement it by new terminal api

2. the X11-specific "set term x11 <n> raise" is as long and non-portable
   that it is useless for the proposed functionality (OK, if you like,
   you can add this proposal, but independent from the "raise" command)

3. The effect of "gnuplot -raise" (again, non-portable command, see also
   OS/2 PM menu for "Always on top" vs. "set term x11 raise") does a
   completely different thing (auto raise after "(s)plot" command).

4. This "raise" is completely irrelevant to desktop manager (try to have
   a look to the window title after "plot x" on OS/2 or Windows, not to be
   so much X11 localized -- but, actually, on X11 you will see exactly the
   same window title if you launch gnuplot several times).
   Thus, on any OS, there is no way to find which gnuplot terminal window
   belongs to which gnuplot console instance. (And don't try to convince
   people to use BESTBLABLA X11 windows manager because it may have
   "some kind of such a feature" -- gnuplot is a portable tool).

5. If you still don't see how much useful "raise" command is, then load 3
   similar data into 3 instances of gnuplot, cover all windows by whatever
   other graphics windows, and then try to figure out who belongs to whom...

  3 gnuplot windows is not unusual -- one experimental data, one good
  simulation, other current simulation ... or some windows from Octave...
  and then, you want to raise up just window with the raw data and that
  from octave, but you don't need to replot it (also, X11 are quite slow
  when replotting large maps, so "replot" is a waste of resources). Then
  comes a colleagues and asks you "can I see the curve we are just
  measuring ...?"

In other words, think of "raise" as of "replot" without replotting :-))

Is it now clear what's the reason and necessity for just "raise" and not
anything else?

BTW, this "raise" command implementation for OS/2 and Windows is not
in CVS, it was just attached to my email.

---
Petr Mikulik

Re: new command: raise

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

On Thursday 04 December 2003 10:31, Petr Mikulik wrote:
>
> Solution: new command "raise" (abbreviated "ra"). Enclosed is an
> implementation for OS/2 PM and Windows terminals. Could somebody
> contribute X11 code?

The attached patch does not add any commands, nor does it
change existing syntax.  Instead it causes=20
=09set term x11 <n> raise
to raise that window immediately (if it exists at all) in addition to set=
ting
the "raise" attribute for future plots in that window.

I think this is pretty harmless, though I doubt I would use it often
myself.  I agree with whoever (Dan?) pointed out that for interactive
use this is more naturally achieved just by clicking on the appropriate
icon provided by your desktop/window manager. Maybe it has a place
in scripted environments, though.

I won't put this in CVS without some feedback from you, though.
Does it achieve what you wanted?  Also, in light of Dan Sebald's=20
recent work to add contol over previous plot windows, would it be
make sense to modify this so that
=09set term x11 <n> raise
would leave the current terminal window unchanged?  As it stands,
if you use this command to raise an old window then you lose your
connection to the current window.

=09Ethan

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

arrow head adjustment

[Daniel J S. <dan...@ie...>]

Did anyone have any ideas for getting the
width of a line in terms of plot units from the
terminal?

Dan

[Fwd: Re: new command: raise]

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>If gnuplot is being used interactively, I would think raising windows on
>user request is a task well outside gnuplot's domain --- that's what you
>have a GUI with a window manager for.
>

Oh, and yes it is the job of the GUI panel, dock, or whatever
to be well organized.  To me, that is the fastest way to find and
raise a window.

I point out that having this control in Gnuplot is of some use
in cases where there is an application utilizing Gnuplot through
a pipe.  Say I write a GUI-based app for processing and
managing images, waveforms, or what have you.  If my app
has some kind of menu where I can select files or whatnot,
one of the functions may be to bring that waveform to the
front of the screen, enlarge the window, close the window,
etc.

Dan




-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: new command: raise

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Thu, 4 Dec 2003, Petr Mikulik wrote:
>
>  
>
>>Often I need to raise terminal windows (or multiple windows in X11)
>>covered by other windows on the desktop (editor, console, ...), for
>>which I had to do "replot" -- but that doesn't work with inline data,
>>with multiple open gnuplot_x11 windows etc.
>>    
>>
>
>I don't see how it can be a good idea to have a gnuplot-internal command
>to raise a graph window to the front.
>
>If gnuplot is being used interactively, I would think raising windows on
>user request is a task well outside gnuplot's domain --- that's what you
>have a GUI with a window manager for.
>
>If gnuplot is non-interactive (scripted or redirected), I don't think the
>script has any business actively raising windows except when they're first
>created or the plot actually changed.  Not unless gnuplot is the only
>program displaying visible windows at a given time.  And maybe not even
>then.  There must have been a reason X11 has option -noraise to avoid
>that, right?
>

I sort of agree with Hans on this one, and the reason is because of
the Gnuplot paradigm which seems to be that plot commands get
sent to terminals in a unidirectional way.

There was discussion on the list about making the plots in Gnuplot
internally more object oriented so that old plots could be replotted
without having to reissue all the necessary commands.  If that were
to become the new paradigm then I would say that having a dedicated
"raise" command might fit, but as it stands probably not.

That doesn't mean a convenient "raise" isn't a good idea, because
it is, and it's something I would find useful.  I would say such a thing
really should be part of the "set term", if anywhere, if the behavior
can be tweeked such that "set term x11 44 raise" would raise the
window.  I realize the option doesn't actually raise the window immediately,
only upon plotting... and I guess these are mutually exclusive things, 
i.e., that
one might want to just raise the window now to be able to see it and not
necessarily to keep raising to the front upon plot in the future.

Could a solution be to add several more options that control the
window?  Instead of just "close" how about

{close | front | back | minimize | maximize | fullscreen}

But again, the idea of how to handle the effect of these on the
current plot hangs out there.  I would say that these should _not_
change the current plot number, but I realize that that is potentially
confusing as it seems to violate the current documentation a bit.

Dan

Re: new command: raise

[Hans-Bernhard B. <br...@ph...>]

On Thu, 4 Dec 2003, Petr Mikulik wrote:

> Often I need to raise terminal windows (or multiple windows in X11)
> covered by other windows on the desktop (editor, console, ...), for
> which I had to do "replot" -- but that doesn't work with inline data,
> with multiple open gnuplot_x11 windows etc.

I don't see how it can be a good idea to have a gnuplot-internal command
to raise a graph window to the front.

If gnuplot is being used interactively, I would think raising windows on
user request is a task well outside gnuplot's domain --- that's what you
have a GUI with a window manager for.

If gnuplot is non-interactive (scripted or redirected), I don't think the
script has any business actively raising windows except when they're first
created or the plot actually changed.  Not unless gnuplot is the only
program displaying visible windows at a given time.  And maybe not even
then.  There must have been a reason X11 has option -noraise to avoid
that, right?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: new command: raise

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Thursday 04 December 2003 13:38, Ethan Merritt wrote:
>  
>
>>>will change the current plot to 100.  But should
>>>	 set term x11 105 raise
>>>actually change the current plot number, or should
>>>it just raise that plot (if it exists) and not change the plot?
>>>      
>>>
>>The latter, definitely.
>>    
>>
>
>Oops.  I see now that this would specifically contradict 
>what the current documentation states.  Sigh.
>

If it is a portion of the documentation that has just been
added, I think changing the documentation and behavior
of "close" for "set term" would be fine.

>Maybe we could change the syntax of these new options to
>	set term x11 {{close|raise} {<x>}}
>That is, a terminal number immediately following the
>'close' or 'raise' indicates that this command leaves
>the current terminal unchanged.  While
>	set term x11 <x> raise
>would continue to set the current window to <x> and flag it
>to raise again on every new plot, as it does now.
>
>Seems kind of confusing.  Let me try again....
>Petr proposed
>	'raise' or 'raise one' 
>and I protested that it was not necessarily clear which
>terminal was involved.  How about modifying this to
>	'{raise|close} term x11 <x>'
>
>I'm not sure either raise or close belongs in a 'set ...'
>command anyhow, since it's a one-time action rather
>than a continuing property.
>  
>

At first I didn't catch your meaning, but now I think
I see what you are saying.  By your thinking, then,
'title "plot title"' would stay with the 'set term ...'
command because that is still setting a _property_
of the window.  "raise" and "close" are basically
arranging the desktop and do not constitute a
property.  They would have no effect on the current
plot.  (Unless of course the current plot is one that
was closed, in which case it goes to the most
recently created, if I recall correctly.)

That's fine with me so long as others don't feel
dedicating an instruction for a rather limited purpose
is too much.  I'd say then deactivate the "raise" and
"close" commands and its documentation if the
Gnuplot build is configured such that a windows-based
terminal is not compiled into the executable.  I.e.,

#if defined(X11) || defined(OS2) || defined(Windows)
close and raise command code
#endif



Dan

Re: new command: raise

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

On Thursday 04 December 2003 13:38, Ethan Merritt wrote:
> > will change the current plot to 100.  But should
> >=09 set term x11 105 raise
> > actually change the current plot number, or should
> > it just raise that plot (if it exists) and not change the plot?
>
> The latter, definitely.

Oops.  I see now that this would specifically contradict=20
what the current documentation states.  Sigh.

Maybe we could change the syntax of these new options to
=09set term x11 {{close|raise} {<x>}}
That is, a terminal number immediately following the
'close' or 'raise' indicates that this command leaves
the current terminal unchanged.  While
=09set term x11 <x> raise
would continue to set the current window to <x> and flag it
to raise again on every new plot, as it does now.

Seems kind of confusing.  Let me try again....
Petr proposed
=09'raise' or 'raise one'=20
and I protested that it was not necessarily clear which
terminal was involved.  How about modifying this to
=09'{raise|close} term x11 <x>'

I'm not sure either raise or close belongs in a 'set ...'
command anyhow, since it's a one-time action rather
than a continuing property.











> And now that I look, I see that your earlier patch does not
> behave this way.  But it ought to.
> =09set term x11 101 close
> should close window 101 but leave the current window
> unchanged.  Do you want to make that change, or should I?
>
> > I tend to use the Gnome desktop panel for raising
> > the windows.  (The problem is if one starts to get too
> > many plots open it is difficult to remember in which
> > order they came and the plot number never seems
> > to appear in the little panel icon because it is "Gnuplot #"
>
> That sounds like a bug in Gnome.  I don't think we should
> worry about modifying gnuplot just to correct for poor
> window managers.   KDE and CDE both show the plot title
> correctly in the corresponding window icon.
> (Let the flamewars begin :-)

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: new command: raise

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

On Thursday 04 December 2003 13:06, Daniel J Sebald wrote:
> I think the "set term ..." approach is better, but there
> could be some confusion about it.  Typing
>
> set term x11 100
>
> will change the current plot to 100.  But should
>=09 set term x11 105 raise
> actually change the current plot number, or should
> it just raise that plot (if it exists) and not change the plot?

The latter, definitely.
And now that I look, I see that your earlier patch does not
behave this way.  But it ought to.
=09set term x11 101 close
should close window 101 but leave the current window
unchanged.  Do you want to make that change, or should I?

> I tend to use the Gnome desktop panel for raising
> the windows.  (The problem is if one starts to get too
> many plots open it is difficult to remember in which
> order they came and the plot number never seems
> to appear in the little panel icon because it is "Gnuplot #"

That sounds like a bug in Gnome.  I don't think we should
worry about modifying gnuplot just to correct for poor
window managers.   KDE and CDE both show the plot title
correctly in the corresponding window icon.
(Let the flamewars begin :-)

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: new command: raise

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Thursday 04 December 2003 10:31, Petr Mikulik wrote:
>
>  
>
>>Solution: new command "raise" (abbreviated "ra"). Enclosed is an
>>implementation for OS/2 PM and Windows terminals.
>>    
>>
>
>Your patch calls driver-specific routines directly from the core code
>in command.c.  Doesn't that break all sorts of things?  What if your
>current terminal type is something other than the windows or OS2
>terminal? 
>
>I would think such a command would have to be implemented either
>as a new driver entry point  (term->raise)(win_number), or via a new
>option to `set term`.  
>
>  
>
>>Could somebody contribute X11 code?
>>Note: proposed is "raise one" command for x11, which would raise just
>>that one currently "set term"ed window, instead of all windows.
>>    
>>
>
>Wouldn't it be better to handle this as in Daniel Sebald's recent patch to
>communcate with previously opened X windows?
>	set term x11 <win#> raise
>The command is already accepted by the current syntax and parser.
>We just need to force an immediate "raise" event if the window already exists.
>I'll have a look - it sounds easy enough.
>

Ethan, Petr added this code to CVS so you should
be able to work from there.

I think the "set term ..." approach is better, but there
could be some confusion about it.  Typing

set term x11 100

will change the current plot to 100.  But should

set term x11 105 raise

actually change the current plot number, or should
it just raise that plot (if it exists) and not change the
current plot?

The only thing about the "set term ..." approach
is that it is slightly long for doing a raise.  Raising
is one of those commands that is more useful for
fluent use of Gnuplot when there are a lot of plots
open and you are working away.  So it would nice
for such a command to be short.

I tend to use the Gnome desktop panel for raising
the windows.  (The problem is if one starts to get too
many plots open it is difficult to remember in which
order they came and the plot number never seems
to appear in the little panel icon because it is "Gnuplot #"
and there is never enough room for the number...
The most recent version of Gnome may have fixed
this.  It seems to place all windows launched from
the same process under one selectable menu.)

Dan

Re: new command: raise

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

On Thursday 04 December 2003 10:31, Petr Mikulik wrote:

> Solution: new command "raise" (abbreviated "ra"). Enclosed is an
> implementation for OS/2 PM and Windows terminals.

Your patch calls driver-specific routines directly from the core code
in command.c.  Doesn't that break all sorts of things?  What if your
current terminal type is something other than the windows or OS2
terminal?=20

I would think such a command would have to be implemented either
as a new driver entry point  (term->raise)(win_number), or via a new
option to `set term`. =20

> Could somebody contribute X11 code?
> Note: proposed is "raise one" command for x11, which would raise just
> that one currently "set term"ed window, instead of all windows.

Wouldn't it be better to handle this as in Daniel Sebald's recent patch t=
o
communcate with previously opened X windows?
=09set term x11 <win#> raise
The command is already accepted by the current syntax and parser.
We just need to force an immediate "raise" event if the window already ex=
ists.
I'll have a look - it sounds easy enough.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

new command: raise

[Petr M. <mi...@ph...>]

Often I need to raise terminal windows (or multiple windows in X11) covered
by other windows on the desktop (editor, console, ...), for which I had to
do "replot" -- but that doesn't work with inline data, with multiple open
gnuplot_x11 windows etc.

Solution: new command "raise" (abbreviated "ra"). Enclosed is an
implementation for OS/2 PM and Windows terminals. Could somebody contribute
X11 code?

Note: proposed is "raise one" command for x11, which would raise just that
one currently "set term"ed window, instead of all windows.

Well, I hope, you will like it too, so I can committ it afterwards...

---
Petr Mikulik

Re: strange auto tic behavior in 3.8j with timeseries data

[Hans-Bernhard B. <br...@ph...>]

On Mon, 1 Dec 2003, Kelley, Scott wrote:

> In order to using scalable png's, 

What's a "scalable png"?  PNG is just as scalable or not as any other
pixel-based file format.  Which means: hardly at all.

> I just installed gnuplot 3.8j onto a Redhat7.2 box.  I'm trying to plot
> timeseries data. The autofreq's xtics are not behaving right (i.e. like
> they did under gnuplot 3.7).

I'm afraid "like 3.7 did" is not a particularly precise description of
"behaving right".  To put it mildly.  Timeseries autoticking in 3.7 worked
more by lucky happenstance than by design.  In particular, it quite
reliably broke on Intel FPUs because of rounding problems, as soon as any
compiler optimization was allowed, because it tried to apply *decimal*
based auto-ticking to time data, which don't adhere to decimal system in
any way.

This area has been rewritten almost completely since 3.7.  Responsibility
for it is mine, so I'll try to see how this can be fixed.

> They go to hour intervals well before they should.  And (even worse) the
> x axis gets stretched to be an hour, even if the data only covers part
> of the hour.  35 minutes seems to be about the point the problem
> manifests.

36 minutes, actually ;-)  That's 12 times 3 minutes, and that's the actual
threshold the observed behaviour relies on.  An easier way to reproduce
the problem is:

	set ydata time
	set format y '%H:%M:%S'
	p [1e4 : 1e4 + 36*60 -1] x

As given, you get 3-minute major tic intervals.  Remove the "-1", and you
get 1 hour.  I'm not entirely sure why it behaves this way --- the key
function in charge of this, quantize_time_tics() returns a quite
reasonable 5 minutes as the tic interval for an axis 36 minutes long.
The bug seems to happen in the communication between it and 
'time_tic_just' which decides on axis endpoints for the plot.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

strange auto tic behavior in 3.8j with timeseries data

[Kelley, S. <Sco...@di...>]

In order to using scalable png's, I just installed gnuplot 3.8j onto a =
Redhat7.2 box.  I'm trying to plot timeseries data.

The autofreq's xtics are not behaving right (i.e. like they did under =
gnuplot 3.7).

They go to hour intervals well before they should.  And (even worse) the =
x axis gets stretched to be an hour, even if the data only covers part =
of the hour.  35 minutes seems to be about the point the problem =
manifests.

Any ideas ?  My attempt to force expected behavior with various xtic and =
mxtics options have not worked.


Example -

set xdata time
set xtics rotate
set timefmt  "%Y-%m-%d %H:%M:%S"
set format x "%Y-%m-%d %H:%M:%S"
set terminal png small
set output "broke.png"
plot "broke.csv" using 1:3 with lines
set output "works.png"
plot "works.csv" using 1:3 with lines


broke.csv
2003-11-25 14:20:00, 1
2003-11-25 14:30:00, 10
2003-11-25 14:56:00, 1

works.csv
2003-11-25 14:20:00, 1
2003-11-25 14:30:00, 10
2003-11-25 14:55:00, 1

--=20
Scott Kelley | Disney Enterprise Services