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