gnuplot-beta

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

[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: 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

[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

[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>]

On Tuesday 09 December 2003 00:35, Petr Mikulik wrote:
> Look this way: Origin and similar graph apps have a common "desktop" fo=
r
> all windows, so raising Origin will raise its desktop with all windows.

I see.  If you want this kind of behaviour from gnuplot under X11, then
I think what you really want is not a new command-line option but instead
a new "master window" of some sort that has an associated X-event
handler for expose+focus events.  When this window is raised, then the
event handler would go through the list of all other gnuplot-associated
windows and raise them too.  You could, for example, make this master
window a small always-on-top icon, and click on it to pop up all the othe=
rs.=20
That should be possible, I think;  x11.trm would spawn off this extra=20
process at the same time it spawns the first instance of gnuplot_x11.=20

To be honest, I dislike like that behaviour of programs whether
under MSWin or under X.  The application program almost never knows
better than I do as to which windows I would like to have on top.
But it does seem to be common.

> Most graphical apps have "Tile" and "Cascade" functions.

??  Sorry, I am not familiar with these.  What do these do?

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

Re: new command: raise

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

> > 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.
>
> I see.  If you want this kind of behaviour from gnuplot under X11, then
> I think what you really want is not a new command-line option but instead
> a new "master window" of some sort that has an associated X-event
> handler for expose+focus events.  When this window is raised, then the
> event handler would go through the list of all other gnuplot-associated
> windows and raise them too.  You could, for example, make this master
> window a small always-on-top icon, and click on it to pop up all the others.
> That should be possible, I think;  x11.trm would spawn off this extra
> process at the same time it spawns the first instance of gnuplot_x11.

I think my "raise" command is much easier than this new proposal.


> To be honest, I dislike like that behaviour of programs whether
> under MSWin or under X.  The application program almost never knows
> better than I do as to which windows I would like to have on top.
> But it does seem to be common.

Like the flamewar of StarOffice with single or no common desktop.

> > 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.


***

This discussion takes us to new dimensions of gnuplot -- and the end of year
is almost here ...  thus I would propose the following:

- add this command "raise" as I proposed, with a simple X11 implementation
as proposed

- release gnuplot 3.8k next week, and gnuplot 4.0 in January

- do all these nice interactive terminal changes afterwards, with enough
time for discussions


What do you think about this?

---
Petr Mikulik

Re: new command: raise

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

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


> 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

command.c:

+#ifdef OS2
+    pm_raise_terminal_window();
+#endif
+#ifdef X11
+    x11_raise_terminal_window(  ...an option for 1 window only...);
+    /* if (one_window) { only one } */
+#endif


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)

I wish to see your nice patch :-))

---
Petr Mikulik

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

Re: new command: raise

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

> >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.

Whether it is nice or not, it works without touching other terminals. For
example, "set mouse" commands are available also as menu items in the
Presentation Manager terminal. The only way to do this without touching
other terminals was send_gpPMmenu() in mouse.c, instead of a new term API
in pm.trm.


>  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 good idea.

There can be something like
	term->do_some_command(SOME_COMMAND_RAISE, &option1, &option2, NULL);


> >+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?

Whatever you may like can be there.
Just notice that "^" is not sent as a new "pipe command", but as a suboption
for a "special" command.


> I originally proposed that there also be functionality for
> minimizing, maximizing, etc.  Ethan said this is bloat,

Currently, I don't see any reason for these additional commands -- they can
be achieved anywhere but an icon on the titlebar.

But how would you launch it?
How to do it portable?

set term interactive close
set term interactive 4 maximize

?? rather than
set term [pm or x11 or windows or ...]

---
Petr Mikulik

Re: new command: raise

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

Petr Mikulik wrote:

>>How about a 'v' for "lower".  If "raise #" makes sense as a
>>command, then wouldn't "lower #" find a similar sort of
>>usefulness?
>>    
>>
>
>Whatever you may like can be there.
>Just notice that "^" is not sent as a new "pipe command", but as a suboption
>for a "special" command.
>

Oh.

>>I originally proposed that there also be functionality for
>>minimizing, maximizing, etc.  Ethan said this is bloat,
>>    
>>
>
>Currently, I don't see any reason for these additional commands -- they can
>be achieved anywhere but an icon on the titlebar.
>

I don't either any longer.

>But how would you launch it?
>How to do it portable?
>
>set term interactive close
>set term interactive 4 maximize
>
>?? rather than
>set term [pm or x11 or windows or ...]
>

