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

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

On Feb 12, 2009, at 7:28 PM, Ethan Merritt wrote:

> On Thursday 12 February 2009 15:51:13 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 repeat an earlier question:  why do you assume that x11 is being  
> used?
> On OSX + aqua, for example, no x-server may be present at all.

I'm not assuming x11 is being used. Since Octave tells gnuplot which  
terminal is being used.

> I also return to my earlier opinion that Octave has no business  
> resizing
> the user's windows, where "window" means the entire window rather than
> merely the plot area.

This is a decision that was historically made my Mathworks.

> If you want a 200x200 pixel plot, fine.  But don't
> try to double-guess how many additional pixels may be added by gnuplot
> for mouse tracking, or by the window manager for widgets.  These will
> vary from one person's desktop to the next, or even from one session  
> to
> the next.  In fact I'd love to extend the widget bars now in wxt and  
> qt
> so that the user can configure/add/remove widgets from the bar, or  
> undock
> it from the plot window.

hmmm ... it may be that it is unwise for gnuplot to support the  
functionality that Octave's development requires for compatibility  
with Matlab. If that is the case, we should be sure to document the  
reason so that both development teams understand the problem and we  
don't rehash it in the future.

> If Octave wants to read and store other window properties so that
> an earlier session can be restored, that seems fine.

Octave has no interest in restoring a prior state (If I understand you  
correctly). However, it does have an interest in allowing the user to  
specify a state, or change a state via the command line or scripting  
language (as is done in Matlab).

> But it should be
> doable without having to understand exactly how each property
> came to have exactly the value it does.  You really just want some
> way to tell the window manager "put this back the way it was".
>
>> As the figure position property is intended to be bidirectional, I
>> think there will be too much confusion if it is implemented in a one-
>> directional manner. If we cannot update the property value when the
>> window is moved by the mouse, then I suspect the preferred solution
>> will be to allow the window to be positioned and sized when opened,
>> but not there after.
>
> 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.

That said, the current state of Octave's development sources when  
running gnuplot's development sources with the x11 terminal  is not  
what we'd like it to be. Octave presently ignores any repositioning/ 
resizing via the mouse and repositions and resizes the figure to the  
location specified by the figure's position property. This only  
happens for the x11 terminal when running development versions of  
Octave and Gnuplot.

This undesirable behavior will be resolved soon (I hope).

Ben