gnuplot-beta

"wxt on Mac": news

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

Dear Mojca, Joe, and all gnuplot enthusiasts,

Here are some news about the availability of the wxt terminal for the
MacOS platform. I have had the chance to get my hands on my MacBook and I
have worked a little bit on the issues you got when trying to use the wxt
terminal.

To sum up where we were last time we talked about it:

- building seems to be ok. The most painful part is to build recent enough
(i.e. using Fink) glib, cairo, pango & wxWidgets. Fortunately, this is
almost to be done the Unix way, 'configure; make; make install'. The
exceptions are to disable features for cairo so that it doesn't ask for
Freetype or fontconfig (useless here).

- executing gnuplot and trying to use wxt, you successfully get plot
windows, but those seem to be "dead". The mouse changes to a colorful
pinwheel, the buttons on the top (close, minimize, maximize) are grayed
out, and you cannot grab the window to move it.

- from my researches, "bundling" is necessary, but it didn't seem to
change anything when done on gnuplot.

So, I've investigated regarding this problem:
- bundling is indeed necessary. I wrote a sample wxWidgets app, and tried
to launch it without bundling it. It doesn't get the focus. BUT the mouse
cursor stays the same, and the buttons on the top bar do work. So it's not
really the root of the problem with the wxt terminal.

- I tried on the sample app what is the second most important aspect of
the wxt implementation: putting the event loop in a separate thread. And
bingo ! I get the same problem as with wxt... Although the separate thread
and its event loop are running, the latter does not process the window
events. It turns out that this is a limitation of Cocoa app (MacOS
programming toolkit):
"The main thread of the application is responsible for handling events.
The main thread is the one blocked in the run method of NSApplication,
usually invoked in an application’s main function. "
(http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/articles/CocoaSafety.html)

I've searched for this "run" method in the wxWidgets code, but could not
find it. MacOS development involves a mixture of layers called Foundation,
Cocoa and Carbon (like GLib, Cairo, GTK and friends) and I'm afraid this
'run' method is in fact hidden somewhere else. Anyway, I tried to do as
much initialization as I could in the separate thread, but it didn't work
either.

