Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/18/06 5:26 PM, Ethan A Merritt at merritt@u.washington.edu wrote:

> On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
>> I think Per's assessment is correct. The problem is not with wxt, but with
>> the necessity for "bundling" wxWidget applications for native use on the
>> Mac. 
> 
> Bizarre O/S design.
> 
>> That requires either extensive modifications to the gnuplot make files,
>> or a special separate make file approach for the Mac.
> 
> I don't think that's true. From what I have found via Googling, nothing
> special should be required in building the application (gnuplot).
> Creating the bundle is a separate step, and could have its own Makefile
> or installation script.
> 
> I am hampered by never having had to install anything like this on a Mac,
> but it sounds to me from all your descriptions that the problem is that if
> you bundle gnuplot, its controlling terminal is not the one you launched
> it from.  Rather, it must have a controlling terminal app as part of the
> bundle.  I guess this is the iTerm approach that someone mentioned.
> Furthermore, I suspect that the info.Plist file must contain one or more
> lines that establishes that the gnuplot plot window gets the focus in
> parallel to, or instead of, the controlling terminal app.  How one does
> any of that is beyond me.
> 
> I found only one similar complaint about lack of focus via Googling.
> In that case the problem was that the application name in info.Plist
> did not precisely match the directory tree name in which the app had
> been placed. Just a thought.
> 
> Anyhow, it sounds to me like this needn't hold up a 4.2 release, because
> it is a post-build installation problem, and probably doesn't require
> changes to the gnuplot code per se.  If it turns out that minor changes
> are required in the wxt code, that can be a follow-on patch of relevance
> only to Mac users.  Maybe fink or Darwin will bundle it with gnuplot
> (in the normal sense of the word, not this strange Mac-ish meaning of
> "bundle") and provide an easy installation source for general users.

Ethan,

You are correct that this problem should not stop a gnuplot release. This is
a Mac specific issue, and if the Apple folks want to ride with their "we're
the best horse" attitude, that's OK. Without cairo/pango installed,
gnuplot-4.2.rc1 builds without problems, and works with both X11 and
AquaTerm.

Neither MacPorts (formerly DarwinPorts) nor Fink do bundling. They basically
modify open source make files and install into their own version of
/usr/local/ that they call /sw or /opt for the "unstable" branch. For older
"stable" stuff, they basically "make install" binary builds into /sw or
/opt. To the new Mac user, this looks like magic, and they don't need to
learn UNIX or navigate in /usr.

As you suggested, I tried renaming the org.gnuplot.app to gnuplot.app in
Info.plist. That did not solve the problem. We need a Mac "developer" to
examine that file. Incidentally, there are literally thousands of .plist
files on any Mac. There are some other things I can try like dragging the
application into /Applications and changing the name to
/Applications/gnuplot.app, but I'm just trying to out guess Apple about
that.

As to the terminal, keep in mind that the standard way to start any Mac
application is via a double click of the icon. No terminal is assumed. For
some other applications that I run in X11 (GMV and Geomview), I have simple
AppleScript files that first start X11, and then invoke the application. We
probably need a Mac native version of that with terminal.app or iTerm.app.
On my old pre-OSX Mac, we had the "Macintosh Programmers Workshop" which was
basically a terminal window into the OS. That was the only way to do command
line stuff. I think that this problem is a legacy of that. No Mac user
should ever be bothered with the need to use of a command line, or something
like that.

I'll keep trying, and if anything develops, I'll let folks know.

Joe