gnuplot-beta — Developers and beta testers of new gnuplot code

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

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

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

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

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

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

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

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

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

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

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

[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

[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

[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

[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

[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: arrow head adjustment

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

Hans-Bernhard Broeker wrote:

>>The question then is, will the terminal achieve the specified line
>>width, or will it only approximate it?  In the latter case, we are no
>>further along.
>>    
>>
>
>If the terminal doesn't do an accurate job, that's too bad.  I don't think
>it's worth bothering about such terminals in terms of how to manage nicely
>drawn arrows for them.  The risk of making already inaccurate outputs even
>worse are essentially negligible, I'd say.  If all else fails, they could
>still be fixed by reporting an effective linewidth of zero plot units, and
>thus reverting to the current behaviour.
>

That's a good idea.

Dan

Re: arrow head adjustment

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

On Sun, 7 Dec 2003, Daniel J Sebald wrote:

> In my opinion, if arrow tips were to be compensated for,
> it would be nice to have the formula at a high level  so that
> it doesn't need to be implemented multiple times in the
> various drivers.  Perhaps some drivers have an option for
> where the tip should land.  

I don't expect any of them does, at this time.  The majority of them rely
on the common fallback implementation term.c:do_arrow() for this.  It's
mainly the vector graphics file format drivers have their own
implementation.  cscope reports:

../term/debug.trm .*[^o]_arrow 245 DEBUG_arrow(sx, sy, ex, ey, head)
../term/dumb.trm .*[^o]_arrow 385 DUMB_arrow(sx, sy, ex, ey, head)
../term/eepic.trm .*[^o]_arrow 366 EEPIC_arrow(sx, sy, ex, ey, head)
../term/epslatex.trm .*[^o]_arrow 892 EPSL_arrow(xstart, ystart, xend, yend, head)
../term/fig.trm .*[^o]_arrow 771 FIG_arrow(sx, sy, ex, ey, head)
../term/gpic.trm .*[^o]_arrow 217 GPIC_arrow(sx, sy, ex, ey, head)
../term/grass.trm .*[^o]_arrow 618 GRASS_arrow(sx, sy, ex, ey, head)
../term/latex.trm .*[^o]_arrow 639 LATEX_arrow(sx, sy, ex, ey, head)
../term/latex.trm .*[^o]_arrow 650 best_latex_arrow(sx, sy, ex, ey, who, head)
../term/metafont.trm .*[^o]_arrow 466 MF_arrow(sx, sy, ex, ey, head)
../term/metapost.trm .*[^o]_arrow 675 MP_arrow(unsigned int sx, unsigned int sy, unsigned int ex, unsigned int ey, TBOOLEAN head)
../term/pstricks.trm .*[^o]_arrow 399 PSTRICKS_arrow(sx, sy, ex, ey, head)
../term/texdraw.trm .*[^o]_arrow 282 TEXDRAW_arrow(sx, sy, ex, ey, head)
../term/tgif.trm .*[^o]_arrow 569 TGIF_arrow(sx, sy, ex, ey, head)
../term/tpic.trm .*[^o]_arrow 628 TPIC_arrow(sx, sy, ex, ey, head)
../term/vws.trm .*[^o]_arrow 463 VWS_arrow(sx, sy, ex, ey, head)

To top it off, the current way arrow head options are handled is
atrocious.  There is *no* terminal API entry to pass arrow options
through, though there definitely should be.  While adding that, it
should be reasonably easy to pass on the line width to the arrow
drawing routines, too.  It *is* part of the arrow options structure,
after all.  term_api.h on arrow_style_type says:

typedef struct arrow_style_type {    /* contains all Arrow properties */
    int layer;                       /* 0 = back, 1 = front */
    struct lp_style_type lp_properties;
[...]

and the line width is part of struct lp_style_type.

> But it isn't worth doing unless there is some way of addressing
> the line width issue.  Getting back line width information might
> be tough.  However, would it be possible to slightly alter the
> terminal line command so that the line width is specified in plot
> units rather than the somewhat arbitrary "1, 2, 3, 4"?  

No.  That would break plot script compatibility, while being almost
certainly un-necessary.  As far as I'm aware, all terminal drivers already
do have default-line width == 1 terminal unit anyway (with exceptions for
the border line type that's usually 2 units wide).

> It could remain "1 2 3 4" from the users' perspective, but first
> translate those to plot units before calling the (*term)->linewidth()
> function.

That's none of the 'set term' command's business to do, nor does it have
the information needed for doing it.  I think not all terminals supporting
variable-width lines even *have* a linewidth option in their terminal
options to begin with. 

The only somewhat reasonable ways I see would be to add a new API function
term->get_linewidth() that reports the current width, in plot units, or to
append to the semantics of term->linewidth(), adding that it should modify
some global variable accordingly, which is initialized by the caller so
most implementations can remain unchanged.  This shouldn't be overly hard,
as term->linewidth() is only called in rather few places to begin with.  
According to cscope:
 
6 mouse.c      event_buttonrelease      1522 (term->linewidth) (border_lp.l_width);
7 term.c       term_apply_lp_properties  615 (*term->linewidth) (lp->l_width);
a term.c       test_term                1592 (*t->linewidth) (1.0);
b term.c       test_term                1717 (*t->linewidth) (1.0);
c term.c       test_term                1740 (*t->linewidth) ((float)(i));
d term.c       test_term                1754 (*t->linewidth) ((float)(1));

> The question then is, will the terminal achieve the specified line
> width, or will it only approximate it?  In the latter case, we are no
> further along.

If the terminal doesn't do an accurate job, that's too bad.  I don't think
it's worth bothering about such terminals in terms of how to manage nicely
drawn arrows for them.  The risk of making already inaccurate outputs even
worse are essentially negligible, I'd say.  If all else fails, they could
still be fixed by reporting an effective linewidth of zero plot units, and
thus reverting to the current behaviour.

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

Re: arrow head adjustment

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

Hans-Bernhard Broeker wrote:

>On Fri, 5 Dec 2003, Daniel J Sebald wrote:
>
>  
>
>>Did anyone have any ideas for getting the
>>width of a line in terms of plot units from the
>>terminal?
>>    
>>
>
>I don't think there is any generic way of doing that.  There's an
>awful lot of copy-pasted code in the terminal drivers which just has
>different variable names, and no generic data structure for internal 
>variables even for cases like this that could use common basic routines
>like "do_linewidth_by_saving_value()" as their term->linewidth() API
>implementation. 
>
>It may not even be the case that all relevant drivers _have_ the linewidth
>stored in any variable in the first place.  PostScript-like ones could
>just have written out a postscript command that sets the linewidth and
>forgot about it...
>
>This may need a re-design of at least the arrow-drawing part of the 
>terminal API to work it out.
>

I think your assessment is correct.

In my opinion, if arrow tips were to be compensated for,
it would be nice to have the formula at a high level  so that
it doesn't need to be implemented multiple times in the
various drivers.  Perhaps some drivers have an option for
where the tip should land.  It might be wise to see how they
all perform before concluding on the best approach.

But it isn't worth doing unless there is some way of addressing
the line width issue.  Getting back line width information might
be tough.  However, would it be possible to slightly alter the
terminal line command so that the line width is specified in plot
units rather than the somewhat arbitrary "1, 2, 3, 4"?  It could
remain "1 2 3 4" from the users' perspective, but first translate
those to plot units before calling the (*term)->linewidth()
function.  The question then is, will the terminal achieve
the specified line width, or will it only approximate it?  In the
latter case, we are no further along.

Dan

Re: arrow head adjustment

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

On Fri, 5 Dec 2003, Daniel J Sebald wrote:

> Did anyone have any ideas for getting the
> width of a line in terms of plot units from the
> terminal?

I don't think there is any generic way of doing that.  There's an
awful lot of copy-pasted code in the terminal drivers which just has
different variable names, and no generic data structure for internal 
variables even for cases like this that could use common basic routines
like "do_linewidth_by_saving_value()" as their term->linewidth() API
implementation. 

It may not even be the case that all relevant drivers _have_ the linewidth
stored in any variable in the first place.  PostScript-like ones could
just have written out a postscript command that sets the linewidth and
forgot about it...

This may need a re-design of at least the arrow-drawing part of the 
terminal API to work it out.

Re: new command: raise

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

Unfortunately, my short mail didn't present well the main idea behind.
So, here it is -- the command for raising:

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.

2. It must be portable. You should write the command and should have
   the same effect on whichever OS you work right now.
   Thus no "set term pm raise", "set term windows raise", and
   "set term x11 raise", but a single command like "raise".

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.

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


Consequently:

1. there is no need to implement it by new terminal api

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)

3. The effect of "gnuplot -raise" (again, non-portable command, see also
   OS/2 PM menu for "Always on top" vs. "set term x11 raise") does a
   completely different thing (auto raise after "(s)plot" command).

4. This "raise" is completely irrelevant to desktop manager (try to have
   a look to the window title after "plot x" on OS/2 or Windows, not to be
   so much X11 localized -- but, actually, on X11 you will see exactly the
   same window title if you launch gnuplot several times).
   Thus, on any OS, there is no way to find which gnuplot terminal window
   belongs to which gnuplot console instance. (And don't try to convince
   people to use BESTBLABLA X11 windows manager because it may have
   "some kind of such a feature" -- gnuplot is a portable tool).

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

  3 gnuplot windows is not unusual -- one experimental data, one good
  simulation, other current simulation ... or some windows from Octave...
  and then, you want to raise up just window with the raw data and that
  from octave, but you don't need to replot it (also, X11 are quite slow
  when replotting large maps, so "replot" is a waste of resources). Then
  comes a colleagues and asks you "can I see the curve we are just
  measuring ...?"

In other words, think of "raise" as of "replot" without replotting :-))

Is it now clear what's the reason and necessity for just "raise" and not
anything else?

BTW, this "raise" command implementation for OS/2 and Windows is not
in CVS, it was just attached to my email.

---
Petr Mikulik

Re: new command: raise

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

On Thursday 04 December 2003 10:31, Petr Mikulik wrote:
>
> Solution: new command "raise" (abbreviated "ra"). Enclosed is an
> implementation for OS/2 PM and Windows terminals. Could somebody
> contribute X11 code?

The attached patch does not add any commands, nor does it
change existing syntax.  Instead it causes=20
=09set term x11 <n> raise
to raise that window immediately (if it exists at all) in addition to set=
ting
the "raise" attribute for future plots in that window.

I think this is pretty harmless, though I doubt I would use it often
myself.  I agree with whoever (Dan?) pointed out that for interactive
use this is more naturally achieved just by clicking on the appropriate
icon provided by your desktop/window manager. Maybe it has a place
in scripted environments, though.

I won't put this in CVS without some feedback from you, though.
Does it achieve what you wanted?  Also, in light of Dan Sebald's=20
recent work to add contol over previous plot windows, would it be
make sense to modify this so that
=09set term x11 <n> raise
would leave the current terminal window unchanged?  As it stands,
if you use this command to raise an old window then you lose your
connection to the current window.

=09Ethan

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