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

[sfeam <sf...@us...>]

On Saturday, 25 October 2014 04:46:23 PM Daniel J Sebald wrote:
> 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?

Sure. Based on the 1st plot in heatmaps.dem

%%%%%%
unset key
set tic scale 0

# Color runs from white to green
set palette rgbformula -7,2,-7
set cbrange [0:5]
unset cbtics

$map1 << EOD
5 4 3 1 0
2 2 0 0 1
0 0 0 1 0
0 0 0 2 3
0 1 2 4 3
EOD

set view map
set multiplot layout 1,2

set title "auto-scaled"
splot '$map1' matrix with image

set xrange [-0.5:4.5]
set yrange [-0.5:4.5]

set title "explicit set xrange [-0.5:4.5]"
replot

unset multiplot

pause -1
%%%%%%

	Ethan

> 
> 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
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta