gnuplot-beta

"raise" for raise gnuplot console too?

[Daniel J S. <dan...@ie...>]

I'm putting together a quick little patch of the ' ' and 'q' bindings for X11 
that we talked of the other day.  (Remember, the idea is to disable the inherent 
gnuplot_x11 key event handling when the mouse is present.)  I then got to 
thinking about another related item we just talked about, i.e., plots taking 
focus away from the console.  The variation of this is that when one does "plot 
foo", the x11 window comes to the top, unless the user supplies the -noraise 
option; but perhaps the user generally likes the autoraise behavior.  In that 
case, would it make sense to have a command that raises the console?

There is the "raise {#}" for raising a GUI plot window.  Perhaps "raise console" 
would be of use.  However, that's too lengthy, one would like a very brief 
command for this sort of thing.

Anyway, rather than do this:

	if (lower) {
#ifdef OS2
	    pm_lower_terminal_window();
#endif
#ifdef X11
	    x11_lower_terminal_group();
#endif
#ifdef _Windows
	    win_lower_terminal_window();
#endif
#ifdef WXWIDGETS
	    wxt_lower_terminal_group();
#endif
	} else {
#ifdef OS2
	    pm_raise_terminal_window();
#endif
#ifdef X11
	    x11_raise_terminal_group();
#endif
#ifdef _Windows
	    win_raise_terminal_window();
#endif
#ifdef WXWIDGETS
	    wxt_raise_terminal_group();
#endif
	}

shouldn't we simply have a term api, even though non-GUI terms will have this 
empty, i.e.,

	if (lower)
	    term->order_plot(plot_num,0);
	else
	    term->order_plot(plot_num,inf);

Make the term api general in the sense that plot_num is the identifier of the 
plot and the second number is where in the displayer order to move it to.  (So 
zero is the lowest and inf the highest.)  Or will there never be a need for such 
general ordering, so just go with 0-bottom, 1-top?

Or is the idea here that we can raise/lower even if the GUI based terminal is 
not currently the active one?  (I'd argue there should be two different terminal 
pointers for such a use, i.e., 'termgui' equals most recent 'term' of the GUI 
variety.)

Dan

Re: "raise" for raise gnuplot console too?

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

On Wednesday 06 June 2007 15:01, Daniel J Sebald wrote:
> I'm putting together a quick little patch of the ' ' and 'q' bindings for X11 
> that we talked of the other day.

I have a patch to remove 'q' processing all ready to go.
You need not work on that one.

' ' processing is a more difficult case, but there already patches on
SourceForge that implement a possible replacement.  If you want to polish these
up, have at it.

	1474309    Bind <space> to builtin_raise in mouse.c
	1500654    Continue to accept input from previous interactive terminal

> I then got to 
> thinking about another related item we just talked about, i.e., plots taking 
> focus away from the console.  The variation of this is that when one does "plot 
> foo", the x11 window comes to the top, unless the user supplies the -noraise 
> option; 

I set a permanent resource
	 "gnuplot*raise:  off"

> but perhaps the user generally likes the autoraise behavior.  In that  
> case, would it make sense to have a command that raises the console?

No.
That is the job of your window manager.  You can't even type the command
unless you have focus, and if you have focus you can hit whatever key
your window manager likes to use for this purpose.  It would be absurd to
argue that every application should implement this basic window management
function all over again, probably inconsistently with N other apps.

> Or is the idea here that we can raise/lower even if the GUI based terminal is 
> not currently the active one?

That is indeed a difficulty. See the SourceForge patches.

-- 
Ethan A Merritt 

Re: "raise" for raise gnuplot console too?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 06 June 2007 15:01, Daniel J Sebald wrote:
> 
>>I'm putting together a quick little patch of the ' ' and 'q' bindings for X11 
>>that we talked of the other day.
> 
> 
> I have a patch to remove 'q' processing all ready to go.
> You need not work on that one.
> 
> ' ' processing is a more difficult case, but there already patches on
> SourceForge that implement a possible replacement.  If you want to polish these
> up, have at it.
> 
> 	1474309    Bind <space> to builtin_raise in mouse.c
> 	1500654    Continue to accept input from previous interactive terminal
> 
> 
>>I then got to 
>>thinking about another related item we just talked about, i.e., plots taking 
>>focus away from the console.  The variation of this is that when one does "plot 
>>foo", the x11 window comes to the top, unless the user supplies the -noraise 
>>option; 
> 
> 
> I set a permanent resource
> 	 "gnuplot*raise:  off"
> 
> 
>>but perhaps the user generally likes the autoraise behavior.  In that  
>>case, would it make sense to have a command that raises the console?
> 
> 
> No.
> That is the job of your window manager.  You can't even type the command
> unless you have focus, and if you have focus you can hit whatever key
> your window manager likes to use for this purpose.  It would be absurd to
> argue that every application should implement this basic window management
> function all over again, probably inconsistently with N other apps.