So there is one remaining thing to try, but this will involve more work on
my part: changing the way wxt works on Unix and Mac and arrange it so that
the main thread runs the event loop while the usual gnuplot command-line
loop runs in the separate thread. The challenge is to do that only when
wxt_init() is called, not before (doing it at startup time is easy, but I
don't feel like it would be the right way).
(note that on Windows we don't have this problem because the fake terminal
already has the event loop and runs gnuplot command loop inside it)
(as far as aquaterm is concerned, it has another design again, something
like the X11 terminal: the GUI is in a different program with its own loop
and talking with gnuplot through some interprocess communication
mechanism)

If some of you feel some inspiration regarding this issue, I would
appreciate to listen to them !

Best regards,

Timothée Lecomte

Re: "wxt on Mac": news

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

On Friday 30 March 2007 10:41, Timoth=E9e Lecomte wrote:
> So there is one remaining thing to try, but this will involve more work on
> my part: changing the way wxt works on Unix and Mac and arrange it so that
> the main thread runs the event loop while the usual gnuplot command-line
> loop runs in the separate thread.

Won't this prevent switching to another interactive terminal type?

Sounds to me that Cocoa is broken by design.  Given this design limitation,
I suspect it would be easier/better to use the gnuplot+gnuplot_x11 model.
Instead of running wxt as a daughter thread, spawn a separate process
for which it is the main thread.

	Ethan

> Dear Mojca, Joe, and all gnuplot enthusiasts,
>=20
> Here are some news about the availability of the wxt terminal for the
> MacOS platform. I have had the chance to get my hands on my MacBook and I
> have worked a little bit on the issues you got when trying to use the wxt
> terminal.
>=20
> To sum up where we were last time we talked about it:
>=20
> - building seems to be ok. The most painful part is to build recent enough
> (i.e. using Fink) glib, cairo, pango & wxWidgets. Fortunately, this is
> almost to be done the Unix way, 'configure; make; make install'. The
> exceptions are to disable features for cairo so that it doesn't ask for
> Freetype or fontconfig (useless here).
>=20
> - executing gnuplot and trying to use wxt, you successfully get plot
> windows, but those seem to be "dead". The mouse changes to a colorful
> pinwheel, the buttons on the top (close, minimize, maximize) are grayed
> out, and you cannot grab the window to move it.
>=20
> - from my researches, "bundling" is necessary, but it didn't seem to
> change anything when done on gnuplot.
>=20
> So, I've investigated regarding this problem:
> - bundling is indeed necessary. I wrote a sample wxWidgets app, and tried
> to launch it without bundling it. It doesn't get the focus. BUT the mouse
> cursor stays the same, and the buttons on the top bar do work. So it's not
> really the root of the problem with the wxt terminal.
>=20
> - I tried on the sample app what is the second most important aspect of
> the wxt implementation: putting the event loop in a separate thread. And
> bingo ! I get the same problem as with wxt... Although the separate thread
> and its event loop are running, the latter does not process the window
> events. It turns out that this is a limitation of Cocoa app (MacOS
> programming toolkit):
> "The main thread of the application is responsible for handling events.
> The main thread is the one blocked in the run method of NSApplication,
> usually invoked in an application=92s main function. "
> (http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading=
/articles/CocoaSafety.html)
>=20
> I've searched for this "run" method in the wxWidgets code, but could not
> find it. MacOS development involves a mixture of layers called Foundation,
> Cocoa and Carbon (like GLib, Cairo, GTK and friends) and I'm afraid this
> 'run' method is in fact hidden somewhere else. Anyway, I tried to do as
> much initialization as I could in the separate thread, but it didn't work
> either.
>=20
> So there is one remaining thing to try, but this will involve more work on
> my part: changing the way wxt works on Unix and Mac and arrange it so that
> the main thread runs the event loop while the usual gnuplot command-line
> loop runs in the separate thread. The challenge is to do that only when
> wxt_init() is called, not before (doing it at startup time is easy, but I
> don't feel like it would be the right way).
> (note that on Windows we don't have this problem because the fake terminal
> already has the event loop and runs gnuplot command loop inside it)
> (as far as aquaterm is concerned, it has another design again, something
> like the X11 terminal: the GUI is in a different program with its own loop
> and talking with gnuplot through some interprocess communication
> mechanism)
>=20
> If some of you feel some inspiration regarding this issue, I would
> appreciate to listen to them !
>=20
> Best regards,
>=20
> Timoth=E9e Lecomte
>=20
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> 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

Re: "wxt on Mac": news

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

> On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>> So there is one remaining thing to try, but this will involve more work
>> on
>> my part: changing the way wxt works on Unix and Mac and arrange it so
>> that
>> the main thread runs the event loop while the usual gnuplot command-line
>> loop runs in the separate thread.
>
> Won't this prevent switching to another interactive terminal type?
>
> Sounds to me that Cocoa is broken by design.

Well, X11 is more flexible, but has its own little problems ;) Note that
Windows has the same limitation (GUI loop in the main thread).
My thinking is more than gnuplot was bit designed for this kind of things.
I have put a lot of thoughts into a better design, I'm not quite there
yet, but we never know ... (it's quite close to our problem with "keep
processing terminal events even when it's not the current one" for which
we have an entry in the tracker).

> Given this design limitation,
> I suspect it would be easier/better to use the gnuplot+gnuplot_x11 model.
> Instead of running wxt as a daughter thread, spawn a separate process
> for which it is the main thread.
>
> 	Ethan

That's an option, with its own issues (locating the executable, using an
interprocess communication mechanism - pipes are not available on Windows
-, bottlenecks in this mechanism, etc.).

Timothée

Re: "wxt on Mac": news

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

>> On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>
> My thinking is more than gnuplot was bit designed for this kind of things.

s/than/that
s/bit/not

>
> Timothée
>
>

Re: "wxt on Mac": news

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

