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

[Ethan M. <merritt@u.washington.edu>]

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 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.  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.

If Octave wants to read and store other window properties so that
an earlier session can be restored, that seems fine. 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.

> Thus the only opportunities to do that would be ...
> 
> 	figure (1, "position", [440   314   560   420])
> 
> or
> 
> 	set (0, "defaultfigurepositionproperty", [440   314   560   420])
> 	figure (2)
> 
> By the way, regarding Qt, I don't think we'll know if it is running on  
> top of x11, Windows, or Quartz. So I'm skeptical we can obtain window  
> size/position information ... or am I missing something?

Yeah, that's what I was pointing out up above.  On the other hand,
Qt must have its own mechanism for querying window properties.


-- 
Ethan A Merritt