Re: gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Dear all,

I finally chose (as usual ?) the shortest way from the current code to
make wxt work on MacOS, i.e.:

> 2nd solution = invert the threads' roles (i.e. the shortest path from
> where we are now):
> - the main thread runs the GUI event loop, and gnuplot gnu_main()
> (plot.c:278) runs in the second thread.
> - terminal callbacks (such as term->graphics, term->text) do every GUI
> action asynchronously, by posting messages to the GUI event loop
> - corner cases:
>     *signals masks have to be carefully set, so that ^C ends up in the
> second thread (easy)
>     *doing everything asynchronously can be painful, sometimes it's
> actually synchronous, so you have to wait for the other thread to finish
> before continuing (I am thinking of term->init() where new windows are
> created) (easy, but not really beautiful programming)
>     * this adds a startup overhead, because wxWidgets has to be
> initialized at launch-time for the threads facility (I don't see how to
> switch the two thread contexts when they are already running) (currently
> it's initialized when first used).

The good news is that few things (window creation mainly) have to be
really done in the GUI thread, so it wasn't much of a pain.
Most of the work is already in CVS. The last patch that actually switches
the two threads is attached. It is a patch against today's CVS. Mojca or
Joe, please test if you want to.
Ethan or Hans-Bernhard maybe, I'd appreciate if you wanted to give a quick
look at the patch and tell me if this approach (not the details) looks
right to you.

Remaining bits to fix: add 24x24 icons for the toolbar (standard on
MacOS), fix oversampling (problems with text position, maybe a buggy cairo
or pango version), make 'persist'-effect work (does it work on aquaterm by
the way ?)

Best regards,

Timothée