#238 Bind <space> to builtin_raise in mouse.c
Currently, each interactive platform (X11, Windows,
OS2) has a separate implementation to raise the gnuplot
console window when the user presses the spacebar in
the terminal window.
This patch moves all the code to mouse.c in a new
function builtin_raise, and binds by default the empty
character (' ') to this new function as it is done for
example with 'a' and builtin_autoscale.
The bindings should work for all terminal windows so
that the spacebar will raise the console window from
any terminal window. This implies a small modification
to make all-windows bindings also work with builtin
bindings.
Motivations :
* the wxWidgets terminal will profit from this global
implementation without having to duplicate code (the
wxWidgets toolkit itself doesn't help for this task at
all).
* the spacebar will profit from all the bindings
capabilities as other keys. Without this patch, the
behaviour of the spacebar is hardcoded and can't be
changed.
Implementation tested on X11 and Windows, but not
tested on OS2, i.e. it may not compile on this
platform. Can somebody try it ?
Implementation in mouse.c and cleanup of original places (not tested on OS2)
Logged In: YES
user_id=1180072
This cannot (and does not) compile on OS/2 for (at
least) two reasons:
* On OS/2 pm and x11 terminal can be included at the same
time. But your code in mouse.c assumes that there's no
X11 terminal on OS/2.
* The OS/2 specific code which you moved from os2/gclient.c
to mouse.c must be executed from within gnupmdrv. This
is a seperate executable (like gplt_x11) which does not
include mouse.c.
I'll see if I can come up with a solution quickly.
Bastian
Logged In: YES
user_id=1333817
Bastian and I have discussed this patch offline quite a bit,
and here are the conclusions so far :
* The code I proposed can be compiled on OS/2 provided some
modifications, and can be executed by the main gnuplot
executable (i.e. it doesn't need a message loop).
* I am not clear about who manages who, as far as windowing
systems are concerned. For example :
- on Unix, X11 is supposed to do all the job
- on OS/2, according to Bastian, you can have a window
managed by the OS/2 native API, or managed by X11, and these
two seem to be mutually exclusive
- on Windows, there seems to be the same case : a window
managed by the Windows API, or by X11 via Cygwin
Currently, as far as I can tell :
- the Windows version assumes that the console window is
managed by the Windows API (and it is the case)
- if you use a X11 version under Windows with Cygwin, it
will assume that the console window is managed by the
X server
- the OS/2 version can use both the PM terminal and the X11
terminal, so :
* the PM terminal assumes that the console window is
managed by the OS/2 API
* the X11 terminal assumes that the console windows is
managed by a X server
Can somebody correct if I am wrong ? Or, if I am right, tell
me how this mess can work in practise ?
* Until now, the main executable doesn't need not linked to
X11 (even if with ./configure it is by default). Changing
this may not be desirable.
In any case, please keep in mind in your responses that this
patch is intended to have a global implementation that the
wxWidgets terminal won't have to care about.
Logged In: YES
user_id=235620
you wrote >
> Until now, the main executable doesn't need
> not linked to X11 (even if with ./configure
> it is by default).
> Changing this may not be desirable.
Sorry. I don't understand what you are saying here.
In any event, it is not true that on unix/linux the "console
window" must be managed by x11. Gnuplot runs just fine from
a true console or virtual console window. People do run it
that way (hence the svga driver). Furthermore, so far as I
can see there is nothing to stop you from running gnuplot
from a true console window and then opening up an x11 plot
window on whatever server you have DISPLAY set to. I haven't
tried it, though.
Logged In: YES
user_id=1333817
> you wrote >
>> Until now, the main executable doesn't need
>> not linked to X11 (even if with ./configure
>> it is by default).
>> Changing this may not be desirable.
>Sorry. I don't understand what you are saying here.
Oops, I submitted without reading ! I wanted to write :
Until now, the main executable doesn't need to be
linked with Xlib, even if the X11 terminal is enabled. Only
gplot_x11 need to.
./configure does put the include & linking flags with Xlib
for the main executable, but they are not needed.
> In any event, it is not true that on unix/linux the
> "console window" must be managed by x11.
> Gnuplot runs just fine from
> a true console or virtual console window.
> People do run it that way (hence the svga driver).
> Furthermore, so far as I can see there is
> nothing to stop you from running gnuplot
> from a true console window and then opening
> up an x11 plot window on whatever
> server you have DISPLAY set to. I haven't
> tried it, though.
You're right. In this case, WINDOWID is not set in the
console environment, so <spacebar> won't do anything.
Logged In: YES
user_id=235620
Comments:
(1)
--- old/docs/gnuplot.doc 2006-03-28
+++ new/docs/gnuplot.doc 2006-04-21
@@ -1750,8 +1750,8 @@
+ every real editor), except 'q' which cannot be rebound.
Actually, this is not true. In the current gnuplot you can
rebind both 'q' and ' ' in x11. I just tried it and it
works as expected in both cases. What you cannot do is bind
a key on top of the current exit hotkey. This is by default
set to 'q', but can be changed to e.g. 'ctrl-q' in the X
environment.
(2)
I very much do not like the idea of moving X11-dependent
code into mouse.c. The separation between the core gnuplot
executable and gnuplot_X11 has been clean up until now. The
only interaction is via a piped communication channel. In
fact gnuplot_x11 can be running on a different machine than
gnuplot, and may have a different X environment. So I don't
see how your proposed patch can work at all in the most
general case. I'm not sure the current code works either,
but that's a separate question.
Logged In: YES
user_id=1333817
you wrote :
> In the current gnuplot you
> can rebind both 'q' and ' ' in x11. I just
> tried it and it works as expected in both cases.
> What you cannot do is bind a key on top of the current
> exit hotkey. This is by default set to 'q',
> but can be changed to e.g. 'ctrl-q' in the X
> environment.
Two conclusions :
* The current documentation is inaccurate, and that's not my
fault ;-)
* You probably use the "-ctrlq" resource, because the
current code in gplot_x11.c definitely can't rebind ' ' when
"ctrlq" is not set.
you wrote :
> I very much do not like the idea of moving X11-dependent
> code into mouse.c. The separation between the core
> gnuplot executable and gnuplot_X11 has been clean up
> until now. The only interaction is via a piped
> communication channel.
So the question is :
How to do this cleanly, and so that the wxWidgets can use it
without duplicating code ?
> In fact gnuplot_x11
> can be running on a different machine than
> gnuplot, and may have a different X environment.
> So I don't see how your proposed patch can work
> at all in the most general case.
> I'm not sure the current code works either,
> but that's a separate question.
Again, you're right : the current code may probably not
work as expected in such a configuration.
Logged In: YES
user_id=235620
>So the question is:
>How to do this [raise the console window] cleanly,
>so that the wxWidgets can use it without duplicating code ?
IMHO (which I know Petr disagrees with) this is not worth
doing at all, and therefore the question is moot. If you
want your console window to stay on top, then mark it
"always on top" using the window property mechanism that
window managers [should] provide. I'm still in favor of
removing this spacebar hotkey altogether, or at least making
it a platform-specific option if non-x11 platforms do not
offer the equivalent of "always on top".
Having said that, it seems to me that the answer to the
question is that it would require a new terminal API entry
to do what you ask. One would define an internal routine:
void raise_console() {
if (term->raise_console)
term->raise_console();
}
And then hook this up to a new suboption of the "raise"
command and let the user bind the spacebar to it:
bind ' ' "raise console"
Note that information on which plot window generated the
event is available if necessary. See the mousing demo, for
instance.
Logged In: YES
user_id=31505
The common code, shared by independent terminal executables
as well as by the gnuplot executable, should go into
mousecmn.c. Currently there is only mousecmn.h, because no
more than definitions were needed until now, but the
reuseable code could be put there; no need for a new
terminal api.
> mark it "always on top" using the window property
mechanism that
That's NOT what the spacebar hotkey is doing.
> term->raise_console()
Hm, this could be an elegant solution... but it would rather
require the yet not existing
term_which_is_screen->interactive("raise gnuplot console")
... the hotkey must work for whichever terminal currently "set".
(Yes of course: "raise ..." => INTERACTIVE_ACTION_RAISE_...)
Logged In: YES
user_id=235620
>term_which_is_screen->interactive(INTERACTIVE_ACTION_RAISE_...)
Now I am confused. I thought the problem under discussion
was that for instance on OS2 you could have both an
OS2-mediated plot window and an x11 window. I don't know
exactly what that looks like on the screen, but .... the
term_which_is_screen->() idea misses the point, because it
might be either x11 or os2. It thought you wanted to raise
the one corresponding to whatever plot window you just hit
the spacebar in, whether or not it is the same as the
default screen terminal.
Consider the new wxt terminal type. It comes up by default
as the screen terminal, but in fact the console terminal is
an xterm. Your term_which_is_screen->() is "wxt" in this
case, right? But the x11 raise command has nothing in
particular to do with wxt. Shouldn't it be x11->() that
gets called? Except that, as I pointed out previously,
gnuplot_x11 can hypothetically be running on a different
X-server than gnuplot itself, so this isn't guaranteed to
work either.
Argh. This really is confusing. Remind me again why this
would ever be useful. You say it's NOT to keep the console
window from being covered by multiple plot windows, which
is what I previously understood. Then what is it for? Is it
so that you can start up gnuplot in parallel from 15
different terminal windows, and use this mechanism to figure
out which plot belongs to which terminal? If so, why can't
you instead open your 15 different plot windows from *one*
terminal window and track them by ID #? set term x11 1;
plot foo; set term x11 2; plot baz; set term x11 3; plot
bif; etc...
Logged In: YES
user_id=31505
> I thought the problem under discussion was that
> for instance on OS2 you could have both an
> OS2-mediated plot window and an x11 window.
Yes, and both are launched from the same gnuplot.exe.
> I don't know exactly what that looks like on the screen
E.g. like nowadays on linux launching both wxt and x11 from
the same gnuplot executable. They live together.
(X11 windows can run seamlessly on Presentation Manager
desktop, or within their own fullscreen Xserver.)
> term_which_is_screen->() idea misses the point, because
> it might be either x11 or os2.
No, it will raise the console/terminal window with
*gnuplot.exe*, not the graphics window where the spacebar
has been hit! So, it does not matter whether pm or x11 will
let the gnuplot console raise.
> Then what is it for?
Open two sessions in one KDE Konsole, or two xterms, then
run gnuplot or Octave in them, draw data (e.g. experimental
data in one, fitting in the other, ... and previous fitting
in yet another...). For a good fit, you cannot distinguish
them very well:-) so hit a spacebar and voila! you are at
the prompt where from you have plotted the graph! Try it!
Logged In: YES
user_id=1333817
>> term_which_is_screen->() idea misses the point, because
>> it might be either x11 or os2.
>
>No, it will raise the console/terminal window with
>*gnuplot.exe*, not the graphics window where the spacebar
>has been hit! So, it does not matter whether pm or x11 will
>let the gnuplot console raise.
What happens if you hit the spacebar from the x11 terminal
while gnuplot.exe is launched in an OS/2 mediated console
window ?
Logged In: YES
user_id=235620
>> term_which_is_screen->() idea misses the point,
>> because it might be either x11 or os2.
> No, it will raise the console/terminal window
> with *gnuplot.exe*, not the graphics window where
> the spacebar has been hit!
Yes, I understand that. But...
> So, it does not matter whether pm or x11 will
> let the gnuplot console raise.
It does indeed matter, because the pm terminal driver should
not be expected to know how to raise an x11 console window,
and conversely the x11 terminal should not be expected to
know how to raise an os2 console window. You would need to
send this hypothetical term->raise_console() command to the
terminal driver that matches the nature of the console
terminal, not to the one that matches GNUTERM or that
matches "current plot window".
Maybe that is what you meant by term_which_is_screen? I had
interpreted that as shorthand for "the default terminal
type, e.g. GNUTERM".
I still think the current x11 code does not work in the
general case. gnuplot sends a value of gnuplotXID, which
gnuplot_x11 will later use to send a command XMapRaised(dpy,
gnuplotXID). But there is no guarantee that the display used
by gnuplot_x11 and the display used by gnuplot itself are
the same display. If they are not the same display, then
gnuplotXID is an id in the wrong server space. So in the
general case, gnuplot_x11 could raise some random window or
no window at all, and do so on the wrong display.
Logged In: YES
user_id=31505
> What happens if you hit the spacebar from the x11 terminal
> while gnuplot.exe is launched in an OS/2 mediated console
> window?
It will raise gnuplot.exe's window it on its appropriate
desktop. (If both X11 and gnuplot.exe are running in PM or
in Xserver, it's clear, and if X11 is running under
fullscreen Xserver while gnuplot.exe is running in PM
terminal window on PM desktop (maybe difficult to image for
non-OS/2 users) it will raise it on the PM.) All these work
fine since many years ago...
Logged In: YES
user_id=31505
> I still think the current x11 code does not work
> in the general case.
Well, until now, it worked for me in all practical cases.
Yes, nothing happens under X11 if you are under different
Xservers (you cannot expect raising putty's window on
Windows by hitting a key on a distance server); if someone
knows how to fix this, I would enjoy it.
Logged In: YES
user_id=1333817
>> What happens if you hit the spacebar from the x11
>> terminal while gnuplot.exe is launched in an OS/2
>> mediated console window?
> It will raise gnuplot.exe's window it on its appropriate
> desktop. (If both X11 and gnuplot.exe are running in PM or
> in Xserver, it's clear, and if X11 is running under
> fullscreen Xserver while gnuplot.exe is running in PM
> terminal window on PM desktop (maybe difficult to image
> for non-OS/2 users) it will raise it on the PM.) All these
> work fine since many years ago...
So, if we had to write a generic function "PM_raise_console"
which could be called from any terminal (x11, pm, and maybe
wxWidgets), should it contain the current x11 code, the
current pm.trm code, or both ?
Logged In: YES
user_id=31505
> So, if we had to write a generic function
> "PM_raise_console"
> which could be called from any terminal (x11, pm,
> and maybe wxWidgets)
I think that X11_raise_console() should be used from x11 and
wxt-X11 (without change also under OS/2), and
PM_raise_console() for pm and wxt-PM terminals. (I think wxt
knows whether it is being built with the x11, pm, windows,
... toolkits).
Logged In: YES
user_id=1333817
> I think that X11_raise_console() should be used from x11 and
> wxt-X11 (without change also under OS/2), and
> PM_raise_console() for pm and wxt-PM terminals. (I think wxt
> knows whether it is being built with the x11, pm, windows,
> ... toolkits).
I am sorry to ask again, but it is still not clear... That
should not depend on wxWidgets. I guess wxWidgets is built
on top of PM, but I should not have to care because what we
are interested in is the console window, not the wxWidgets
window, right ?
So what I would like to write is more a OS2_raise_console().
Again, what would need to be in 0S2_raise_console() ? Is it
PM_raise_console(), X11_raise_console(), or both but
triggered depending on where the console is ?
Logged In: YES
user_id=31505
I guess you can compile wxWindows against PM or against Xlib
(like under Windows, where you can compile it against Win32
or against Xlib). Then, either PM_raise_... or X11_raise_...
is used (and similarly on Windows, either WIN_raise_... or
X11_raise_... is to be used).
Logged In: YES
user_id=1333817
I'm sorry, but I don't get the reason for this.
Do you assume that the console window is managed by the X
server when the x11 terminal is used, and that it is managed
by the PM api when the PM terminal is used ?
If yes, why should it be always the case ? Can't you open
gnuplot from a console managed by PM, and plot something to
a x11 window ?
Otherwise, it means that both implementations work no matter
who manages the console window. Then, why do you suggest to
to choose between PM_raise_... and X11_raise_... if both work ?
Logged In: YES
user_id=235620
But the question is not answered. How is the wx terminal (or
any other terminal) expected to know what kind of window the
gnuplot console itself is running in? That is something
known only to the gnuplot session itself, not to the
outboard drivers like gnuplot_x11 or gnupmdrv.
I am back to agreeing with Timothee's original idea, that
the only clean way is to have the core code do any such
"raise" event. But I still dislike the idea of adding x11
linkage requirements to the core executable.
My preferred solution:
Abandon this mechanism altogether.
Compromise proposal:
- Create a new terminal API term->raise_console()
implemented in pm.trm and x11.trm
- Remove the spacebar as a special-case event in
gnuplot_x11 and gnupmdrv
- Allow a "bind '<space>' raise_console" command
using the general bind hotkey mechanism
That way the core code can decide for itself (don't ask me
how!) whether it is running in an xterm or an os2 console
window or whatever, and call the appropriate driver via the
new API. No, I don't like this idea all that much, but I
like it better than the alternative.
Logged In: YES
user_id=31505
Yes, you are right. So please write an OS2_raise_...
function. Therein, there should be some mechanism
implemented to determine whether to call the PM_raise_ or
the X11_raise_ (I think that env variable WINDOWID should be
defined only in an X11-like terminal window, but not in OS/2
command prompt window).
Note: for the PM_raise_..., take the code after the
"VK_SPACE" in gclient.c.
Logged In: YES
user_id=235620
Upon further reflection, I don't think my compromise
proposal will work. Suppose gnuplot is being run from from
an xterm window, but using "set term wx" or "set term pm"
for plotting. In this case there is no instance of
gnuplot_x11 being run, so asking it to issue a "raise
window" event is not going to work. Or at the lease you will
incur a huge overhead of starting up an external process and
communicating with it via pipes just to have it issue the
one "raise" command.
But this must already be a problem in the current code for
"set term pm" from an xterm window on OS2. Is that correct,
Petr? I thought you said before that it has been working
for years...
Logged In: YES
user_id=1333817
Ok, I understand now ! Thanks for your patience, Petr.
So the trick can be :
* check for WINDOWID, if it is set go on and use the x11 code
* if WINDOWID is not set, do :
HSWITCH hswitch = WinQuerySwitchHandle(0,getpid());
then check for errors with WinGetLastError, which would
mean that the console window is not managed by PM, and
continue with WinSwitchToProgram if it's ok.
So the remaining question is : where to put this code ?
Ethan's idea to add a new terminal entry in x11.trm and
pm.trm is attractive, but it implies that these terminals
are compiled for the spacebar to work with the wxWidgets
terminal. It also implies that the corresponding executables
are running, while they should not be needed if the
wxWidgets terminal is used.