On Friday 30 March 2007 12:49, Timoth=E9e Lecomte wrote:
> > On Friday 30 March 2007 10:41, Timoth=E9e Lecomte wrote:
> >> So there is one remaining thing to try, but this will involve more
> >> work on my part: changing the way wxt works on Unix and Mac and
> >> arrange it so that the main thread runs the event loop while the
> >> usual gnuplot command-line loop runs in the separate thread.
> >
> > Sounds to me that Cocoa is broken by design.
> > Given this design limitation,
> > I suspect it would be easier/better to use the gnuplot+gnuplot_x11 mode=
l.
> > Instead of running wxt as a daughter thread, spawn a separate process
> > for which it is the main thread.
>=20
> That's an option, with its own issues=20
> (locating the executable,=20
  should not be an issue on OSX

> using an interprocess communication mechanism
  already works on OSX for x11 terminal; this should be no worse

> - pipes are not available on Windows=20
  not relevant to OSX, surely?

> -, bottlenecks in this mechanism, etc.).
  This one is a real issue, however.
  One my linux machines, the wxt terminal is somewhat slower than x11,
  and x11 is already limited partly by the pipe throughput between=20
  gnuplot and gnuplot_x11.
  The question is: would the slowdown due to limited pipe throughput
  be additive with the slowdown due to using wxt, or is it partially
  masked by it?  I.e. does the pipe transfer overlap with the execution
  of drawing commands?  If so, then the additional slowdown due to=20
  piping may be minimal in practice.


Other possible solution:

Some quick googling led me to some pages that seem to imply that
apps have a choice between using carbon or cocoa.  If this problem is
due to a mis-feature in cocoa, do we have the option of using carbon
instead?  (I've never done development on OSX, and have only a vague
idea what the difference between the two is, other than historically).



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

Re: "wxt on Mac": news

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

> On Friday 30 March 2007 12:49, Timothée Lecomte wrote:
>> > On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>> >> So there is one remaining thing to try, but this will involve more
>> >> work on my part: changing the way wxt works on Unix and Mac and
>> >> arrange it so that the main thread runs the event loop while the
>> >> usual gnuplot command-line loop runs in the separate thread.
>> >
>> > Sounds to me that Cocoa is broken by design.
>> > Given this design limitation,
>> > I suspect it would be easier/better to use the gnuplot+gnuplot_x11
>> model.
>> > Instead of running wxt as a daughter thread, spawn a separate process
>> > for which it is the main thread.
>>
>> That's an option, with its own issues
>> (locating the executable,
>   should not be an issue on OSX
>
>> using an interprocess communication mechanism
>   already works on OSX for x11 terminal; this should be no worse

right

>
>> - pipes are not available on Windows
>   not relevant to OSX, surely?
>

My point is that I want to share code/implementation for as more platforms
as possible.

>> -, bottlenecks in this mechanism, etc.).
>   This one is a real issue, however.
>   One my linux machines, the wxt terminal is somewhat slower than x11,
>   and x11 is already limited partly by the pipe throughput between
>   gnuplot and gnuplot_x11.
>   The question is: would the slowdown due to limited pipe throughput
>   be additive with the slowdown due to using wxt, or is it partially
>   masked by it?  I.e. does the pipe transfer overlap with the execution
>   of drawing commands?  If so, then the additional slowdown due to
>   piping may be minimal in practice.
>

You're right, in the current situation of cairo performance, the
bottleneck would be the drawing. But the current situation is using only
software rendering, whereas Cairo can also draw directly to native
"surfaces" (it's what is done in wxt on Windows, and the rendering is
indeed faster than with linux, where the rendering is done purely in
software) and such a performance gain may put the pipe as the bottleneck
again.

But still, if it's really more practical to have a separate process, it
may be worth it.

>
> Other possible solution:
>
> Some quick googling led me to some pages that seem to imply that
> apps have a choice between using carbon or cocoa.  If this problem is
> due to a mis-feature in cocoa, do we have the option of using carbon
> instead?  (I've never done development on OSX, and have only a vague
> idea what the difference between the two is, other than historically).
>

Unfortunately, _wxWidgets_ already uses both, and apart from dropping
wxWidgets, I don't see a solution (FYI the MacOS port of GTK+ seems to do
the same, i.e. use both Cocoa and Carbon for fine-tuning).
Cocoa is object-oriented, written in "Objective-C", whereas Carbon is pure
C. The object-oriented approach is supposed to be more adapted for GUI
development.

Best regards,

Timothée

Re: "wxt on Mac": news

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

