Re: Clarification on terminal size for Qt terminal and generally

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

On 03/17/2014 03:21 PM, Mojca Miklavec wrote:
> On Sat, Mar 15, 2014 at 4:20 AM, Daniel J Sebald wrote:
>> On 03/10/2014 01:36 AM, Daniel J Sebald wrote:
>>>
>>> On 03/09/2014 04:47 PM, Daniel J Sebald wrote:
>>>
>>>> I'm in the
>>>> middle of programming this right now, so it would be good to know how it
>>>> should behave.
>>>
>>>
>>> I've placed an initial version Qt window size retention on the patch
>>> tracker:
>>>
>>> http://sourceforge.net/p/gnuplot/patches/663/
>>
>>
>> Mojca,
>>
>> If you have some time this weekend, please try out the Qt window size
>> retention patch.
>
> I'm very grateful for the change that keeps me in terminal as opposed
> to jumping to the plotting area and having to alt-tab back to terminal
> after every command.
>
> I'm not sure how to reproduce the following (and maybe I should check
> with master), but as a rule of thumb it happened when I had all the
> cores 100% occupied with other tasks:
>
> Terminal type set to 'qt'
> gnuplot>  plot sin(x)
> qt_graphics: "QLocalSocket: Socket operation timed out"
> qt_graphics: Not receiving requested widget size
> Error: short read from gnuplot_qt socket while expecting font metrics
>           warning: Too many axis ticks requested (>1e+01)
>           warning: Terminal canvas area too small to hold plot.
>          Check plot boundary and font sizes.
>           warning: Too many axis ticks requested (>1e+01)
>           warning: Too many axis ticks requested (>4)
>
> Other than that it sometimes happens that I don't get any text labels
> at all (one of the things that Ethan fixed), but don't hold my word
> for it because I'm not sure if that was a side effect of forgetting
> "make install" or if that was a real issue.
>
> The second plot shrinks – it uses a different plotting area. (The
> first plot doesn't fully fit into the window – x axes labels are too
> low. The second plot now fixes that by using smaller plotting area.)
>
> I'm not sure about the pattern (how exactly to reproduce it), but very
> often sizes of the plots are completely off (either too small or too
> big). The ratio seems right, but scaling is not. See the attachment.
> Please note that I have "Replot on resize" switched off (because it's
> not bearable to have it turned on as it resizes every few pixels.) But
> usually the plot should adjust after calling "plot ...". Here it
> sometimes does and sometimes doesn't.
>
>> From time to time I also get
>
> gnuplot>  qt_graphics: "QLocalSocket: Socket operation timed out"
> qt_graphics: Not receiving requested widget size
> qt_graphics: "QLocalSocket: Socket operation timed out"
> qt_graphics: Not receiving requested widget size
>
> (with "Replot on resize" turned on).
>
> I didn't try to understand the changes in the source code, I was only
> testing the functionality.
>
> (I'm not saying that everything reported above is specific to the
> patch. Some problems might be present in trunk already. I would need
> to check more carefully, but some "errors/problems" are somewhat
> random.)

Thanks Mojca.  So generally it is about right, but occasionally is 
dropping data sent from the outboard gnuplot_qt.  That's what I'm seeing 
as well.

Something doesn't seem reliable about the comm link.  It could be 
something I did, but note that a lot of resizing with the mouse means a 
lot of traffic.  There are probably ways to reduce the traffic, say by 
recording the reported size on the inboard side, and we can do that. 
But first I'd prefer to leave a lot of traffic and fix the dropped data 
issue.  Reducing its occurrence only makes it a harder bug to fix down 
the road.

Dan