Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-25 18:03:56
|
I'm getting tired of going through the SourceForge patches interface, so I'm pulling this over to normal Email. Timoth=E9e wrote> >So the trick can be : >* check for WINDOWID, if it is set go on and use the x11 code But you can't use the existing code, because as you point out yourself the external program gnuplot_x11 is not running if the current terminal is set to wx or pm. And if you pull the code out of gnuplot_x11 and put it in=20 the core code, well.. that's crazy. There should be no X dependence in the core code. Particularly if we all switch over and use the wxWidgets terminal, since we wouldn't even need to build in the x11 terminal at all :-) :-) >* if WINDOWID is not set, do : > HSWITCH hswitch =3D WinQuerySwitchHandle(0,getpid()); > then check for errors with WinGetLastError, which would =20 > mean that the console window is not managed by PM, and > continue with WinSwitchToProgram if it's ok. WINDOWID not set can mean many things. It certainly is not proof that you are not running on x11. Let me give you a real-world example, one that I encounter almost every day. I work from home in the evening, but often log in to the lab computers to do so. In that case I am=20 running in an xterm session *on my home computer*, from which I have used ssh to log in to a lab computer. If I need to check a job result quickly, I will run gnuplot on the lab computer with the display set back to my home machine. But there is no WINDOWID in gnuplot's environment because it is not running on the same machine as the window it is running in. =20 =46urthermore, even when sitting at my desk in the lab, I often ssh to other machines and use gnuplot over the ssh link. Again WINDOWID does not exist, or if it does it points to a window on the wrong X-server. =20 This whole mechanism *DOES NOT WORK* in the general case, and by that I mean in my normal daily use. Petr:=20 You obviously are running gnuplot in a certain configuration where this "raise window XXX" makes sense, so you think everything is functions reasonably. But it doesn't. Really it doesn't. I think we should remove it and try to find a different way of doing what you want. Can we step back and start over again with a clear=20 statement of what is the capability that you need? Maybe it requires a Raise event and maybe it doesn't. Labels? Spatial proximity? Tabbed windows?=20 Color-coded windows? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-04-25 18:12:22
|
> I think we should remove it and try to find a different way > of doing what you want. It should work as it works now. Thus: if you run gnuplot on the computer you sit at, the spacebar raises the gnuplot console. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-25 18:33:18
|
On Tuesday 25 April 2006 11:12 am, Petr Mikulik wrote: > It should work as it works now. > > Thus: if you run gnuplot on the computer you sit at, the spacebar raises the > gnuplot console. Try this: $ ssh localhost $ gnuplot gnuplot> set term x11 gnuplot> plot x You will see the plot as normal, assuming you have ssh-tunneling enabled for X. But the spacebar will not work, because your terminal and your plot window are using different X-display paths. Same machine, same executable, but a different connection path for X. So it really is not a question of where you are sitting, or which machine gnuplot is running on. You are relying on a fragile mechanism that happens to work on a common configuration. But "common" is a very long way from universal. As I said, I use gnuplot + x11 every day, and every day at least some of those uses do not follow the model you are assuming. If the feature is truely useful, then let us try to find a way to make it work for more cases than it does now. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-04-26 17:27:53
Attachments:
essai.sh
|
> You are relying on a fragile mechanism that happens to > work on a common configuration. But "common" is a very long > way from universal. As I said, I use gnuplot + x11 every day, > and every day at least some of those uses do not follow > the model you are assuming. If the feature is truely useful, > then let us try to find a way to make it work for more > cases than it does now. > > -- > Ethan A Merritt There is something basically strange in this feature : it involves to control a console, which is not guaranteed to be in a managed window, except on Windows. Currently, we rely on WINDOWID for xterm and xterm-like, with a special case for konsole, because Petr has been willing to implement it. This implies to link 'something' with Xlib. I have found another poor alternative : using xterm control sequences. If you look at this page : http://www.xfree86.org/snapshot/ctlseqs.html or http://www.isri.unlv.edu/~slumos/hacks/xtctl , you will find that xterm understand the sequence "=1B[5t" as "raise the window", when xterm is in VT100 mode (Does it mean that it won't work if xterm is in a different mode ? I'm not sure of this.) For example, try the attached script (where I replaced 5 by 6) from a xterm : it will lower the window. That means that we can use something like system(echo -n "<something>") t= o handle this instead of linking with Xlib. Of course, it may not work on other terminals (gnome ?, rxvt ?). It does not work on konsole, but we already have a special case for konsole, using dcop. In any case, the current patch has a drawback : it relies on the processing of terminal events by the core, so as far as I understand, the spacebar would only work when the interactive terminal is the one currently active in gnuplot. This may be considered as a regression compared to the current behaviour. Petr, as you seem to be the only one using it, do you think it is a regression ? On the short-run, I may let it in the wxWidgets terminal as it is currently : has to be linked with Xlib (or gdk, as it is already needed for raise_plot_window_but_don_t_give_it_the_focus ), or Windows.h (not a problem), or os2.h (not a problem either). Any other idea ? Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-26 19:27:55
|
On Wednesday 26 April 2006 10:27 am, Timoth=C3=A9e Lecomte wrote: > I have found another poor alternative : using xterm control sequences. > [...] the "<esc>[5t" as "raise the window" when xterm is in VT100 mode= =20 > (Does it mean that it won't work if xterm is in a different mode ? Correct. It does not work if you switch to Tek mode. Probably no one uses Tek mode any more, but then again not everyone is using a vt100-style xterm in the first place. The KDE and Gnome terminals may be more common. =20 > On the short-run, I may let it in the wxWidgets terminal as it is > currently : has to be linked with Xlib (or gdk, as it is already needed > for raise_plot_window_but_don_t_give_it_the_focus ), or Windows.h (not a > problem), or os2.h (not a problem either). It is of course OK for an outboard (external) terminal driver to link against its own support libraries. =20 > Any other idea ? Give up on the whole idea of a generic mechanism for raising the console. It was not well thought out to begin with, and in fact is not even a well-defined operation. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-04-26 18:26:41
|
> On Wednesday 26 April 2006 10:27 am, Timoth=C3=A9e Lecomte wrote: >> On the short-run, I may let it in the wxWidgets terminal as it is >> currently : has to be linked with Xlib (or gdk, as it is already neede= d >> for raise_plot_window_but_don_t_give_it_the_focus ), or Windows.h (not= a >> problem), or os2.h (not a problem either). > > It is of course OK for an outboard (external) terminal driver to link > against its own support libraries. Note that currently, the wxWidgets terminal is not external, i.e. it is compiled in the main executable, so the latter is linked with wxWidgets, cairo, and friends. >> Any other idea ? > > Give up on the whole idea of a generic mechanism for raising the consol= e. > It was not well thought out to begin with, and in fact is not even a > well-defined operation. I second this, and here are some extra arguments : * it will make the bindings system more consistent, as the spacebar will be completely treated as other keys (as the discussed patch was supposed to do) * it will make the spacebar be a valid key to return from a pause (it is not the case on X11 unless you have set the ctrlq resource) * it won't break old scripts as it is only an interactive feature If we finally choose this alternative, I would also drop the bound betwee= n 'q' and 'close this window' : * it is the role of the window manager to close the window, usually alt-F= 4 already does it * it will make the bindings system completely consistent if 'q' is part o= f it (not the case on X11 unless you set the ctrlq resource) * again, it won't break old scripts as it is only an interactive feature With the wxWidgets terminal, we introduce a brand-new terminal with a different visual aspect, so it is the right time to make these changes if we can agree that they make sense. Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-04-26 18:45:38
|
Timoth=E9e Lecomte wrote: >=20 >>>Any other idea ? >> >>Give up on the whole idea of a generic mechanism for raising the consol= e. >>It was not well thought out to begin with, and in fact is not even a >>well-defined operation. It's a reasonable feature to want in some way. That is, "I have this plo= t and I want to know where the console is that it originated from". (But= right, if there is some networking to outside computers and back into an= X window, then it makes no sense.) I suppose the X11 manager would be j= ust as good for finding this console. Even still, as this currently works on my X11 system the space bar doesn'= t even "raise the console"; it merely gives the console focus. So, one p= resses the space bar on top of a plot and can type a command to regenerat= e a plot. It works, but if there is some other window originally obscuri= ng the console, one can't see the letters as typed which is somewhat dodg= y, because then you are forced to go back to the windowing menu bar anywa= y. Furthermore, wouldn't it be prefered that if one typed a space in the plo= t in question then entered a command that it would be the plot in which t= he space bar was typed that will change (i.e., an inherent "set term x11 = #")? >=20 >=20 > I second this, and here are some extra arguments : > * it will make the bindings system more consistent, as the spacebar wil= l > be completely treated as other keys (as the discussed patch was suppose= d > to do) > * it will make the spacebar be a valid key to return from a pause (it i= s > not the case on X11 unless you have set the ctrlq resource) > * it won't break old scripts as it is only an interactive feature >=20 > If we finally choose this alternative, I would also drop the bound betw= een > 'q' and 'close this window' : This doesn't have the networking problem that Ethan described, but if Alt= -F4 works that's good. But I can also see the argument of keeping 'q' as= close because then it remains consistent for gnuplot no matter what plat= form you move to, say temporarily. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-26 19:53:36
|
On Wednesday 26 April 2006 11:54 am, Daniel J Sebald wrote: > But I can also see the argument of keeping 'q' as close because > then it remains consistent for gnuplot no matter what platform > you move to, say temporarily. The consistency I want is among all windows currently on my screen, whatever program they might belong to. If tomorrow I use some other computer or desktop where the "close window" hotkey is <ctrl-z> rather than <alt-F4>, that's annoying but at least it's a global rule. If every application has its own set of bindings, I am bound to type the wrong thing to the wrong window and close something I didn't intend. So if people want the ability to bind "q" to "quit" or "close window", fine. But it should not be hard-wired; it should be just one more "bind" command. Mea culpa. I was the one that added a special exception X-resource to make the hard-wired key <ctrl-q> rather than <q>. That was a hack rather than a proper fix. Making it a configurable binding is a much cleaner solution. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-04-26 20:05:08
|
Ethan Merritt wrote: > On Wednesday 26 April 2006 11:54 am, Daniel J Sebald wrote: > > >>But I can also see the argument of keeping 'q' as close because >>then it remains consistent for gnuplot no matter what platform >>you move to, say temporarily. > > > The consistency I want is among all windows currently on my screen, > whatever program they might belong to. If tomorrow I use > some other computer or desktop where the "close window" > hotkey is <ctrl-z> rather than <alt-F4>, that's annoying > but at least it's a global rule. If every application has > its own set of bindings, I am bound to type the wrong thing > to the wrong window and close something I didn't intend. > > So if people want the ability to bind "q" to "quit" or > "close window", fine. But it should not be hard-wired; > it should be just one more "bind" command. I can go along with that. Just put the bind commands in one's .gnuplot file and problem solved. Dan |
|
From: <tim...@en...> - 2006-04-26 20:15:19
|
> Even still, as this currently works on my X11 system the space bar does= n't > even "raise the console"; it merely gives the console focus. So, one > presses the space bar on top of a plot and can type a command to > regenerate a plot. It works, but if there is some other window origina= lly > obscuring the console, one can't see the letters as typed which is > somewhat dodgy, because then you are forced to go back to the windowing > menu bar anyway. Hmm... It may not be what you wanted to say, but we can take that as an extra argument to remove the feature, i.e .there's another obstacle that makes it unreliable : the focus-stealing-prevention mechanism that is activated by default on several desktops. > Furthermore, wouldn't it be prefered that if one typed a space in the p= lot > in question then entered a command that it would be the plot in which t= he > space bar was typed that will change (i.e., an inherent "set term x11 #= ")? That's an interesting idea, which goes along with the fact that the multiple_plot_windows feature is currently very limited (i.e. only one really active window). > It's a reasonable feature to want in some way. That is, "I have this p= lot > and I want to know where the console is that it originated from". (But > right, if there is some networking to outside computers and back into a= n X > window, then it makes no sense.) I suppose the X11 manager would be ju= st > as good for finding this console. That makes me think of a different approach to associate a console window and a plot window : make the prompt and the window title change accordingly. Advantage : both of them are really managed by gnuplot, so that is reliable and cross-platform. Drawback : not as straightforward, For example, the first instance of gnuplot would have the prompt "gnuplot>", and the window would be entitled "gnuplot", a second instance could have the prompt "gnuplot(2)>", and the window would be entitled "gnuplot(2)", etc. Many programs I know are able to recognize if an instance is already running. So I guess we could be able to do it too, and to use this information to change the prompt. Is that satisfying ? Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-04-26 20:29:01
|
Timoth=E9e Lecomte wrote: > Hmm... It may not be what you wanted to say, but we can take that as an > extra argument to remove the feature, i.e .there's another obstacle tha= t > makes it unreliable : the focus-stealing-prevention mechanism that is > activated by default on several desktops. Just saying the current implementation isn't super useful. But a focus-s= tealing-prevention is also problematic. > That makes me think of a different approach to associate a console wind= ow > and a plot window : make the prompt and the window title change > accordingly. >=20 > Advantage : both of them are really managed by gnuplot, so that is > reliable and cross-platform. > Drawback : not as straightforward, >=20 > For example, the first instance of gnuplot would have the prompt > "gnuplot>", and the window would be entitled "gnuplot", a second instan= ce > could have the prompt "gnuplot(2)>", and the window would be entitled > "gnuplot(2)", etc. >=20 > Many programs I know are able to recognize if an instance is already > running. So I guess we could be able to do it too, and to use this > information to change the prompt. >=20 > Is that satisfying ? Right now in Gnome I see that if I have two versions of gnuplot and gnupl= ot_x11, the windows created for the two different gnuplot_x11 are combine= d in the same menu group; so yeah that could be useful. (Not something I= 'm pining for, though.) Dan |
|
From: Petr M. <mi...@ph...> - 2006-04-27 06:21:38
|
>>> Give up on the whole idea of a generic mechanism for raising the console.
>>> It was not well thought out to begin with, and in fact is not even a
>>> well-defined operation.
The current spacebar is an operation which works well on "single-user" OS/2,
Windows, and Linux. In the latter, there are many X11 window managers that
can be set up into a dozen of behaviours, and you can set them up so the
current spacebar operation is canceled by the window manager. But then it is
not the private problem of gnuplot.
If you do some other tricks with X11 (logging into other servers, tunnelling
your X11 protocol), then it may not work, as you have noticed.
Actually ... I've just tried to ssh' -X to our server from Konsole, run
xterm, run gnuplot, plot x, spacebar, and gnuplot pops up! So it should work
also for you, why not?
> Even still, as this currently works on my X11 system the space bar doesn't
> even "raise the console"; it merely gives the console focus.
In all my environments it was always doing both...
>> * it will make the spacebar be a valid key to return from a pause (it is
>> * it won't break old scripts as it is only an interactive feature
>> If we finally choose this alternative, I would also drop the bound between
>> 'q' and 'close this window' :
OK with me, but let those chars to be "bind" by default.
> there's another obstacle that makes it unreliable : the
> focus-stealing-prevention mechanism that is activated by default on
> several desktops.
In recent versions of KDE, you must set "control center => windows behaviour
=> advanced => protection level against stealing (??? or somehow like that)
=> None". This info should probably go into "help mouse".
In summary, there are two ways what to do:
1. No major changes
wxterminal copies the raising code from gclient, gplt_x11 and wgraph,
or
the code is moved into mousecmn.c and to be called from the above sources
2. Major changes
Let 'q' and ' ' be "bind"able. Needs routines raise_gnuplot_console and
term->quit_window. This would need the new API for interactive terminals.
If somebody wants to improve windows changes in some X11 combinations (as I
did for KDE, for example), he can contribute it to the appropriate place of
code, independently of the above ways.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-26 20:29:34
|
On Wednesday 26 April 2006 01:15 pm, you wrote: > > For example, the first instance of gnuplot would have the prompt > "gnuplot>", and the window would be entitled "gnuplot", a second instance > could have the prompt "gnuplot(2)>", and the window would be entitled > "gnuplot(2)", etc. That's a window-naming policy, and can already be done in KDE. In fact I think it defaults to that. For instance, when I open new terminal windows they receive banner titles "Xterm <2>" "Xterm <3>" and so on. Anyhow gnuplot already allows you to specify a window title, so all that's wanting is a way to change the prompt. myname = "Foo" set term x11 title myname set prompt myname."> " > Many programs I know are able to recognize if an instance is already > running. Probably safer to let the application do the naming. Pure numbers are not the most informative identifiers. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-04-26 21:24:46
|
> Anyhow gnuplot already allows you to specify a window title, > so all that's wanting is a way to change the prompt. > myname = "Foo" > set term x11 title myname > set prompt myname."> " > >> Many programs I know are able to recognize if an instance is already >> running. > > Probably safer to let the application do the naming. > Pure numbers are not the most informative identifiers. Do you mean : "Probably safer to let the _user_ do the naming" ? |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-26 21:36:27
|
On Wednesday 26 April 2006 02:24 pm, Timoth=E9e Lecomte wrote: > > Anyhow gnuplot already allows you to specify a window title, > > so all that's wanting is a way to change the prompt. > > myname =3D "Foo" > > set term x11 title myname > > set prompt myname."> " > > > >> Many programs I know are able to recognize if an instance is already > >> running. > > > > Probably safer to let the application do the naming. > > Pure numbers are not the most informative identifiers. >=20 > Do you mean : "Probably safer to let the _user_ do the naming" ? Well no, I meant the application. My thought was that if you ran applications A, B, and C simultaneously (or three instances A, B, and C of a single application like Octave), then the piped output from these apps to three separate gnuplot instances would respectively start with a line "myname =3D 'A'", "myname =3D 'B', or "myname =3D 'C'". I suppose in this case you could say the application *is* the user. But I still don't have a good picture of the environment Petr is working in that pops up all these disconnected windows, so perhaps this wouldn't help any.=20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-04-26 21:53:03
|
> On Wednesday 26 April 2006 02:24 pm, Timoth=E9e Lecomte wrote: >> > Anyhow gnuplot already allows you to specify a window title, >> > so all that's wanting is a way to change the prompt. >> > myname =3D "Foo" >> > set term x11 title myname >> > set prompt myname."> " >> > >> >> Many programs I know are able to recognize if an instance is alread= y >> >> running. >> > >> > Probably safer to let the application do the naming. >> > Pure numbers are not the most informative identifiers. >> >> Do you mean : "Probably safer to let the _user_ do the naming" ? > > Well no, I meant the application. My thought > was that if you ran applications A, B, and C simultaneously > (or three instances A, B, and C of a single application like > Octave), then the piped output from these apps to three separate > gnuplot instances would respectively start with a line > "myname =3D 'A'", "myname =3D 'B', or "myname =3D 'C'". > I suppose in this case you could say the application *is* the user. Ok, I get your point. Well, everything is already in place for such a behaviour. Timoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-27 06:46:21
|
On Wednesday 26 April 2006 11:21 pm, you wrote: > Actually ... I've just tried to ssh' -X to our server from Konsole, > run xterm, run gnuplot, plot x, spacebar, and gnuplot pops up! ^^^^^^^^^^ > So it should work also for you, why not? That worked because you ran the xterm on the remote machine, so it used the same display path as the gnuplot session. But if you do it that way then the entire management of the xterm goes over the net so it is relatively slow. This faster way is to ssh in and run gnuplot immediately (no remote xterm). That way the xterm window is local to your seat, and fast, but the gnuplot process is on the remote machine and uses a different server path. Since the konsole window and the plot window use different server paths, the "raise by window_id" cannot work. > In summary, there are two ways what to do: > 1. No major changes > wxterminal copies the raising code from gclient, gplt_x11 and wgraph, > or > the code is moved into mousecmn.c and to be called from the above sources I prefer the "bind" option. > 2. Major changes > Let 'q' and ' ' be "bind"able. Needs routines raise_gnuplot_console yes. > term->quit_window. but we already support this, at least for x11, with no special API. > This would need the new API for interactive terminals. I disagree. The "close existing window" function is already present in the current terminal interface (see x11), and the raise_console function is not a terminal interface issue at all. At first I was confused, and thought that the core code should call such a term->raise_console() routine. But this doesn't work for all the reasons we went through earlier in this thread. So raise_console() would have to be a core routine. > If somebody wants to improve windows changes in some X11 combinations (as I > did for KDE, for example), he can contribute it to the appropriate place of > code, independently of the above ways. The "appropriate place" is exactly what we are struggling to find. It is not obvious where that place is. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2006-04-27 16:39:15
|
> machine and uses a different server path. Since the konsole window and > the plot window use different server paths, the "raise by window_id" > cannot work. Yes, they run in windows launched from two different machines, in my simple explanation (1st time I see "different server paths"). >> This would need the new API for interactive terminals. > > I disagree. The "close existing window" function is already > present in the current terminal interface (see x11), and the > raise_console function is not a terminal interface issue at all. > So raise_console() would have to be a core routine. Does it work for the other interactive terminals as well? I thought your wish for the API was that gnuplot is not linked against Xlib. > At first I was confused, and thought that the core code should call > such a term->raise_console() routine. But this doesn't work for all > the reasons we went through earlier in this thread. This could be for supporting "bind" commands to " " and "q": term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, " ", ..._RAISE_CONSOLE, 0) term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, " ", ..._RAISE_CONSOLE, 1) term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, "q", ..._CLOSE_WINDOW, 0) term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, "q", ..._CLOSE_WINDOW, 1) >> If somebody wants to improve windows changes in some X11 combinations (as I >> did for KDE, for example), he can contribute it to the appropriate place of >> code, independently of the above ways. > > The "appropriate place" is exactly what we are struggling to find. You have shown that on X11 it does not work when running gnuplot and its plot in windows belonging to different computers. > It is not obvious where that place is. BTW, I asked several times how to do the same Konsole "sheet flipping" for the gnome-terminal, but no one answered. So gnome-native users cannot enjoy the full functionality (but it works with a single gnome-terminal sheet/card). --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-04-27 17:46:31
|
On Thursday 27 April 2006 09:39 am, Petr Mikulik wrote: > > machine and uses a different server path. Since the konsole window and > > the plot window use different server paths, the "raise by window_id" > > cannot work. > > Yes, they run in windows launched from two different machines, in my simple > explanation (1st time I see "different server paths"). Sorry for any confusion; I don't know what the correct terminology is. But it is not a question of which machine the executable is running on. What matters is the X-server instance to which it is connected. ssh-tunneling is a common example of why this is an issue, but multi-head graphics setups are another example. X-terminals (archaic, yes, but we still have some) are another example. > >> This would need the new API for interactive terminals. > > > > I disagree. The "close existing window" function is already > > present in the current terminal interface (see x11), and the > > raise_console function is not a terminal interface issue at all. > > So raise_console() would have to be a core routine. > > Does it work for the other interactive terminals as well? > I thought your wish for the API was that gnuplot is not linked against Xlib. I would prefer that, yes. But during the course of this discussion I have come to think there is no other way to correctly implement a "raise console" function. It can only be done by the core code. Having realized that, my first preference is not to do it at all. I fully understand that you disagree with me. But if are to make this change, let us at least try to do it as cleanly as possible. It will definitely simplify the hot key processing in gnuplot_x11, since it no longer needs to special case these exceptions to the general key binding mechanism. I am not familiar with the windows/pm code, but I would think the same is true there. I am thinking that the cleanest way is to create a new core routine raise_console(). It will be ugly, because it will have conditional code for all the various platforms. Remember that this conditional code must match the type of the console window, not the type of the plot window. So, for instance, there should be no need for any wxWidgets special code. If you are running 'set term wx' under windows you will need the windows code; it you are running 'set term wx' under X you will need the X code. I further suggest that this whole mechanism be under the control of a configuration option, e.g. ./configure --with-console-management Those of us who have no need for it can omit it from the configuration. > > At first I was confused, and thought that the core code should call > > such a term->raise_console() routine. But this doesn't work for all > > the reasons we went through earlier in this thread. > > This could be for supporting "bind" commands to " " and "q": > > term->interactive(TERM_INTERACTIVE_BIND_HOTKEY, " ", ..._RAISE_CONSOLE, 0) ?? But the 'bind' mechanism is implemented in the core routines, and once set up it applies equally to all terminals used in a gnuplot session. You will break this if you try to make it a terminal entry point instead. Switching terminals would lose your key bindings. For that matter, closing and re-opening an x11 plot window would lose your key bindings. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-04-27 22:27:10
|
>> Does it work for the other interactive terminals as well? >> I thought your wish for the API was that gnuplot is not linked against Xlib. > > I would prefer that, yes. But during the course of this discussion I > have come to think there is no other way to correctly implement a > "raise console" function. It can only be done by the core code. > > But if are to make this change, let us at least try to do it as > cleanly as possible. It will definitely simplify the hot key > processing in gnuplot_x11, since it no longer needs to special > case these exceptions to the general key binding mechanism. > I am not familiar with the windows/pm code, but I would think > the same is true there. > > I am thinking that the cleanest way is to create a new core routine > raise_console(). All that is fine with me. Considering gnuplot under X11, the binary will have to be linked against -lX11, but as I can see it adds just 200 B of code, thus this is not an issue. --- PM |
|
From: Bastian M. <bma...@we...> - 2006-04-28 09:34:50
|
Petr Mikulik wrote: >>> Does it work for the other interactive terminals as well? >>> I thought your wish for the API was that gnuplot is not linked=20 >>> against Xlib. >> >> I would prefer that, yes. But during the course of this discussion I >> have come to think there is no other way to correctly implement a >> "raise console" function. It can only be done by the core code. >> >> But if are to make this change, let us at least try to do it as >> cleanly as possible. It will definitely simplify the hot key >> processing in gnuplot_x11, since it no longer needs to special >> case these exceptions to the general key binding mechanism. >> I am not familiar with the windows/pm code, but I would think >> the same is true there. >> >> I am thinking that the cleanest way is to create a new core routine >> raise_console(). >=20 > All that is fine with me. I agree. >=20 > Considering gnuplot under X11, the binary will have to be linked agains= t=20 > -lX11, but as I can see it adds just 200 B of code, thus this is not an= =20 > issue. >=20 For the standard OS/2 build we will have to leave out the linkage requirement against X11 though. Too many systems do not have X11 installe= d. Could we move the raise_console() code into a new executable instead? --=20 Bastian M=E4rkisch Physikalisches Institut, Universit=E4t Heidelberg |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-28 15:22:43
|
On Friday 28 April 2006 02:34 am, Bastian Maerkisch wrote: > For the standard OS/2 build we will have to leave out the linkage > requirement against X11 though. Too many systems do not have X11 installed. > Could we move the raise_console() code into a new executable instead? The new code must of course be subject to the same configuration tests and conditional compilation as we have now. As to putting it in a separate executable, that's what we have now already. I don't see how changing from one external executable to another helps in any way. I'm still in favor of ./configure --enable-console-raise so I can turn it off permanently at build time. OS/2 could do the same if it is problematic. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-04-28 17:06:18
|
> On Friday 28 April 2006 02:34 am, Bastian Maerkisch wrote:
>> For the standard OS/2 build we will have to leave out the linkage
>> requirement against X11 though. Too many systems do not have X11
>> installed.
>> Could we move the raise_console() code into a new executable instead?
>
> The new code must of course be subject to the same
> configuration tests and conditional compilation as we have now.
It is worth noting that there is already (a) special case(s) to
distinguish a OS/2 console and a Xterm-like console for other purposes.
For example, in readline.c (866) :
#ifdef OS2
/* We need to call different procedures, dependent on the
session type: VIO/window or an (XFree86) xterm */
static char
os2_getch() {
static int IsXterm =3D 0;
static int init =3D 0;
if (!init) {
if (getenv("WINDOWID")) {
IsXterm =3D 1;
}
init =3D 1;
}
if (IsXterm) {
return ansi_getc();
} else {
return msdos_getch();
}
}
#endif /* OS2 */
If this code has worked for years, and it is likely to be the case (
*_getch() is used for each input character), we can be confident that a
test for WINDOWID is enough to know who manages the console.
Timoth=E9e
|
|
From: Bastian M. <bma...@we...> - 2006-05-08 23:51:34
Attachments:
spacebar_new_os2.diff
|
Here's a modified version of Timoth=E9e latest patch which fixes the OS/2 part. Moreover it introduces a new define WANT_X11_RAISE to be able to deactivate the X11 dependant stuff. This will be defined when X11 is defined, but is normally undefined on OS/2 to avoid the linkage requirement againt libX11. I also removed some "%lu" formats left in a printf statement when removin gnuplotXID. I'll post it on the list since I cannot attach files on sourceforge. Bastian |
