|
From: Ben A. <bpa...@ma...> - 2009-02-13 12:52:12
|
On Feb 13, 2009, at 3:59 AM, 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. > > These values would be compatible with values in > set term x1||wxt|... size nnn,nnn position mmm,mmm Having those new variables would be a great help. > 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. Ethan has convinced me to proceed cautiously. I'd like to first keep the figure position property up to date with the mouse movements. In the event, that octave does support repositioning of a gnuplot window, your points will need to be respected. There are plans to put listeners in place to handle such events (the support for listeners is already in place). Ben |