On Friday 30 March 2007 10:41, Timoth=C3=A9e Lecomte wrote:
>=20
> - I tried on the sample app what is the second most important aspect of
> the wxt implementation: putting the event loop in a separate thread. And
> bingo ! I get the same problem as with wxt... Although the separate thread
> and its event loop are running, the latter does not process the window
> events. It turns out that this is a limitation of Cocoa app (MacOS
> programming toolkit):
> "The main thread of the application is responsible for handling events.
> The main thread is the one blocked in the run method of NSApplication,
> usually invoked in an application=C2=92s main function. "
> (http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading=
/articles/CocoaSafety.html)

Hmm. I'm not sure I read that document the same way you do. It says:

Events
The main thread of the application is responsible for handling events.
The main thread is the one blocked in the run method of NSApplication,
usually invoked in an application=E2=80=99s main function. While the Applic=
ation
Kit continues to work if other threads are involved in the event path,
operations can occur out of sequence. For example, if two different
threads are responding to key events, the keys could be received out of ord=
er.
By letting the main thread process events, you achieve a more consistent us=
er
experience. Once received, events can be dispatched to secondary threads for
further processing if desired. You can call the postEvent:atStart: method of
NSApplication from a secondary thread to post an event to the main thread=
=E2=80=99s
event queue. Order is not guaranteed with respect to user input events, how=
ever.
The main thread of the application is still responsible for handling events
in the event queue.

Note the phrase: "if two different threads are responding to key events,
the keys could be received out of order".  To me that implies that it is
indeed possible to do event handling in the daughter threads.  It is just
warning you that the sequence of handling is not guaranteed, which is not
surprising.

> I've searched for this "run" method in the wxWidgets code, but could not
> find it. MacOS development involves a mixture of layers called Foundation,
> Cocoa and Carbon (like GLib, Cairo, GTK and friends) and I'm afraid this
> 'run' method is in fact hidden somewhere else.

Perhaps section 4.2.2 of this document is useful?

    developer.imendio.com/files/ developer/Porting-Gtk-MacOSX.pdf=20



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

Re: "wxt on Mac": news

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

Timothée Lecomte wrote:
> Dear Mojca, Joe, and all gnuplot enthusiasts,
>
> Here are some news about the availability of the wxt terminal for the
> MacOS platform. I have had the chance to get my hands on my MacBook and I
> have worked a little bit on the issues you got when trying to use the wxt
> terminal.
>
> (...)
>
> So there is one remaining thing to try, but this will involve more work on
> my part: changing the way wxt works on Unix and Mac and arrange it so that
> the main thread runs the event loop while the usual gnuplot command-line
> loop runs in the separate thread. The challenge is to do that only when
> wxt_init() is called, not before (doing it at startup time is easy, but I
> don't feel like it would be the right way).
> (note that on Windows we don't have this problem because the fake terminal
> already has the event loop and runs gnuplot command loop inside it)
> (as far as aquaterm is concerned, it has another design again, something
> like the X11 terminal: the GUI is in a different program with its own loop
> and talking with gnuplot through some interprocess communication
> mechanism)

Hey people, here are some more news about "wxt on Mac". I've found some 
time yesterday to investigate a little further. I found that wxMac has 
some limitations :

- the GUI thread (i.e. the one running the GUI event loop) has to be the 
main thread. I had some success making the second thread be the GUI one, 
but still a lot of issues come after that, because:
- GUI calls should all be done in the same thread. With wxGTK, there's a 
mutex locking mechanism, but it seems that it's really not working on wxMac.

So far, I was able to make wxt work by :
-at startup, first initialize wxWidgets
-create a second thread that run gnu_main (otherwise called main in plot.c)
-start the event loop in the main thread
and use messages to tell the GUI event loop to do something, instead of 
doing it directly in the second thread.

(it may seem very close to a two process-scheme, such as what is done 
for the X11 terminal, but I don't want to have to deal with 
inter-process communication, or fork+exec for now ;)

So, it's working !

The drawback is that there will be problems if, one day, we want to do, 
for example, a GTK terminal with a similar design... there may be some 
sort of clash between the two wanting for their main loop be in the main 
thread... but that day is probably quite far !

I'll be cleaning up the corresponding patch in the next days if I have 
some time again, and I'll send it to the list as soon as it's ready.

Best regards,

Timothée