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