I was thinking a

"set term x11 interactive" would make x11 or whatever the
interactive terminal.  Then any of the "window manager"
terminal commands

raise
minimize
maximize
close
hide

would be directed to the interactive terminal as opposed to the
plot terminal.  Of course, they will often be the same terminal.

That would be too many commands for what it provides.

Dan

Re: new command: raise

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

On Tuesday 09 December 2003 10:08, Daniel J Sebald wrote:
> Petr Mikulik wrote:
> >It seems like most people agree that this patch is useful! Great!

I cannot comment on how useful it is under Windows, OS2, etc.
If you need it, then fine.

But I am not yet convinced it is useful in an X11 environment.
There are better solutions available at a higher level (the window
manager).

I do take your point that the window title is not always obvious.=20
We have a "set term ... title 'foo'" option, but the user may not always
think to take advantage of it.  Maybe we should add  an auto-title=20
feature, similar to the auto-titling of plots themselves?
If the user has set an explicit title, then use that one.  If the user ha=
s
not set a window title, then set it to match the title of the current plo=
t
displayed in the window. Does that sound reasonable?

> >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

This approach runs roughshod over the existing terminal API and=20
coding philosophy, at least as I understand it.  Driver functions should =
be
exposed via the driver's TERM_TABLE, and called in a driver-independent
fashion.  Yes, we have some legacy code that does not operate this way
but do we really need to create more bad examples?

> (*term_interactive)->attributes()
>
> "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?)

I don't think so.  The PNG driver itself doesn't know anything about
the fact that it is talking through a pipe to a display program.  So it
has no way of knowing that it is pseudo-interactive.  Anyhow the
mechanism we have now for opening such a pipe:
=09set output '| display png:-'
offers no way to return a process identifier for the display program,
so we cannot send any signals to it, nor do we have any way that I
can think of from inside gnuplot to identify it to the X window manager.

But I also don't think it is necessary.  I am perfectly happy to just
click on the appropriate icon or taskbar entry to raise the window
if I need to.  If appropriate I can even "pin" it via always-on-top so
that it stays visible at all times.

--=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 Tuesday 09 December 2003 10:08, Daniel J Sebald wrote:
>  
>
>>Petr Mikulik wrote:
>>    
>>
>>>It seems like most people agree that this patch is useful! Great!
>>>      
>>>
>
>I cannot comment on how useful it is under Windows, OS2, etc.
>If you need it, then fine.
>
>But I am not yet convinced it is useful in an X11 environment.
>There are better solutions available at a higher level (the window
>manager).
>
>I do take your point that the window title is not always obvious. 
>We have a "set term ... title 'foo'" option, but the user may not always
>think to take advantage of it.  Maybe we should add  an auto-title 
>feature, similar to the auto-titling of plots themselves?
>
>

>If the user has set an explicit title, then use that one.  If the user has
>not set a window title, then set it to match the title of the current plot
>displayed in the window. Does that sound reasonable?
>

Not a bad idea, but I don't know what syntax would be used.
Also, it might be nice to have a special character for
the plot number, e.g., "set termtitle 'G #'". With that example,
one could save space on the menu panel and actually see the
number. (I pointed out that the new Gnome GUI has a better
setup now, I think.) A # would mean put the plot window's
number in the title. A ## would mean put a # in the title.
Or vice versa.


Dan

Re: new command: raise

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

On Tuesday 09 December 2003 06:53 pm, Daniel J Sebald wrote:
> Ethan Merritt wrote:

> >If the user has set an explicit title, then use that one.  If the user has
> >not set a window title, then set it to match the title of the current plot
> >displayed in the window. Does that sound reasonable?
>
> Not a bad idea, but I don't know what syntax would be used.

No syntax. Just do it as the normal behaviour.
Or, since this is X after all, make it an Xresource:

Gnuplot*autotitle:	on

-- 
Ethan A Merritt
eme...@es...

Re: new command: raise

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

> I cannot comment on how useful it is under Windows, OS2, etc.
> If you need it, then fine.
>
> But I am not yet convinced it is useful in an X11 environment.
> There are better solutions available at a higher level (the window
> manager).

I think I have written here several times why these solutions do not work,
or they would work only with some additional effort.


> I do take your point that the window title is not always obvious.
> We have a "set term ... title 'foo'" option, but the user may not always
> think to take advantage of it.  Maybe we should add  an auto-title
> feature, similar to the auto-titling of plots themselves?
> If the user has set an explicit title, then use that one.  If the user has
> not set a window title, then set it to match the title of the current plot
> displayed in the window. Does that sound reasonable?