But when I have x11 plot active, and type "plot x" again, the gnuplot console 
still retains focus, but the plot comes to the top and partially covers the 
console window.  So then again I'd have to move the mouse over the plot (and 
click) to give it focus, so that I can type the ' ' bar to bring the console 
up... or just mouse click in the gnuplot console window.

You may have a setup that works fine, but my point is that I've never had a 
configuration (I use gnome, not kde) that gets away from requiring the mouse 
click in some way as opposed to just staying with the keyboard.

It's not that important, but the extra mouse clicks do add up.

> 
> 
>>Or is the idea here that we can raise/lower even if the GUI based terminal is 
>>not currently the active one?
> 
> 
> That is indeed a difficulty. See the SourceForge patches.
> 

OK, I'll have a look at this one:

  	1500654    Continue to accept input from previous interactive terminal

My idea would be simply to do:

     term = set_term(c_token);
     [snip]
     if ({term INTERACTIVE OR HAS MOUSE SOMEHOW})
	guiterm = term;

and then for raise/lower and event input use 'guiterm' pointer rather than 
'term' pointer.

Dan

Re: "raise" for raise gnuplot console too?

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

On Wednesday 06 June 2007 15:32, Daniel J Sebald wrote:
> would it make sense to have a command that raises the console? 
> > 
> > No.
> > That is the job of your window manager.  You can't even type the command
> > unless you have focus, and if you have focus you can hit whatever key
> > your window manager likes to use for this purpose.  It would be absurd to
> > argue that every application should implement this basic window management
> > function all over again, probably inconsistently with N other apps.
> 
> You may have a setup that works fine, but my point is that I've never had a 
> configuration (I use gnome, not kde) that gets away from requiring the mouse 
> click in some way as opposed to just staying with the keyboard.

Depends on the window manager. Gnome has a well-deserved reputation for
making it hard to change the default behaviour of anything, but if you
can't even change the focus policy that would be beyond absurd.
A quick Google search suggests it is actually quite easy:

Sawfish:
    Helix GNOME Control Center
	The selection box at the top determines how the mouse pointer sets focus.
	The default is to focus when the mouse clicks on the window. The other 
	choices are to focus only when the pointer is in the window ("enter-exit")
	and focus stays with the last window entered ("enter-only").

Enlightenment:
    Enlightenment configuration tool
	Keyboard focus follows
	These buttons determine how "focus" is selected by the actions of the mouse.
	The available settings are Mouse Pointer (focus follows mouse),
	Sloppy Pointer (focus follows mouse after a delay), and Pointer Clicks
	(focus is given to window on which a mouse clicks).

 
> My idea would be simply to do:
> 
>      term = set_term(c_token);
>      [snip]
>      if ({term INTERACTIVE OR HAS MOUSE SOMEHOW})
> 	guiterm = term;
> 
> and then for raise/lower and event input use 'guiterm' pointer rather than 
> 'term' pointer.

That doesn't work at all.  See previous frustrating discussion in which
I totally failed to explain why.  The core gnuplot code will never even
see the <space> keypress event, so it never has the opportunity to decide
what terminal function to call.  The difficulty is all on the input end,
not the output end.


-- 
Ethan A Merritt

Re: "raise" for raise gnuplot console too?

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

On Wednesday 06 June 2007 19:07, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > 
> > The core gnuplot code will never even 
> > see the <space> keypress event, so it never has the opportunity to decide
> > what terminal function to call.  The difficulty is all on the input end,
> > not the output end.
> > 
> gnuplot tells gplt_x11 to set handle_key_events equal to 0 when it does a 
> term init, where does the space key get lost?

As it is now, the space key does not get lost because gnuplot_x11 will 
always trap it and act on it.  But this makes it unavailable for "bind"
because that handling is done *instead of* sending back to gnuplot for
use either as a normal keystroke or as a trigger for some previously
bound hotkey action.

If we change it so that gnuplot_x11 does not treat it as a special case,
then it will get lost because:
 - gnuplot_x11 sees keystroke (happens to be <space> but nothing special about this)
 - gnuplot_x11 tosses a keystroke event notification into the pipe for gnuplot
   to read via X11_waitforinput()  
 - if the current terminal is x11, then as the stream of chars in the pipe
   is gradually read, this one will be directed to event_keypress() for 
   comparison against the list of "bind" actions
 - but if the current terminal is not x11, nobody will read from the pipe
   at all.  So it is "lost" in the pipe and is never delivered to event_keypress().

Patchset #1500654 "Continue to accept input from previous interactive terminal"
tries to work around this by continuing to use X11_waitforinput() as an input
source even if x11 is no longer the current terminal. It sort of works so long
as x11 is the only interactive terminal in the mix, but when last I looked at
it the result of switching to some other interactive terminal was to flood the
input stream with garbage characters.  I didn't debug it any further, and 
anyhow the wxt terminal driver has evolved since then.  So maybe the patch can
be polished up and made more acceptable.  If you want to work on the problem,
great, but please first explore that patchset and learn why it is necessary and
how it works.

-- 
Ethan A Merritt