Re: gnuplot -> octave communication of figure position

[Ben Abbott]

opps, I got Ethan's email wrong.
 
On Thursday, January 29, 2009, at 04:36PM, "Ben Abbott" <address@hidden> wrote:
>John / others
>
>What do you think. Shall I make a request of the gnuplot developers to make 
>the x11 window id accessible?
>
>As I'm not familair with how the communication between octave and gnuplot is 
>done, I'll have to differ to those who are.
>
>Ben
>
>>From: "Ethan Merritt" <address@hidden>
>>To: "Benjamin Abbott" <address@hidden>
>>Cc: <address@hidden>
>>Date: January 29, 2009 04:13:19 PM EST
>>Subject: Re: problem with "set x11 {size WW,HH} {position XX,YY}"
>>
>>On Thursday 29 January 2009 12:32:29 Ben Abbott wrote:
>>> 
>>> On Dec 29, 2008, at 12:15 AM, Ethan A Merritt wrote:
>>> 
>>> > On Sunday 28 December 2008, Ben Abbott wrote:
>>> >>
>>> >> On Dec 28, 2008, at 9:10 PM, Ethan A Merritt wrote:
>>> >>
>>> >>> On Sunday 28 December 2008, Ben Abbott wrote:
>>> >>>
>>> >>
>>> >>>> *SNIP*
>>> >>>> By the way, it would really be cool if there was a method by which
>>> >>>> the
>>> >>>> size and position of a plot window could be determined. That way  
>>> >>>> if a
>>> >>>> user moves or resizes a window Octave could do some checking and  
>>> >>>> have
>>> >>>> some awareness of such (I'd be stunned if such were possible, but
>>> >>>> thought I'd ask).
>>> >>>
>>> >>> You can do that with a call into xlib; you don't need any special
>>> >>> code in gnuplot for that.  You should be able to get all the info
>>> >>> you'd get from the command line using "xwininfo"
>>> >>
>>> >> hmmm ... that may be quite useful.
>>> >>
>>> >> xwininfo: Window id: 0xc00008 "Figure 1"
>>> >>
>>> >>   Absolute upper-left X:  440
>>> >>   Absolute upper-left Y:  128
>>> >>   Relative upper-left X:  0
>>> >>   Relative upper-left Y:  22
>>> >>   Width: 560
>>> >>   Height: 493
>>> >>   Depth: 24
>>> >>   Visual Class: TrueColor
>>> >>   Border width: 0
>>> >>   Class: InputOutput
>>> >>   Colormap: 0x21 (installed)
>>> >>   Bit Gravity State: ForgetGravity
>>> >>   Window Gravity State: NorthWestGravity
>>> >>   Backing Store State: NotUseful
>>> >>   Save Under State: no
>>> >>   Map State: IsViewable
>>> >>   Override Redirect State: no
>>> >>   Corners:  +440+128  -440+128  -440-279  +440-279
>>> >>   -geometry 560x493+440+106
>>> >>
>>> >> Unfortunately, the height includes the portion needed to display the
>>> >> cursor's coordinates ... sigh :-(
>>> >
>>> > That extra height is equal to term->v_char.  This quantity is not
>>> > currently exported as a user variable, but it would be trivial to do  
>>> > so.
>>> > Do you want it?  Its name would be GPVAL_TERM_VCHAR.
>>> 
>>> I'm back hoping to better understand what is needed to determine the  
>>> position of a specific gnuplot x11 window. I can see how xwininfo can  
>>> be used, but how do I determine the window id (0xc00008 in the  
>>> instance above)? Would it be necessary to patch gnuplot?
>>
>>The usual way is to make successive requests to the window mananger
>>asking it to step through all the current windows on the display, 
>>and check each one to see if it is the one you want.  That does not
>>require any cooperation or modification of the program that created
>>the window in the first place.
>>
>>It would also be possible to modify gnuplot_x11 so that it reports
>>back the id of each new plot window that it opens.  The would involve
>>modifying gplt_x11.c,  mouse.c, and perhaps x11.trm, but I think it
>>would not be difficult.
>>
>>> Regarding the proposed GPVAL_TERM_VCHAR, how would be be accessed?
>>
>>It would be just like any of the other internally-maintained variables.
>>The two obvious ones are
>>
>>   show GPVAL_TERM_VCHAR
>>or
>>   set print "my/named/pipe/or/other/file"
>>   print "term->char =", GPVAL_TERM_VCHAR
>>   unset print
>>
>>-- 
>>Ethan A Merritt
>>
>>
>
>