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

Re: color box positioning for splot

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

On Fri, 12 Dec 2003, Petr Mikulik wrote:

> Colorbox should stay at that position where it is for the default view.

Then it mustn't be output in terms of data coordinates, but in "view
coordinates" or even directly in screen coordinates.  The difference
between the two is the matrix multiplication carried out by functions
map3d_xy() and map3d_xyz() in util3d.c.

So you would have to avoid calling either of those (or referring to
trans_mat, for that matter) in draw_color_smooth_box().

A little background: 3D plots have four distinct coordinate systems, not
just the three we expose to the user in the 2D case:

	first/second  (i.e. data coordinates)
	graph         
	screen

In 3D, the processing goes like this:

data points ---- (ranges, map_x3d() & friend) ----> normalized coordinates
  
normalized coordinates (set view, map3d_xyz()) ---> view coordinates

view coordinates ----> ([xy]scaler, [xy]middle) ---> terminal coordinates

Of these, the "normalized" most closely match the 2D "graph" coordinates,
and terminal coordinates are essentially the same as "screen".  View 
coordinates fall somewhere between those. 

For reference, the results in default 'set view' for the corners of the
colour box are:

res = {0.70899346400575247, -0.14693375672974057, 2.1484375602010033,
  6.1537877952320801e-313}
res = {0.77827549630850756, 0.49701905283832915, 2.1484375602010033,
  6.1537877952320801e-313}

(It's the first two coordinates only, in each case, that count).
Apply scaler and middle and use those as cb_{x|y}_{from|to}, and you 
should be in business.

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

Re: color box positioning for splot

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

Petr Mikulik wrote:

>I'd like to ask here again: Could somebody have a look how to fix position
>of the color box when a surface is rotated (by mouse or by 'set view'
>commands). It's fine for 'set view map', but not for other views. E.g.
>	set pm3d
>	splot x*y
>.. and rotate the surface by mouse
>
>Colorbox should stay at that position where it is for the default view.
>
>I had a look to the source of 3d positions, but I failed to figure it out. I
>hope somebody will be more lucky.
>
>This fix would be nice for the forthcoming 4.0 release...
>

I can understand wanting this change, as you and I talked about this
outside the list and I want to see this fixed as much as anyone, but
I've feared the "fix a few things first" approach to making a release.

There are a couple things about this.  You and I agreed that a nicer
control of the colorbox position is in order.  Also, I made a comment
a while back that I think there should be more consistency amoung
2d and 3d plots.  The "image" patch allows a colorbox for 2d plots,
similar to "map" mode for 3d.  The code is fine for the 2d colorbox in
the patch, but the organization is a kludge.  It is in two different 
locations
for 2d and 3d, and the two are done in different ways.  My opinion is
to combine the two in a consistent fashion, reusing the colorbox
placement code.  It is something outside of the plot (or it should be,
unlike the quick fix of the 3d plot method) and will be the same for
2d/3d.  It simply takes up some space and repositions the plotting area
of the actual plot.

If there is to be any progress and things done "right", then one has to
allow major changes and allow the code to destabilize for a while.
One can put some effort into fixing and debugging that, then after 4.0
if there seems to be a need for colorboxes in 2d plots then one may
end up reprogramming some of it.

Dan

color box positioning for splot

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

I'd like to ask here again: Could somebody have a look how to fix position
of the color box when a surface is rotated (by mouse or by 'set view'
commands). It's fine for 'set view map', but not for other views. E.g.
	set pm3d
	splot x*y
.. and rotate the surface by mouse

Colorbox should stay at that position where it is for the default view.

I had a look to the source of 3d positions, but I failed to figure it out. I
hope somebody will be more lucky.

This fix would be nice for the forthcoming 4.0 release...

---
Petr Mikulik

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: test palette rgb

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

> 'help test palette' says
>   The optional parameter, a permutation of letters rgb, determines the sequence of
>   r,g,b profiles drawn one after the other --- try this yourself for `set palette
>   gray`. The default sequence is rgb.
>
> When I try this with the x11, post or png terminals, I do not see any difference in
> the resulting plot no matter whether I say  rgb or grb or brg or whatever.
> The order of labels on the curves change, but that is the only thing different.
>
> Am I doing something wrong, or is this a bug, or am I not understanding
> what the output is supposed to show?

Try this:

set palette gray
test palette rgb
pause
test palette rbg
pause
test palette bgr

...it shows different things.
If it not clear from the docs, you can modify it.

---
Petr Mikulik

Re: test palette rgb

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

Petr:

'help test palette' says
  The optional parameter, a permutation of letters rgb, determines the se=
quence of
  r,g,b profiles drawn one after the other --- try this yourself for `set=
 palette
  gray`. The default sequence is rgb.

When I try this with the x11, post or png terminals, I do not see any dif=
ference in=20
the resulting plot no matter whether I say  rgb or grb or brg or whatever=
=2E
The order of labels on the curves change, but that is the only thing diff=
erent.

Am I doing something wrong, or is this a bug, or am I not understanding
what the output is supposed to show?

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

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

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

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

version

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

  >

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

I could write a patch this weekend some time.

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

I would say that the "raise" isn't essential to a release.  It could 
remain as a patch.  Since it will likely be a small patch, my guess is 
that it won't be as susceptible to changes in CVS and won't need 
updating so much.

But certainly, moving toward a 4.0 release is a good idea.  (If I 
understand correctly, 4.0 will be an "official" release, not a beta sort 
of thing.)

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

Well, I guess this was my idea.  But I myself am not totally sold on 
this.  Doing this is sort of a big change, or addition, to the paradigm, 
and I'm afraid that it may take things down a path of people requesting 
additional support, and soon we have something that is more than 
intended and perhaps totally different from a better scheme.  (Maybe the 
scheme Hans discussed where there are multiple plots.**)  I guess it is 
the syntax that is really the "standard" in Gnuplot [Changing things 
behind the scenes isn't always so crucial... "ignore that man behind the 
curtain" ;)], and 'raise' seems the logical choice.  But still.  I see 
the beta releases as being ways of putting those patches that are 
clearly desirable into the code then allowing developers to try them 
out, suggest changes and knock the rough edges off of them.  [Case in 
point is the image patch.  Having Petr's and Ethan's feedback has made 
it much nicer than what I originally did.]  I would say aim for 4.0, tag 
the version, then start introducing some of the new ideas and let things 
destabilize a bit.

Dan

** But that is a BIG change.  It would require saving the actual plot 
commands in a linked list, not too bad.  But also it would require the 
capturing of the state of the system "set variables" before any change 
in the terminal window.  I assume that would mean organizing all those 
variables into a nice table format.

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:

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

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

[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