From: sfeam <sf...@us...> - 2014-10-25 20:23:46
|
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. 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 Ethan > > are in the code. But if WXT is running in its own thread all the > Windows items should still work fine as well as linux. That's the idea > anyway. > > Just to confirm, does the Qt terminal work in both Linux and Windows? > > Dan > > ------------------------------------------------------------------------------ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |