Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2003-12-04 18:31:45
Attachments:
raise-03.diff.gz
|
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. Solution: new command "raise" (abbreviated "ra"). Enclosed is an implementation for OS/2 PM and Windows terminals. Could somebody contribute X11 code? Note: proposed is "raise one" command for x11, which would raise just that one currently "set term"ed window, instead of all windows. Well, I hope, you will like it too, so I can committ it afterwards... --- Petr Mikulik |
|
From: Ethan M. <merritt@u.washington.edu> - 2003-12-04 19:15:49
|
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. Your patch calls driver-specific routines directly from the core code in command.c. Doesn't that break all sorts of things? What if your current terminal type is something other than the windows or OS2 terminal?=20 I would think such a command would have to be implemented either as a new driver entry point (term->raise)(win_number), or via a new option to `set term`. =20 > Could somebody contribute X11 code? > Note: proposed is "raise one" command for x11, which would raise just > that one currently "set term"ed window, instead of all windows. Wouldn't it be better to handle this as in Daniel Sebald's recent patch t= o communcate with previously opened X windows? =09set term x11 <win#> raise The command is already accepted by the current syntax and parser. We just need to force an immediate "raise" event if the window already ex= ists. I'll have a look - it sounds easy enough. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2003-12-04 20:49:57
|
Ethan Merritt wrote: >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. >> >> > >Your patch calls driver-specific routines directly from the core code >in command.c. Doesn't that break all sorts of things? What if your >current terminal type is something other than the windows or OS2 >terminal? > >I would think such a command would have to be implemented either >as a new driver entry point (term->raise)(win_number), or via a new >option to `set term`. > > > >>Could somebody contribute X11 code? >>Note: proposed is "raise one" command for x11, which would raise just >>that one currently "set term"ed window, instead of all windows. >> >> > >Wouldn't it be better to handle this as in Daniel Sebald's recent patch to >communcate with previously opened X windows? > set term x11 <win#> raise >The command is already accepted by the current syntax and parser. >We just need to force an immediate "raise" event if the window already exists. >I'll have a look - it sounds easy enough. > Ethan, Petr added this code to CVS so you should be able to work from there. I think the "set term ..." approach is better, but there could be some confusion about it. Typing set term x11 100 will change the current plot to 100. But should set term x11 105 raise actually change the current plot number, or should it just raise that plot (if it exists) and not change the current plot? The only thing about the "set term ..." approach is that it is slightly long for doing a raise. Raising is one of those commands that is more useful for fluent use of Gnuplot when there are a lot of plots open and you are working away. So it would nice for such a command to be short. I tend to use the Gnome desktop panel for raising the windows. (The problem is if one starts to get too many plots open it is difficult to remember in which order they came and the plot number never seems to appear in the little panel icon because it is "Gnuplot #" and there is never enough room for the number... The most recent version of Gnome may have fixed this. It seems to place all windows launched from the same process under one selectable menu.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2003-12-04 21:39:00
|
On Thursday 04 December 2003 13:06, Daniel J Sebald wrote: > I think the "set term ..." approach is better, but there > could be some confusion about it. Typing > > set term x11 100 > > will change the current plot to 100. But should >=09 set term x11 105 raise > actually change the current plot number, or should > it just raise that plot (if it exists) and not change the plot? The latter, definitely. And now that I look, I see that your earlier patch does not behave this way. But it ought to. =09set term x11 101 close should close window 101 but leave the current window unchanged. Do you want to make that change, or should I? > I tend to use the Gnome desktop panel for raising > the windows. (The problem is if one starts to get too > many plots open it is difficult to remember in which > order they came and the plot number never seems > to appear in the little panel icon because it is "Gnuplot #" That sounds like a bug in Gnome. I don't think we should worry about modifying gnuplot just to correct for poor window managers. KDE and CDE both show the plot title correctly in the corresponding window icon. (Let the flamewars begin :-) --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2003-12-04 22:09:20
|
On Thursday 04 December 2003 13:38, Ethan Merritt wrote:
> > will change the current plot to 100. But should
> >=09 set term x11 105 raise
> > actually change the current plot number, or should
> > it just raise that plot (if it exists) and not change the plot?
>
> The latter, definitely.
Oops. I see now that this would specifically contradict=20
what the current documentation states. Sigh.
Maybe we could change the syntax of these new options to
=09set term x11 {{close|raise} {<x>}}
That is, a terminal number immediately following the
'close' or 'raise' indicates that this command leaves
the current terminal unchanged. While
=09set term x11 <x> raise
would continue to set the current window to <x> and flag it
to raise again on every new plot, as it does now.
Seems kind of confusing. Let me try again....
Petr proposed
=09'raise' or 'raise one'=20
and I protested that it was not necessarily clear which
terminal was involved. How about modifying this to
=09'{raise|close} term x11 <x>'
I'm not sure either raise or close belongs in a 'set ...'
command anyhow, since it's a one-time action rather
than a continuing property.
> And now that I look, I see that your earlier patch does not
> behave this way. But it ought to.
> =09set term x11 101 close
> should close window 101 but leave the current window
> unchanged. Do you want to make that change, or should I?
>
> > I tend to use the Gnome desktop panel for raising
> > the windows. (The problem is if one starts to get too
> > many plots open it is difficult to remember in which
> > order they came and the plot number never seems
> > to appear in the little panel icon because it is "Gnuplot #"
>
> That sounds like a bug in Gnome. I don't think we should
> worry about modifying gnuplot just to correct for poor
> window managers. KDE and CDE both show the plot title
> correctly in the corresponding window icon.
> (Let the flamewars begin :-)
--=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2003-12-04 22:56:52
|
Ethan Merritt wrote:
>On Thursday 04 December 2003 13:38, Ethan Merritt wrote:
>
>
>>>will change the current plot to 100. But should
>>> set term x11 105 raise
>>>actually change the current plot number, or should
>>>it just raise that plot (if it exists) and not change the plot?
>>>
>>>
>>The latter, definitely.
>>
>>
>
>Oops. I see now that this would specifically contradict
>what the current documentation states. Sigh.
>
If it is a portion of the documentation that has just been
added, I think changing the documentation and behavior
of "close" for "set term" would be fine.
>Maybe we could change the syntax of these new options to
> set term x11 {{close|raise} {<x>}}
>That is, a terminal number immediately following the
>'close' or 'raise' indicates that this command leaves
>the current terminal unchanged. While
> set term x11 <x> raise
>would continue to set the current window to <x> and flag it
>to raise again on every new plot, as it does now.
>
>Seems kind of confusing. Let me try again....
>Petr proposed
> 'raise' or 'raise one'
>and I protested that it was not necessarily clear which
>terminal was involved. How about modifying this to
> '{raise|close} term x11 <x>'
>
>I'm not sure either raise or close belongs in a 'set ...'
>command anyhow, since it's a one-time action rather
>than a continuing property.
>
>
At first I didn't catch your meaning, but now I think
I see what you are saying. By your thinking, then,
'title "plot title"' would stay with the 'set term ...'
command because that is still setting a _property_
of the window. "raise" and "close" are basically
arranging the desktop and do not constitute a
property. They would have no effect on the current
plot. (Unless of course the current plot is one that
was closed, in which case it goes to the most
recently created, if I recall correctly.)
That's fine with me so long as others don't feel
dedicating an instruction for a rather limited purpose
is too much. I'd say then deactivate the "raise" and
"close" commands and its documentation if the
Gnuplot build is configured such that a windows-based
terminal is not compiled into the executable. I.e.,
#if defined(X11) || defined(OS2) || defined(Windows)
close and raise command code
#endif
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2003-12-05 22:36:52
Attachments:
x11_raise.patch
|
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 |
|
From: Petr M. <mi...@ph...> - 2003-12-06 13:53:51
|
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 |
Thanks for helping keep SourceForge clean.
X