Re: GPVAL_TERM_VCHAR (was: problem with "set x11 {size WW,HH} {position XX,YY}")

[Ben A. <bpa...@ma...>]

On Friday, February 13, 2009, at 11:27AM, "Ethan A Merritt" <merritt@u.washington.edu> wrote:
>On Friday 13 February 2009, Petr Mikulik wrote:
>> > >Right.  No re-positioning or re-sizing of an existing window.
>> > 
>> > Personally, I have no position on what is and is not proper with respect to
>> > the positioning of windows. However, I think it is important to clarify a
>> > point.
>> > 
>> > Octave's intention is to allow the user to move/resize the figures via the
>> > mouse, the command line, or a script. This intent is primarily driven by the
>> > goal of compatibility with Matlab.
>> 
>> All these 3 move/resize work correctly. The only way which is not available 
>> is the feedback of "user moves/resizes by mouse" => "update this information 
>> in Octave". We have shown that it is a wrong way to use "xwininfo" for this 
>> because it returns the window size, not the plot size, and it would work on 
>> X11 only. Therefore, the only solution is to have new variables
>> 	GPVAL_PLOT_SIZE
>> 	GPVAL_PLOT_POSITION
>> e.g.
>> 	GPVAL_PLOT_SIZE=600 400
>> 	GPVAL_PLOT_POSITION=0 0
>> which would Octave check when it needs them. 
>
>
>We already support this!  (Well OK, not the position part.  I am strictly
>opposed to that). This was, in fact, the original motivation for
>adding the GPVAL_* variables.  The information variables were added
>exactly so that they could be used by higher level program to implement
>external mousing and the creation of image maps for, e.g., png images
>displayed on the web.
>
>The canvas size is held by GPVAL_TERM_XMIN, GPVAL_TERM_XMAX, etc...
>The plot boundaries are held by GPVAL_X_MIN, ....
>
>This mechanism is in real use in conjunction with several terminals,
>including the recently added canvas terminal.
>
>> These values would be compatible with values in
>> 	set term x1||wxt|... size nnn,nnn position mmm,mmm
>
>No. That cannot work.  In order to be valid, the must represent the
>values used by the most recent plot, not the values that were originally
>set by the "set term" command.  
>
>> If they are not available (as nowadays), Octave should not use
>> 	set term ... size position
>> unless user explicitly changes these values via
>> 	set(gcf, 'position', [new values])
>> I propose you add a static variable which remembers last 'position' values 
>> and does "set term ... size position" only in case of a change. I think this 
>> is a useful compromise.
>
>
>I am strictly opposed to adding a "position" property to gnuplot's "set term"
>commands.  If you require the ability to place multiple plots relative to
>each other, then use multiplot mode and a larger canvas.
>

Ethan you convinced me that gnuplot's windows should not be moved by the "set term" command.

Is there reason to not allow the windows to be opened at specific positions?

Ben