gnuplot-beta

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
>
> Are we sure that OS2 is never #defined if somebody builds the X11 version
> on OS/2?

OS2 is always #defined when compiling it with X11 (or without).
On OS/2, you can use simultaneously pm and x11 terminals. Or just one of
them. As you like. No problem.

> > #ifdef X11 => X11 is interactive
> > #ifdef _Windows => windows is interactive
>
> Same here.

Compiling with makefile.cyg or .mgw et al, only _Windows is defined, never
X11.
Compiling by cygwin using ./configure; make defines X11, but not _Windows.
These two can never work together.

> > 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.
>
> I always thought that's what one had a window manager with multiple
> (virtual) desktops for... but then again, I'm obviously spoilt by never
> having had to do actual lab work on Windows or OS/2, so far.

I use virtual desktops on OS/2 and Windows, too.
But it does not prevent you to hide windows by other windows.

---
Petr Mikulik

Re: new command: raise

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

On Wed, 10 Dec 2003, Petr Mikulik wrote:

> > > Most graphical apps have "Tile" and "Cascade" functions.
> > ??  Sorry, I am not familiar with these.  What do these do?
> 
> Wow, you have really not seen this? Even in old brave DOS Turbo Vision
> environments, Win 3.1 and anywhere else?
>   It tiles or cascades all open windows... so changes their size and
> position to fit on the desktop.

I think you're mixing up internal windows inside a larger application
window, known as MDI (for "multi-document interface"), with features of
the desktop at large.  And that's exactly what we're discussing here: your
change would have the main gnuplot instance maintain central control over
several daughter windows.  I.e. it'd make gnuplot a multiple-document
program, but without having all those daughter windows confined inside a
single "master" window.  The only Windows program I've seen behaving like
that, so far, was Borland C++ Builder 1.0, and quite a lot of people hated
it for this reason.  

As a matter of fact, "tile" and "cascade" for the desktop itself haven't
existed in Windows for a long time.  They were in Win3.1, but this feature
was removed again pretty soon after.  I don't think it's been part of
anything newer than Win95.

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

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