Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> I suppose. But the work involved to disentangle the code in
> wxt_gui.cpp from the core to make it a loadable module would be pretty
> much the same work needed to make it an outboard driver.

Probably yes.  I was thinking that once this has been done for one
driver iot would providew an easier model to follow for others and then
allow the "expensive" drivers (in terms of dependencies) split out into
their own modules (Cairo/Pango, etc. pp.).

> Honestly I think it would be less work to get the Qt terminal
> working.

I think we'll get there eventually, it's just that the Cygwin devs don't
have a small enough reproducer yet.

> But I have never worked on Windows at all and have no particular
> desire to start now.  So I can't really debug or try much myself, only make
> suggestions and point to possible problem points.   
> Is the problem with O_NONBLOCK absolute, i.e. Cygwin will never
> accept such a call, or is it just that making this particular connection
> non-blocking reveals an unacceptable latency in the initialization?
> The former I can't do much about, but the latter we could maybe
> work around by having gnuplot_qt return SUCCESS immediately
> even though initialization is not complete.

The thing is that the call _should_ work and since this is deep inside a
Qt library that is happily used by other Qt applications without any
reported problems indicates that there is some other condition that
makes it not work work for gnuplot_qt specifically (an initialization
that's missing or something like that).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada