Re: Bind <space> to builtin_raise in mouse.c

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

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