Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2007-05-07 18:08:07
|
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.
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.
The main restriction, as discussed in previous mails, is that the main
thread should do each and every GUI action. Currently, wxt uses a 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 MacOS.
1st solution, as suggested previously = 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 = 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).
3rd solution = 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 stdin
in addition to window events
- no more locking, no more worries about not-so-asynchronous 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 early
ages probably.
* as for the previous solution, there's a startup overhead 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 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 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ée Lecomte
|
|
From: <HBB...@t-...> - 2007-05-07 19:17:53
|
Timothée Lecomte wrote:
> 1st solution, as suggested previously = 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).
I don't really believe inter-communication between threads to be any
easier than inter-communication between processes, in the long run.
More efficient it may be, but it's not easier. You basically pay for
the extra speed by extra requirements on careful coding.
> 3rd solution = 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 stdin
> in addition to window events
That's pretty much the way the Windows native terminal has been doing
things since day 1 (and in a pretty nasty way, too, overriding the
<stdio.h> functions with macros of our own making). Which means a bit
of synergy might be achievable if you go this way.
> 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();}
Not necessarily. It's possible to lace the GUI event handling into the
readline character input function instead.
|
|
From: <tim...@en...> - 2007-05-07 19:31:04
|
Hans-Bernhard Bröker wrote:
> Timothée Lecomte wrote:
>
>> 1st solution, as suggested previously = 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).
>
> I don't really believe inter-communication between threads to be any
> easier than inter-communication between processes, in the long run.
> More efficient it may be, but it's not easier. You basically pay for
> the extra speed by extra requirements on careful coding.
I agree that both are difficult, in different places.
Inter-communication in general seems to be worth avoiding.
>
>> 3rd solution = 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
>> stdin in addition to window events
>
> That's pretty much the way the Windows native terminal has been doing
> things since day 1 (and in a pretty nasty way, too, overriding the
> <stdio.h> functions with macros of our own making). Which means a bit
> of synergy might be achievable if you go this way.
That's true, and wxt works on Windows thanks to this ! That's also why
I've been thinking about that.
>
>> 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();}
>
> Not necessarily. It's possible to lace the GUI event handling into
> the readline character input function instead.
>
Right, that's somehow the way it works on Windows (since the "message
loop" - from Windows terms - is in TermGetCH), and I guess it was part
of the intent when term->waitforinput was first introduced, since it is
used as a wrapper for getch().
But in that situation the GUI loop stays at a lower level, run by a
master loop waiting for commands input. I'd like to have a global and
single loop, with everything at the same level. I agree that it's not
that different, but it seems clearer to me.
Note that it's definitely the way the GNU Readline "alternate interface"
is designed to work
(http://www.delorie.com/gnu/docs/readline/rlman_41.html) (It is already
used in gnuplot, but I don't understand why... )
Thanks for your comments,
Best regards,
Timothée
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-07 19:17:55
|
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
|
|
From: Per P. <per...@ma...> - 2007-05-08 17:19:06
|
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
|
|
From: <tim...@en...> - 2007-05-07 19:41:48
|
Ethan Merritt wrote:
> On Monday 07 May 2007 11:02, Timothée 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.
>>
>> 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.
>
Well, I wouldn't say so ;)
First, I don't know of *any* application that use this design. First, I
can't think of any other application that have to mix command lines from
stdin with GUI. Then, when I first wrote wxt, I tried my best to make it
work without changing anything in gnuplot core (and I'm quite proud of
the result, the current code is *purely* self-contained in the
"term->..." table!). But it's obviously not the best design. Finally,
"fixing the upstream" means work on wxWidgets (there may be locking
issues that could be fixed), which I won't do, or fixing Carbon, which I
won't do either, cause I'm not paid by Apple ;) Really, the piece that
needs fixing is wxt/gnuplot.
> or
>
> (5) Use X11 + wxWidgets on OSX rather than the apparently broken
> native OSX layer (that's possible, right?)
>
It's should be working right now... but it seems that Mac users are
reluctant to install X11 when they can have a native counterpart.
> 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.
>
>
> Ethan
>
Thanks for your comments, Ethan.
Best regards,
Timothée
>
>
>
>
>
>
>> The main restriction, as discussed in previous mails, is that the main
>> thread should do each and every GUI action. Currently, wxt uses a 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 MacOS.
>>
>> 1st solution, as suggested previously = 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 = 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).
>>
>> 3rd solution = 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 stdin
>> in addition to window events
>> - no more locking, no more worries about not-so-asynchronous 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 early
>> ages probably.
>> * as for the previous solution, there's a startup overhead 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 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 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ée Lecomte
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
>
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-07 20:25:25
|
On Monday 07 May 2007 12:35, Timoth=C3=A9e Lecomte wrote:
> > (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.
> > =20
>=20
> Well, I wouldn't say so ;)
> First, I don't know of *any* application that use this design. First, I=20
> can't think of any other application that have to mix command lines from=
=20
> stdin with GUI.
They are quite common in my field, and many of them work under OSX.
However, they do so by requiring the user to install X11 and use
that interface. Hence my option (5).
Most of the recent ones are written in Python; I don't know if that makes
any difference to the toolkits available.
Here's one example where it looks like they are working on an aqua
port in addition to the X11-OSX "hybrid" version we are currently using
http://pymol.sourceforge.net/obtaining.html
Here's another page that collects info and instructions on interactive
X11-based programs running on OSX. These generally do require mixed
input from GUI and stdin.
http://xanana.ucsc.edu/~wgscott/xtal/wiki/index.php/Main_Page
I have not myself done any OSX development, but for better or worse
I have committed to [supervise the] port of several other apps to OSX,
so in the future I have more insight into the difficulties.
=09
"Mojca Miklavec" <moj...@gm...> wrote:
> If I had to use X11, I would prefer to stick with AquaTerm, even
> though it's functionality (esp. mouse) is limited. X11 is really the
> last resort to consider. (I never use this word, but X11 really
> "s*cks" on Mac.)
There may be a misunderstanding. I wasn't proposing that they use the
x11 terminal. I was proposing the we require x11-based wxWidgets+cairo+pan=
go
support libraries for OSX so that the wxWidgets-based wxt terminal can
be built. As to whether X11 sucks on Mac, I don't know. People in the
lab here seem to be happy with the OSX ports of X11-based interactive
graphics programs we use. Maybe a native port would be better yet,
but I don't hear a loud clamor for someone to put in the work.=20
=2D-=20
Ethan A Merritt Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742
|
|
From: Mojca M. <moj...@gm...> - 2007-05-07 19:49:11
|
On 5/7/07, 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.
Dear Timoth=E9e,
Thanks a lot for all your effort.
I really don't have any idea about the "dirty details" of
implementation, so I might be the wrong person to ask about the
opinion. But I'm still willing to test (and looking forward to the day
when I will be able to use the working version of it :).
> 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.
I wouldn't object the improvement of native GTK handling on Mac (I
would really like to see Mono working on Mac), but that's probably
off-topic here and outside the scope ...
> (5) Use X11 + wxWidgets on OSX rather than the apparently broken
> native OSX layer (that's possible, right?)
If I had to use X11, I would prefer to stick with AquaTerm, even
though it's functionality (esp. mouse) is limited. X11 is really the
last resort to consider. (I never use this word, but X11 really
"s*cks" on Mac.)
It's as if one would suggest using wine for running gnuplot with
windows interface on linux instead of using X11 or wxt.
It really is important to have some native driver unless there is no
other choice.
---
Thanks again for the marvellous work you do,
Mojca
|
|
From: <tim...@en...> - 2007-05-07 20:18:14
|
Mojca Miklavec wrote: > On 5/7/07, Ethan Merritt wrote: >> On Monday 07 May 2007 11:02, Timothée 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. > Dear Timothée, > > Thanks a lot for all your effort. > > I really don't have any idea about the "dirty details" of > implementation, so I might be the wrong person to ask about the > opinion. But I'm still willing to test (and looking forward to the day > when I will be able to use the working version of it :). Oops, I forgot to put a link to a screenshot I made earlier today, after I got solution n°2 working: http://tipote.free.fr/wxt_mac_20070507.png (wow, I *love* those transparent surfaces !) No code yet, but a nice screenshot, isn't it ? Insightful eyes would have notices that oversampling is disabled (not much noticeable on these plots with few straight lines, and the toolbar icons are bigger than they should be) Timothée > > --- > > Thanks again for the marvellous work you do, > Mojca |
|
From: <tim...@en...> - 2007-05-07 20:14:38
|
Mojca Miklavec wrote: > On 5/7/07, Ethan Merritt wrote: >> On Monday 07 May 2007 11:02, Timothée 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. > Dear Timothée, > > Thanks a lot for all your effort. > > I really don't have any idea about the "dirty details" of > implementation, so I might be the wrong person to ask about the > opinion. But I'm still willing to test (and looking forward to the day > when I will be able to use the working version of it :). Your user's point of view makes a lot of sense ! > >> 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. > > I wouldn't object the improvement of native GTK handling on Mac (I > would really like to see Mono working on Mac), but that's probably > off-topic here and outside the scope ... Note that there's no GTK involved here. wxMac uses Cocoa and Carbon, the native interfaces, directly. > >> (5) Use X11 + wxWidgets on OSX rather than the apparently broken >> native OSX layer (that's possible, right?) > > If I had to use X11, I would prefer to stick with AquaTerm, even > though it's functionality (esp. mouse) is limited. X11 is really the > last resort to consider. (I never use this word, but X11 really > "s*cks" on Mac.) > > It's as if one would suggest using wine for running gnuplot with > windows interface on linux instead of using X11 or wxt. > > It really is important to have some native driver unless there is no > other choice. That's what I've understood. Besides, there's already a plotting program in MacOS X, called Grapher if I remember correctly. There would be little point in working on wxt if it was a complicated (for the user) solution using X11, compared to Aquaterm and Grapher. > --- > > Thanks again for the marvellous work you do, > Mojca Well, thank you for your answer ! Timothée |
|
From: Mojca M. <moj...@gm...> - 2007-05-07 20:27:24
|
On 5/7/07, Timoth=E9e Lecomte wrote: > Mojca Miklavec wrote: > > On 5/7/07, Ethan Merritt wrote: > > > >> 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. > > > > I wouldn't object the improvement of native GTK handling on Mac (I > > would really like to see Mono working on Mac), but that's probably > > off-topic here and outside the scope ... > > Note that there's no GTK involved here. wxMac uses Cocoa and Carbon, the > native interfaces, directly. I know. It was just a slightly off-topic discussion (but I would really be glad if wxt was ported natively to Mac - in a stable state - even though it has nothing to do with gnuplot). > > It really is important to have some native driver unless there is no > > other choice. > > That's what I've understood. Besides, there's already a plotting program > in MacOS X, called Grapher if I remember correctly. Yes, and it's really simple to use for a newbie. I don't use it (yet?) for some reason, probably because I have old code lying around, because I keep changing platforms I work on, and because it's difficult to change old habits ... but the program is really worth looking into. Thanks again, Mojca |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-07 20:57:24
|
On Monday 07 May 2007 13:43, Mojca Miklavec wrote: > > Here's one example where it looks like they are working on an aqua > > port in addition to the X11-OSX "hybrid" version we are currently using > > http://pymol.sourceforge.net/obtaining.html > > I don't know the dirty details, but I use pymol without X11 from the > beginning (MacPyMOL probably). It seems to be a pure aqua port without > traces of X11. OK, so then PyMOL is an example application that uses both command line and GUI-driver input. Perhaps it would be useful to look and see how it does so? Or does the "pure aqua" version not let you type commands into a scripting window? -- Ethan A Merritt Courier Deliveries: 1959 NE Pacific Dept of Biochemistry Health Sciences Building University of Washington - Seattle WA 98195-7742 |
|
From: Mojca M. <moj...@gm...> - 2007-05-07 21:02:00
|
On 5/7/07, Ethan Merritt <merritt@u.washington.edu> wrote: > On Monday 07 May 2007 13:43, Mojca Miklavec wrote: > > > Here's one example where it looks like they are working on an aqua > > > port in addition to the X11-OSX "hybrid" version we are currently using > > > http://pymol.sourceforge.net/obtaining.html > > > > I don't know the dirty details, but I use pymol without X11 from the > > beginning (MacPyMOL probably). It seems to be a pure aqua port without > > traces of X11. > > OK, so then PyMOL is an example application that uses both command line > and GUI-driver input. Yes. > Perhaps it would be useful to look and see how > it does so? Or does the "pure aqua" version not let you type commands > into a scripting window? Yes, of course it's possible to type commands in it - no problem. Also, an interesting example probably worth looking into is the R project. But I don't have the slightest idea what they did. I guess that they used a purely Aqua-specific solution. Mojca |
|
From: <tim...@en...> - 2007-05-07 21:59:30
|
Ethan Merritt wrote: > On Monday 07 May 2007 13:43, Mojca Miklavec wrote: > >>> Here's one example where it looks like they are working on an aqua >>> port in addition to the X11-OSX "hybrid" version we are currently using >>> http://pymol.sourceforge.net/obtaining.html >>> >> I don't know the dirty details, but I use pymol without X11 from the >> beginning (MacPyMOL probably). It seems to be a pure aqua port without >> traces of X11. >> > > OK, so then PyMOL is an example application that uses both command line > and GUI-driver input. Perhaps it would be useful to look and see how > it does so? Or does the "pure aqua" version not let you type commands > into a scripting window? > I have given a quick look... I don't know much about python, apart from the fact that it's an interpreted language, with its command line & parser. The python files have mutex locks all over the place: 93 # these locks are to be shared by all PyMOL instances within a 94 # single Python interpeter 95 96 _pymol.lock_api = threading.RLock() # mutex for API 97 _pymol.lock_api_c = threading.RLock() # mutex for C management of python threads 98 _pymol.lock_api_status = threading.RLock() # mutex for PyMOL status info 99 _pymol.lock_api_glut = threading.RLock() # mutex for avoiding GLUT In __init__.py, there's also: 76 # standard input reading thread 77 78 _pymol._stdin_reader_thread = None So it looks like it's multithreaded, with a thread dedicated to waiting for the input. Timothée |
|
From: <tim...@en...> - 2007-05-22 21:47:41
Attachments:
reworkevent.diff
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-22 23:08:39
|
On Tuesday 22 May 2007 14:47, Timoth=C3=A9e Lecomte wrote:
> 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.
The conditional dependencies look suspicious to me.
In wxt_gui.h I see this:
#if defined(__WXGTK__) || defined(__WXMAC__)
# define WXT_MULTITHREADED
#elif defined(__WXMSW__)
# define WXT_MONOTHREADED
But then in wxt_gui.cpp I see:
#ifdef WXT_MULTITHREADED
extern "C" int gnu_main(int argc, char **argv);
int main(int argc, char **argv)
{
#ifdef __WXMSW__
/* the following is done in wxEntry() with wxMSW only */
wxSetInstance(GetModuleHandle(NULL));
wxApp::m_nCmdShow =3D SW_SHOW;
#endif /*__WXMSW__*/
Is it really possible for __WXMSW__ to be defined inside of
a block marked #ifdef WXT_MULTITHREADED ?
=2D-=20
Ethan A Merritt
|
|
From: <tim...@en...> - 2007-05-23 16:28:48
Attachments:
reworkevent.diff
|
> On Tuesday 22 May 2007 14:47, Timothée Lecomte wrote:
>> 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.
>
> The conditional dependencies look suspicious to me.
>
> In wxt_gui.h I see this:
> #if defined(__WXGTK__) || defined(__WXMAC__)
> # define WXT_MULTITHREADED
> #elif defined(__WXMSW__)
> # define WXT_MONOTHREADED
>
> But then in wxt_gui.cpp I see:
>
> #ifdef WXT_MULTITHREADED
> extern "C" int gnu_main(int argc, char **argv);
> int main(int argc, char **argv)
> {
> #ifdef __WXMSW__
> /* the following is done in wxEntry() with wxMSW only */
> wxSetInstance(GetModuleHandle(NULL));
> wxApp::m_nCmdShow = SW_SHOW;
> #endif /*__WXMSW__*/
>
>
> Is it really possible for __WXMSW__ to be defined inside of
> a block marked #ifdef WXT_MULTITHREADED ?
>
> --
> Ethan A Merritt
>
You're right, the previous code did not handle the Windows case.
I've committed the comments and debugging messages changes to CVS, fixed
the code in my local copy to work for Windows too. Attached is the
corresponding patch against current CVS copy.
Thanks.
Timothée |
