Re: gnuplot with wxt on MacOS, time for decisions

[Ethan M. <merritt@u.washington.edu>]

On Monday 07 May 2007 11:02, Timoth=C3=A9e Lecomte wrote:
> Dear gnuplot (especially on MacOS) enthusiasts,
> Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
> Dear Nigel, whose remarks inspired me for this mail,=20
>=20
> I have worked a little more on wxt for MacOS this last days.
>=20
> Fixing it for MacOS is not really straightforward, because I seem to=20
> have abused Linux/GTK/X flexibility so that some things have to be=20
> restricted now.

[rest of original message now at the end]
=20
> So, I'd like to know what you think of this. Do you think it's worth=20
> doing all these changes ?=20

Not really.  I think the prefered options are

(4) Fix the upstream package in OSX

It seems pointless to spend all that time re-arranging gnuplot only
to the benefit of gnuplot users.  The equivalent amount of work on
the OSX equivalent of the GTK layer would presumably benefit ports
of many other applications to OSX as well.

or

(5) Use X11 + wxWidgets on OSX rather than the apparently broken
native OSX layer (that's possible, right?)

I'd like to hear from Per Persson as well (CC'ed)

If you really want to pick from options 1, 2, and 3 I'd go with=20
(1) two single-threaded processes, as in the X11 implementation.
If nothing else, this makes it easier to debug.


	Ethan






> The main restriction, as discussed in previous mails, is that the main=20
> thread should do each and every GUI action. Currently, wxt uses a second=
=20
> thread for the GUI event loop, and happily does things in the first=20
> thread with some mutexes locked. This approach does not work on MacOS.
>=20
> 1st solution, as suggested previously =3D use two processes:
>  - this is the design of the x11 terminal. I don't like it, because I=20
> find complicated to have to handle two processes and their=20
> inter-communication where we really have one program (one task).
>=20
> 2nd solution =3D invert the threads' roles (i.e. the shortest path from=20
> where we are now):
> - the main thread runs the GUI event loop, and gnuplot gnu_main()=20
> (plot.c:278) runs in the second thread.
> - terminal callbacks (such as term->graphics, term->text) do every GUI=20
> 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=20
> second thread (easy)
>     *doing everything asynchronously can be painful, sometimes it's=20
> actually synchronous, so you have to wait for the other thread to finish=
=20
> before continuing (I am thinking of term->init() where new windows are=20
> created) (easy, but not really beautiful programming)
>     * this adds a startup overhead, because wxWidgets has to be=20
> initialized at launch-time for the threads facility (I don't see how to=20
> switch the two thread contexts when they are already running) (currently=
=20
> it's initialized when first used).
>=20
> 3rd solution =3D use one thread only (the most ambitious)
>  - the one and only thread is an event loop.
>  - "a char arrived on stdin" is handled as an event (this is natural,=20
> isn't it?), and passed to readline
>  - the event loop is actually the GUI loop, just extended to watch stdin=
=20
> in addition to window events
>  - no more locking, no more worries about not-so-asynchronous actions,=20
> no more multithreading restrictions to take care of
>  - it looks like it's the way Nigel Nunn has mentioned for so long
>  - drawbacks:
>     * it's the longer way to go from what we have now, involving some=20
> work in some mechanisms and assumptions gnuplot has had since the early=20
> ages probably.
>     * as for the previous solution, there's a startup overhead because=20
> we would have to initialize the event loop (i.e. wxWidgets)
>=20
> Currently, we have:
>     while( readline(); do_line(); ) {};
>=20
> Instead we would have an event loop, with the following callbacks:
>     data_is_available_in_stdin() {rl_callback_read_char ();}
>     line_is_completed() {do_line();}
> The event loop naturally processes these events exactly the same way it=20
> does with others, namely GUI events.
>=20
> In practise, a lot of reorganization is needed:
> - in plot.c, to separate the initialization code, from the actual loop=20
> quoted above,
> - in command.c and readline.c, to implement the event-based approach,=20
> and to rework the pieces of code that call read_line or getc directly=20
> (builtin-pager, help system, inline data)
>=20
>=20
> So, I'd like to know what you think of this. Do you think it's worth=20
> doing all these changes ? Note that if I work on this, I won't change=20
> the way it works when wxt is not compiled in.
>=20
>=20
> Best regards,
>=20
> Timoth=C3=A9e Lecomte
>=20
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742