Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On 10/25/2014 03:01 PM, sfeam wrote:
> On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote:
>
>>  On 10/25/2014 01:05 PM, Bastian Märkisch wrote:
>
>>  > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald:
>
>>  >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote:
>
>>  >>
>
>>  >>> I removed the interlock test and it creates quite a mess with invalid
>
>>  >>> events, seg faults in bad library calls, to scratch the surface.
>
>>  >>>
>
>>  >>> Investigating a bit, I think the problem lies in the fact wxt terminal
>
>>  >>> is not in its own process.
>
>>  >>
>
>>  >> It's too much work to do this in an afternoon or so. Having looked at
>
>>  >> the code, though, I'd say some things get simplified when WXT is run in
>
>>  >> its own process as an outboard plotter. All these sorts of conditions
>
>>  >>
>
>>  >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>
>>  >>
>
>>  >> go away.
>
>>  >>
>
>>  >> Dan
>
>>  >
>
>>  > Btw. Timothée had been working on this years ago, see patch #380
>
>>  > https://sourceforge.net/p/gnuplot/patches/380
>
>>
>
>>  Thanks. That could save a ton on the initial tedious work of putting
>
>>  bulk of the code in its own program.
>
>>
>
>>
>
>>  > Also, the qt and wxt terminals run nicely in the same session on
>
>>  > Windows. It just took some effort to make qt->waitforinput() work.
>
>>  >
>
>>  > Since waitforinput() is a terminal routine it typically only handles
>
>>  > events from the library the current terminal uses. If we want to use
>
>>  > multiple libraries in the same process, we need to replace/extend that
>
>>  > mechanism.
>
>>
>
>>  I think once the active terminal is changed, mousing and keyboard input
>
>>  is disabled for others.
>
>>
>
>>
>
>>  > From my experience with the (outboard) qt terminal, I sincerely doubt
>
>>  > that moving the wxt terminal to its own process will significantly
>
>>  > simplify the source.
>
>>
>
>>  It won't simplify the source, but it will get rid of those "corner
>
>>  cases". As you point out, Windows works fine for both terminals...and
>
>>  that's why the things like:
>
>>
>
>>  #if defined(WXT_MONOTHREADED) || defined(_Windows)
>
> Before tearing into a project to split off wxt into a separate process
>
> altogether, I think you should look into making the WXT_MONOTHREADED
>
> variant work on linux. Some/all of the problems it now has are due to
>
> the graphics event loop running in a separate thread.

I know that Qt has a requirement that graphics be only in the main 
thread.  I can't verify that is the case for wxWidgets and I see some 
discussion on the Web that graphics can be done in non-main threads 
(sometimes with extra initialization inside the other threads).

In any case, is that the desired setup?  To have interactive graphics 
running in the same thread?  Doesn't that create some event management 
code that typically is averted by using separate threads or processes?

One approach might be to put what is now the main thread/code for 
processing command line input into a separate thread and then leaving 
the main thread for a possible interactive terminal, but not sure I like 
that idea.


> Anyhow, I really don't see the need for typical users to switch between
>
> qt and wxt within a single gnuplot session. Especially because the
>
> distro-packaged gnuplot versions probably only provide one or the other,
>
> not both. It can be handy for a developer, yes, because you'd like to
>
> compare the output of the two terminals. But I don't think that's a
>
> particularly useful thing for a typical gnuplot session.
>
> So really I think this is low priority compared to some other issues.
>
> For instance, how about fixing the auto-scaling for image plots?
>
> Right now the default behavior is to auto-scale to the center of
>
> the 4 corner pixels, which clips all the outermost pixels in half.
>
> That would be OK if there were an easy way to override it, but
>
> many of the obvious commands don't work.
>
> E.g.
>
> set xrange [-0.5:*] # doesn't work with image data
>
> set offset .5, .5, .5, .5 # this doesn't work either

Could you give an example?

This works on my system:

reset
set xrange [-0.5:*]
set cbrange [0:1]
unset key
set tics out
plot '-' with rgbimage
0 0 0.0 0.0 0.5
0 1 0.0 0.5 0.0
1 0 0.5 0.0 0.5
1 1 0.0 0.5 0.5
e

Although, I would point out that the Qt terminal doesn't quite layout of 
the pixels correctly.  The left column pixels are about 5% to 10% too 
wide and overlap the right column pixels.  The wxt terminal is better at 
this, but I notice that wxt has some problems when scaling the plot 
size.  Sometimes there is a small white space between the axes and image.

This sort of works:

reset
set offset 0.5, 0.5, 0.5, 0.5
set cbrange [0:1]
unset key
set tics out
plot '-' with rgbimage
0 0 0.0 0.0 0.5
0 1 0.0 0.5 0.0
1 0 0.5 0.0 0.5
1 1 0.0 0.5 0.5
e

but it seems to me that a 0.5 border is created, but then the autorange 
is taking that extra space to compute nice round numbers a little bigger 
than the 0.5 border, i.e., [-1:2].

We should come up with a definition for the image pixel coordinate 
system, if that hasn't already been done.  I'm recalling confusion about 
one of us thinking in terms of pixel centers, while the other in terms 
of pixels at the coordinate system leading edge.  They're both valid and 
the choice is somewhat arbitrary, but it would be nice to have the 
accepted spatial coordinate system written down so that when programming 
there's no doubt about how to program computations.  We should have:

1) A fairly detailed statement in a code file or a text file.

2) An intricate demo plotting an image along with some lines and arrow 
describing what the convention is.

Dan