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