Re: GPVAL_TERM_VCHAR

[Timothée L. <tim...@lp...>]

Ben Abbott wrote:
> On Feb 12, 2009, at 6:08 PM, Petr Mikulik wrote:
>
>   
>>> hmmmm. I was not aware the mouse coordinates could be toogled on  
>>> and off.
>>> What are the default hot-keys?
>>>
>>> If the mouse coordinates did not extend the y-size, the hassle of
>>> accounting for it would be more convenient.
>>>       
>> It is even worse ... the "wxt" terminal has icon bar which also  
>> extends the
>> plot area. The "Qt" terminal may be even different. Therefore,
>> 	set term wxt|x11 size nnn,nnn
>> 	plot x
>> 	!xwininfo
>> show different numbers. You can find that
>> 	set term x11|wxt size nnn,nnn
>> means the size of the graph-canvas area, not the full x11 window.
>>
>> IMHO, Octave does not need to know the size of the window, does it?
>> Is it really useful for any practical case? I don't think so.
>> And if user changes
>> 	set(gfc, 'position', [....])
>> and you pass these numbers to gnuplot, then it will set the size as
>> expected.
>>     
>
> If the "icon bar" is a fixed size in pixels, then I can handle wxt,  
> Qt, and x11 having their sizes reported differently by xwininfo (or  
> the like). If the "icon bar" is not a fixed size, then that would be  
> problematic. We'd likely only update Octave's figure position property  
> when we can be confident that x11 properly reports the window's size  
> and position.
I fully agree with Ethan here : it seems more logical to fix a size for 
the plot area rather than for the plot window. It makes that property 
consistent when used with screen-based terminals and then exporting to a 
file terminal. For example, you ask for a 400x300 pixels figure, why 
would you want to get a 400x300 pixels PNG from the png terminal and 
only a 350x290 pixels plot area in x11/wxt/... ? I'm quite sure you want 
400x300 plot area in both cases.

Timothée