Re: new command: raise

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

Petr Mikulik wrote:

>It seems like most people agree that this patch is useful! Great!
>

Well, luke warm it seems.  Let's mull this over a bit more
before programming a patch.

>>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.
>>    
>>
>
>Now, it does not have to be the current terminal. You can implement it
>in exactly the same way as in OS/2's PM terminal.
>
>command.h:
>+#ifdef OS2
>+extern void pm_raise_terminal_window();
>+#endif
>+#ifdef X11
>+extern void x11_raise_terminal_window(   maybe option for 1 window );
>+#endif
>

I'm not sure if I like the idea of having platform dependent functions
in the code.  The paradigm for Gnuplot, as it currently exists, is
"everything" is a terminal.  I propose adding a new terminal function
and going that route; something descriptive yet generic like

(*term_interactive)->layer()
(*term_interactive)->attributes()
(*term_interactive)->any_suggestions()

"term_interactive" is a new pointer that is associated with
the interactive terminal.  The existing "term" pointer remains
just as it is.  (Ethan, will this work for your concept of PNG,
etc. when doing research?)

This would account for characteristics of the plot that are not
a _property_ in the sense of the "set term x11 ...".  So the "raise"
of "set term x11 raise" would stay just exactly as it currently
is.  Also, most of the terminals will have this new function as
a default empty function.

>x11.trm:
>+void
>+x11_raise_terminal_window( ... )
>+{
>+    putc(SET_SPECIAL, PM_pipe);
>+    putc('^', PM_pipe); /* raise window */
>+    fflush(PM_pipe);
>+}
>.. I think it is X11_pipe or X11_ipc
>
>
>+ code in gplt_x11.c to accept and react to '^' (go through the window list
>and raise them)
>

How about a 'v' for "lower".  If "raise #" makes sense as a
command, then wouldn't "lower #" find a similar sort of
usefulness?

I originally proposed that there also be functionality for
minimizing, maximizing, etc.  Ethan said this is bloat, and
I suppose it is.  First, it is only when the window is on top
and visible that it makes sense to be messing around with
minimize/maximize, in which case those buttons are right
there on the window easily accessible.  Second, the X11
systems seems to make raising the window a special
case compared to other attributes.  Third, easy enough
to add if ever desired and won't break compatibility.

Dan