This discussion is nice -- but it is not a replacement for "raise", that's
just an additional feature.

> But I also don't think it is necessary.  I am perfectly happy to just
> click on the appropriate icon or taskbar entry to raise the window
> if I need to.  If appropriate I can even "pin" it via always-on-top so
> that it stays visible at all times.

BTW, there are experimental workstations with X11 where there is no "nice"
window manager to use those tricks with titles.

---
Petr Mikulik

Re: new command: raise

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

I have done a little bit of research into the X11 protocols,
and here is what I have found.

The X11 standard strongly discourages client programs from
trying to control window placement or position in the stack
(i.e. raise/lower) except by making a request of the window=20
manager.  Basically this means that if you can't do what you
want in the window manager, then you can't do it from the=20
application program either.  The application can set a
"please raise me" attribute for a window, but the window
manager decides whether or not to pay any attention to this.

I think the bottom line is that gnuplot_x11 is free to mark
all its windows as belonging to the same "window_group"
if it wants to, but whether this has the effect that Petr wants
(raise them all at once) will depend entirely on the window
manager.

Let me quote from a couple of relevant sections from
Scheifler & Gettys "X Window System" reference manual.

<begin quote>
4.1.5 Configuring the Window
[...]
=09Convention
Clients that use a ConfigureWindow request to request a change
in their position in the stack should do so using None in the sibling
field. [...] Doing this is deprecated, and window managers are in any
case free to position windows in the stack as they see fit.
<end quote>=20


<begin quote>
4.1.11 Window Groups
A set of top-level windows that should be treated from the
user's point of view as related (even though they may belong
to a number of clients) should be linked together using the
window_group field of the WM_HINTS structure. [...]
It is up to the window manager to determine the policy for
treating the windows in a group. At present, there is no way
for a client to request a group, as opposed to an individual,
operation.
<end quote>

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

Re: new command: raise

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

> I have done a little bit of research into the X11 protocols,
> and here is what I have found.
>
> The X11 standard strongly discourages client programs from
> trying to control window placement or position in the stack
> (i.e. raise/lower) except by making a request of the window
> manager.

It would say that's a complete nonsense. *I* want to decide myself what I
want to have a look to, not sb else...

In particular:

1. "plot x" => gnuplot raises its x11 window. No problem  with any
window manager.

2. Further, hitting <space> in graphical window => gnuplot's console is
raised.  No problem.

So I really don't know what do you mean in your letter.

> application program either.  The application can set a
> "please raise me" attribute for a window, but the window
> manager decides whether or not to pay any attention to this.

Raising window is an X11 function .. and window manager is also just an X11
application too...

> treating the windows in a group. At present, there is no way
> for a client to request a group, as opposed to an individual,
> operation.

Thus, the client apps has to raise its window one after the other, as I
have proposed.

---
Petr Mikulik

Re: new command: raise

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

Petr Mikulik wrote:

>>I have done a little bit of research into the X11 protocols,
>>and here is what I have found.
>>
>>The X11 standard strongly discourages client programs from
>>trying to control window placement or position in the stack
>>(i.e. raise/lower) except by making a request of the window
>>manager.
>>    
>>
>
>It would say that's a complete nonsense. *I* want to decide myself what I
>want to have a look to, not sb else...
>
>In particular:
>
>1. "plot x" => gnuplot raises its x11 window. No problem  with any
>window manager.
>
>2. Further, hitting <space> in graphical window => gnuplot's console is
>raised.  No problem.
>
>So I really don't know what do you mean in your letter.
>

This is the problem with X11 documentation; it isn't precisely clear 
about things, neither is a good concept given.  The obvious is given and 
all the intricacies are left for us to guess...  We may be making too 
much out of this.  It may be simply that the documentation intends that 
the programmer should never directly have the window do these sorts of 
things.  Rather you should request the manager to tell the window to do 
something.  That way you avoid any conflicts in a multitasking system 
where something could happen to remove or change the window, unknown to 
the programmer.

Dan

Re: new command: raise

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

Daniel J Sebald wrote:

> Petr Mikulik wrote:
>
>>> I have done a little bit of research into the X11 protocols,
>>> and here is what I have found. 
>>

 From doing a "man XRaiseWindow" I gather that "stack" and "depth"
are in fact the same thing, i.e., "stack" pertains to the appearance on
the desktop.

