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 ?
Logged In: YES
user_id=1180072
Last night I tested the claimed behaviour on OS/2 with
gnuplot 4.0 and 4.1 using two different X11 servers
(Hoblink and XFree86) in differenet scenarios and
OS/2 Presentation Manager (PM).
To make it short: Raising the console does only work
if gnuplot and the terminal back end (pm or x11) 'live'
on the same screen, i.e. both on PM or both on the _same_
X11 session. Everthing else I tried did not work, including
mixed pm/x11 scenarios and two differnt x11 servers.
Personally I think it is not worth the effort to support
such 'mixed sessions'. I do like the current behaviour,
though. It really makes life easier sometimes.
I think it's good to avoid duplicating code, but I
object to introduce X11 as a linkage requirement.
Instead I propose to only support "single screen
scenarios", ie. if the terminal is x11 try and call
X11_raise_console() (the new terminal entry which Ethan
proposed)
which pipes the "raise" command to gplt_x11. That way
we can 'bind' the space key and avoid duplicating code
for WXT.
Timothee, if you want to implement PM_raise_console()
please take the code I sent you earlier, it is fully
tested.
Logged In: YES
user_id=31505
> Allow a "bind '<space>'
Fine with me.
> term->raise_console()
So let's have
term->interactive(int action, varargin, ...)
and use
term->interactive(INTERACTIVE_ACTION_RAISE_GNUPLOT_CONSOLE)
Otherwise, the common code should go into mousecmn.c.
> I thought you said before that it has been working
> for years
Thanks to Bastian who verified how it really works nowadays.
(Earlier, I was using IBM's PMX or XFree86).
Logged In: YES
user_id=235620
Here's my go at it.
raise_console_1
This first patch is very similar to Timothée's original
patch, except that it defines "raise console" as a normal
core command. This immediately means that you can bind it
to a hotkey, including the spacebar. It also means you can
include it in a script (not sure why that would be useful).
raise_console_2
Removes the hardwired code from gnuplot_x11, x11.trm and
other drivers. Adds "bind ' ' 'raise console'" as a default
setting.
My version - add new command "raise console"
Logged In: YES
user_id=31505
I've tried it for X11 and WXT, and it seems to work.
But for WXT, rebounding ' ' by the 'bind' command does not work.
BTW, there is still some code
(getMultiTabConsoleSwitchCommand) duplicated in mouse.c and
in raise_console.c .
Logged In: YES
user_id=1333817
Hmm, where is raise_console_2.patch ?
Remove console-raising code from terminals
Logged In: YES
user_id=235620
Here it is.
(untested except for x11)
Revised version of original spacebar.diff
Logged In: YES
user_id=235620
After trying both, I have decided I like your builtin-raise
approach better. So here (spacebar_EAM.diff) is a revised
version of your original patch that fixes the compile and
run-time logic of which console types are tried in which
order, and also removes the equivalent code from the x11 and
wxt terminals.
Logged In: YES
user_id=1333817
Ethan, I have put small adjustments on top on your last patch :
* gclient.c : according to Bastian, VK_SPACE need to stay on
the switch, it does not mean ' ' by default.
* wxt_gui.h : remove RaiseConsoleWindow() declaration.
* mouse.c : rework the OS2 case based on Bastian's remarks
and my observations.
* gplot_x11.c : you seem to have missed to remove gnuplotXID
in sscanf() since you have removed it from x11.trm, and by
the way it is not used anywhere.
Tested on wxWidgets and x11, (the Windows code has not
changed, so I have not rebooted to try it).
Logged In: YES
user_id=235620
Looks OK, except for the OS2 part of builtin_raise(). You
have re-introduced the improper initializations in body of
the OS2 #ifdef code. It needs curly brackets around it to
be valid C, or else the declarations need to be moved to the
top of the routine.
Logged In: YES
user_id=1333817
> You have re-introduced the improper initializations in
body > of the OS2 #ifdef code.
Ok, here is a patch with the if (1) {...}
Revised version
Logged In: YES
user_id=1180072
Here's a modified version of the 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 newsgroup since I cannot
attach files here.
Logged In: YES
user_id=1333817
I attached Bastian's patch here, taken from his post to the
mailing list.
Revised version for OS2 (disable X11 code on OS2), last fix to sscanf and printf
Logged In: YES
user_id=235620
In preparation for a code freeze and the run-up to a release of
version 4.2, existing bugs and patchsets are being prioritized.
This patchset is not on my (sfeam) list for inclusion in 4.2 and
is therefore being marked as priority 2.
Note that this does not mean it is a bad patch, or that it won't
be incorporated into cvs after 4.2 is released. We can
re-evaluate priorities after 4.2 is out.
If you want to argue for immediate reconsideration - go right
ahead; but do so quickly!
Ethan Merritt
Logged In: YES
user_id=235620
Originator: NO
We never managed to find a clean implementation that moved the raise-on-space code into the core without dragging in unwanted libraries, and it remains impossible to turn off the space-key-trapping once the program is running.
So I am adding a compile-time configuration option --disable-raise-space that gets rid of all the support code for this option. I for one never want the program to mess with my window layout, and I intend to make this configuration option standard for my builds.
Logged In: YES
user_id=31505
Originator: NO
There was a long discussion I see.
I think the best would be to add
term->interactive(int action, varargin, ...)
Then it will be called as
term->interactive(INTERACTIVE_ACTION_RAISE_GNUPLOT_CONSOLE)
Then it would also allow to set/synchronize menu items in the stand-alone gnupmdrv and gnuplot_x11 or others in future with settings inside gnuplot (e.g. "set mouse" switches of menu items) via
term->interactive(INTERACTIVE_ACTION_SET_MOUSE, 0) # unset mouse
term->interactive(INTERACTIVE_ACTION_SET_MOUSE, 1) # set mouse
In order to avoid duplicated code, there will be new file
interactive.c
which will contain code shared via gnuplot/gnupmdrv/gnuplot_x11 and compiled in when needed via #define's.
Logged In: YES
user_id=235620
Originator: NO
I think every one of us that looks at this problem gets confused all over again.
Remember that a large part of what makes this hard is that it is not a terminal function. Nothing we add to any given terminal will solve this. The device-specificity we are fighting is the difference in consoles, not the difference in terminals. So far as I can see, adding a new terminal entry point doesn't help to solve the problem. There is a disconnect between the kind of console window and the kind of plot window. Things that affect the plot window are logically handled by the individual terminal drivers. Things that affect the console window have to be handled in the core code for it to make any sense. That's where the earlier efforts foundered.
Logged In: YES
user_id=31505
Originator: NO
I propose to keep the code in terminals, in order not to blow the core gnuplot executable with new library dependencies.
Logged In: YES
user_id=235620
Originator: NO
> I propose to keep the code in terminals, in order not to bloat the
> core gnuplot executable with new library dependencies.
That's what we have now. I 100% agree that we shouldn't bloat the core with terminal-specific code and library references. But the result is that the terminals themselves are bloated. Why should the x11, wxt, and win drivers all contain a copy of the same code that is needed to raise the windows console, and a copy of the same code that is needed to raise an xterm or KDE console, and so on?
Fortunately, at this point I can try to ignore the terminal code bloat because now I can turn it all off during compilation by using the --disable-raise-console option.