Clarification on terminal size for Qt terminal and generally

[Daniel J S. <dan...@ie...>]

Jérôme,

I've been looking at the Qt terminal code to address sizing retention. 
Through some dialog for patch #661 Ethan and I began to question the 
differences between Qt versions and how that would effect an initial 
incorrect plot size that I and apparently Mojca are seeing.

I'm beginning to suspect that is the case, and what is different between 
the Qt versions is probably the obscure size hint.  Newer versions are 
probably more accurate.  However, I'm wondering if we can get away from 
the size hint and get direct results with just a little clean up of

QtGnuplotWidget::processEvent()

The gist of it is that QtGnuplotWidget is made to be the central widget 
of the QMainWindow, so I would guess just doing that alone is enough to 
impart size adjustment on QtGnuplotWidget without having to process 
GESetWedgetSize inised processEvent.  But before addressing that, I'd 
like to clear up the layout of the widgets in the main window.

Now, from what Ethan describes, the size specifications option for qt 
terminal refers to the outer dimensions of the QMainWindow, not the 
plotting area.  I think the documentation could be clearer on this:

  "The size of the plot area is given in pixels, it defaults to 640x480.
  In addition to that, the actual size of the window also includes the space
  reserved for the toolbar and the status bar."

The 640x480 is not the plot area, more accurately the "size of the 
window".  Is there consensus on this?

If there is, then here is another question.  What do

term->xmax
term->ymax

represent to the core code?  Outer window dimensions?  Or the plot area?

I ask because if it is the latter, then

	// Set plot size
	if (qt_setSize)
	{
		term->xmax = qt_oversampling*qt_setWidth;
		term->ymax = qt_oversampling*qt_setHeight;
		qt_setSize = false;
	}

seems questionable.  If the latter, then really the size should be sent 
to gnuplot_qt, which then computes the plotting area size and sends that 
info back to the inboard driver, which eventually ends up in term->xmax, 
term->ymax.

Let's clarify these things and then proceed to do a little bit of 
cleanup of the code.

Dan