Re: gnuplot with wxt on MacOS, time for decisions

[Per P. <per...@ma...>]

On May 7, 2007, at 21:17, Ethan Merritt wrote:

> On Monday 07 May 2007 11:02, Timoth=E9e 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,
>>
>> I have worked a little more on wxt for MacOS this last days.
>>

First of all: nice work Timoth=E9e, the screenshots looks very nice.

>> Fixing it for MacOS is not really straightforward, because I seem to
>> have abused Linux/GTK/X flexibility so that some things have to be
>> restricted now.
>
> [rest of original message now at the end]
>
>> So, I'd like to know what you think of this. Do you think it's worth
>> doing all these changes ?
>
> 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.

Huh, you lost me here. Fix what? You mean wxMac/wxCocoa right?

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

Yes, I can't see why it shouldn't.

>
> 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
> (1) two single-threaded processes, as in the X11 implementation.
> If nothing else, this makes it easier to debug.

I don't really have a strong opinion here, and since I don't know wx =20
stuff at all I'm mostly guessing.

Do you really need all that asynchronicity in option (2)? AFAIK most =20
GUI-systems will lock focus on a drawing view
at an appropriate time and then call a specific method, lets call it =20
draw(). What if you used Cairo's metasurface to record the drawing =20
commands in the driver, and then played them back in the draw() =20
method? But then again, I haven't had time to follow what's going on =20
here or on the related projects.

As for (3), maybe that approach (should you choose it) should be =20
generalized[1] to simplify development of Windows/GTK/Mac/Qt/etc GUI =20
interfaces to gnuplot, on equal footing with the current CLI.

/Per

(1) I guess such a generalization could lead to a situation with x =20
number half-baked GUI's popping up, each with different feature sets, =20=

level of maintenance, quality etc since developer resources would be =20
"like butter spread over too much bread". In that case I'd rather see =20=

a single well kept CLI.


>
>
> 	Ethan
>
>
>
>
>
>
>> The main restriction, as discussed in previous mails, is that the =20
>> main
>> thread should do each and every GUI action. Currently, wxt uses a =20
>> second
>> thread for the GUI event loop, and happily does things in the first
>> thread with some mutexes locked. This approach does not work on =20
>> MacOS.
>>
>> 1st solution, as suggested previously =3D use two processes:
>>  - this is the design of the x11 terminal. I don't like it, because I
>> find complicated to have to handle two processes and their
>> inter-communication where we really have one program (one task).
>>
>> 2nd solution =3D 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 =20=

>> 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 =20=

>> 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 =20
>> finish
>> before continuing (I am thinking of term->init() where new windows =20=

>> 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 =20
>> how to
>> switch the two thread contexts when they are already running) =20
>> (currently
>> it's initialized when first used).
>>
>> 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,
>> isn't it?), and passed to readline
>>  - the event loop is actually the GUI loop, just extended to watch =20=

>> stdin
>> in addition to window events
>>  - no more locking, no more worries about not-so-asynchronous =20
>> actions,
>> 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
>> work in some mechanisms and assumptions gnuplot has had since the =20
>> early
>> ages probably.
>>     * as for the previous solution, there's a startup overhead =20
>> because
>> we would have to initialize the event loop (i.e. wxWidgets)
>>
>> Currently, we have:
>>     while( readline(); do_line(); ) {};
>>
>> 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 =20
>> way it
>> does with others, namely GUI events.
>>
>> In practise, a lot of reorganization is needed:
>> - in plot.c, to separate the initialization code, from the actual =20
>> loop
>> quoted above,
>> - in command.c and readline.c, to implement the event-based approach,
>> and to rework the pieces of code that call read_line or getc directly
>> (builtin-pager, help system, inline data)
>>
>>
>> So, I'd like to know what you think of this. Do you think it's worth
>> doing all these changes ? Note that if I work on this, I won't change
>> the way it works when wxt is not compiled in.
>>
>>
>> Best regards,
>>
>> Timoth=E9e Lecomte
>>
>>
>>
>> ---------------------------------------------------------------------=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
> Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
> Dept of Biochemistry
> Health Sciences Building
> University of Washington - Seattle WA 98195-7742