There is something we need to be careful about with the "raise"
command.  Raising windows one at a time is fine; there is the
XRaiseWindow() function.  However, raising all the Gnuplot
plots at once might pose a bit of a problem.  The raise routine to be
"nice".  That is, say I make plots
1 through 8, in that order so that the linked list within gnuplot_x11
is sequential.  But then, I raise plot 1 and 2 to the front, _via the
window manager_, not via the "raise #" command.  There is no
way for gnuplot_x11 to know that that was done.  Only the window
manager knows that.  OK, I go off do something else and then type
"raise" to bring up the Gnuplot plots.  But gnuplot_x11 will go through
its list and raise them one at a time in which case plots 1 and 2 will
go back down to the bottom of the pile.  The user will not like that
and there will be complaints.

No solution is better than a bad solution in this case.  So, there
has to be a method to maintain the order as the window manager
sees it for just that group of plots associated with gnuplot_x11.
Otherwise, no go.  I'm looking to see if there is a command or
option that will raise all subwindows of a given window.  There
is a circulate command for subwindows, even that might work if
one calls circulate for the number of windows there are.  That
way all the subwindows come up eventually and maintain their
order.

Dan

Re: new command: raise

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

> There is something we need to be careful about with the "raise"
> command.  Raising windows one at a time is fine; there is the
> XRaiseWindow() function.  However, raising all the Gnuplot
> plots at once might pose a bit of a problem.  The raise routine to be
> "nice".

> No solution is better than a bad solution in this case.  So, there
> has to be a method to maintain the order as the window manager
> sees it for just that group of plots associated with gnuplot_x11.

I propose that you try to implement it, and we see how nicely it works.

> "raise" to bring up the Gnuplot plots.  But gnuplot_x11 will go through
> its list and raise them one at a time in which case plots 1 and 2 will
> go back down to the bottom of the pile.  The user will not like that
> and there will be complaints.

1. the user will know about it from the "raise" command documentation

2. he does not mind about the windows order at all if his windows do not
overlap (that's what you usually organize if you want to see of your plots
simultaneously) -- so the worries about window manager and particular order
are quite irrelevant

---
Petr Mikulik

Re: new command: raise

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

Ethan Merritt wrote:

>I have done a little bit of research into the X11 protocols,
>and here is what I have found.
>
>The X11 standard strongly discourages client programs from
>trying to control window placement or position in the stack
>(i.e. raise/lower) except by making a request of the window 
>manager.  Basically this means that if you can't do what you
>want in the window manager, then you can't do it from the 
>application program either.  The application can set a
>"please raise me" attribute for a window, but the window
>manager decides whether or not to pay any attention to this.
>
>I think the bottom line is that gnuplot_x11 is free to mark
>all its windows as belonging to the same "window_group"
>if it wants to, but whether this has the effect that Petr wants
>(raise them all at once) will depend entirely on the window
>manager.
>
>Let me quote from a couple of relevant sections from
>Scheifler & Gettys "X Window System" reference manual.
>
><begin quote>
>4.1.5 Configuring the Window
>[...]
>	Convention
>Clients that use a ConfigureWindow request to request a change
>in their position in the stack should do so using None in the sibling
>field. [...] Doing this is deprecated, and window managers are in any
>case free to position windows in the stack as they see fit.
><end quote> 
>
>
><begin quote>
>4.1.11 Window Groups
>A set of top-level windows that should be treated from the
>user's point of view as related (even though they may belong
>to a number of clients) should be linked together using the
>window_group field of the WM_HINTS structure. [...]
>It is up to the window manager to determine the policy for
>treating the windows in a group. At present, there is no way
>for a client to request a group, as opposed to an individual,
>operation.
><end quote>
>

Are "stack" and "depth" the same thing? I pointed out before that X11
seems to have a routine dedicated to raising a window, i.e., the depth
of the window in terms of visibility. All other window properties seem
to be handled by another function, and those properties seem to be all
the other items that are listed when you look at the upper-left corner
of the X11 window. The menu has "maximize", "unmaximize", "in group"...
and one labelled "depth". Honestly, I'm not an expert on what every one
of those does. But, I'm wondering if "stack" in the documentation refers
to internally how X11 arranges things in its linked list of windows,
i.e.,the order in which signals are sent around the system.

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

[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

[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

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

On Tue, 9 Dec 2003, Petr Mikulik wrote:

> > > 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?

> #ifdef X11 => X11 is interactive
> #ifdef _Windows => windows is interactive

Same here.

> 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.

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