Re: Building wxt terminal for OS X

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

On Oct 26, 2006, at 01:32, Joe Koski wrote:

>>
> Timoth=E9e, Per,
>
> I tried both approaches to resolve the focus problem with my =20
> gnuplot binary,
> but the problem persists. Thanks to Timoth=E9e for finding the links =20=

> that
> clearly state the problem, and also state the solutions.
>
> First I tried making a simple gnuplot.app structure like the one in =20=

> the web
> page
>
>   http://www.wxwidgets.org/wiki/index.php/=20
> App_Not_Getting_Input_When_Run
>
> but, if you try to execute gnuplot, it probably needs to launch a =20
> terminal
> application like iTerm.app, then gnuplot via a script so you can =20
> communicate
> with the gnuplot. (I think that's what Per was hinting to me a year =20=

> or more
> back when he suggested iTerm.app, while we were trying to figure =20
> out how to
> bundle octave). When I double-clicked gnuplot.app, the hard disk =20
> made a
> noise, but nothing happened.
>
> Then I tried the Rez incantation
>
> jakoski$ /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -i =20=

> gnuplot
> -d WXUSINGDLL -o gnuplot Carbon.r
>
> and, indeed, something happened to gnuplot, as there was a delay of =20=

> a second
> or two at the command line while the hard disk made noise, and no =20
> errors
> were reported. When I tried the resulting Rez modified binary, it =20
> worked,
> but the focus problem remained. Do we need a separate wxt.app, or =20
> is that
> called AquaTerm?
>
> Unless we can get the Rez modification to work, there are some =20
> important
> implications for gnuplot here, and I think Per can give us some =20
> insight
> based on his experience with gnuplot and AquaTerm.
>
> If I am interpreting this correctly, the only sensible way to =20
> distribute
> gnuplot-4.2 for Macs, with the wxt terminal included, is via a bundled
> application.

Yes. I wasn't sure whether Timoth=E9e's addition was in fact a complete =20=

wxGnuplot or just a terminal (see older mail). The point here is that =20=

with wxMac/wxCocoa *everything* must be wrapped up in a single wx-=20
application.
As you guessed, AquaTerm is simply a mechanism to (seamlessly) detach =20=

the process doing the drawing (e.g. gnuplot) and the process doing =20
the rendering (AquaTerm) in a controlled manner.

As an experiment, pull out the wxWhatever.app/Contents/MacOS/whatever =20=

execuatable from any wxMac demo and start it at the prompt, and =20
you'll see the can't-get-any-events behaviour.

*However*, X11 on Mac OS X is the same as on any other platform, so =20
the focus problem shouldn't arise if you used wxWidgets for X11.


> This is great for the end user (easy installation), but
> requires significantly more work on the Mac development end to pull =20=

> things
> together.

A guesstimate is that a proper[1] port to make gnuplot a self-=20
contained Cocoa application is about the same amount of work as a =20
wxMac port. It all comes down to how familiar you are with the =20
respective class libraries etc.

[1] With proper I don't mean to imply that other ways aren't any =20
good, just that *on the Mac* Cocoa provides the richest application =20
environment, enjoys full benefit from systemwide improvements, =20
adheres automatically to look-and-feel, well supported etc. Someone =20
would still have to maintain it though.

>
> A Mac .dmg installer is probably indicated to also install header =20
> files,
> etc. so that octave and other open source applications can find =20
> gnuplot
> during builds. Fortunately, gnuplot doesn't change every five =20
> minutes like
> octave does, so this is probably doable without too much burden on the
> developers in the long run, once the approach is perfected.
>
> We could sure use a knowledgeable Mac developer about now. I do not =20=

> claim to
> be one, so any and all advice will be given careful consideration.

While I wouldn't mind to be considered for the above category, I have =20=

even less time than usual at my disposal.
In fact, we should try to find someone (preferrably with an Intel =20
based Mac) willing to help out with Mac development since:
1) it is not likely that I will have more time to spend on open =20
source project in the near future
2) I can't test/fix problems related to Intel Macs

/Per