Re: Qt on Mac (no such luck, apparently)

[Mojca M. <moj...@gm...>]

(Why was the email sent under my name and not under Ethan's?)

On Thu, Jan 5, 2012 at 00:26, Mojca Miklavec wrote:
>
>> http://gitorious.org/~friesoft/dinjam/friesoft-development/blobs/master/src/sources/data/standarddirs_mac.cpp
>>
>> /**
>>  Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has always had issues
>>  on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
>>  result, in the case where we would normally fork and then dlopen code, or continue
>>  to run other code, we must now fork-and-exec.
>>
>>
>> I would be willing to debug, but I have no idea how to do so. I
>> created a ticket:
>>     https://sourceforge.net/tracker/?func=detail&aid=3469233&group_id=2055&atid=102055
>> where I attached crash report (I just realized where systems stores
>> crash reports) if that is of any help, but I'm not sure neither how to
>> debug nor how to fix anything.
>>
>> If you tell me how exactly to "exec()" after fork in qt_term.cpp, I
>> can test it, but I don't fully understand the code, so I'm not sure
>> what exactly to change and how.
>
> That's not how it works.  When you call exec() you are basically running
> a new program.  In order to create a suitable program to run, you would have
> to re-write gnuplot so that there is a separate entry path that starts up
> directly  in the state you want the separate process to be in.  Then you
> would have to re-write (I think) the communication channel between the
> original process and the new one so that the drawing commands are passed
> through in one direction and the mousing info is passed back in the other.
>
> At one point Timothée Lecomte was working on something like that for the
> wxt terminal, as another path towards getting it working under OSX.
> It is patchset #1950392 on the SourceForge tracker.
> In the end it turned out not to be necessary.
>
> Alternatively you could use gnuplot(x11.trm) + gnuplot_x11(gplt_x11.c)
> as a model. That is, create two separate programs rather than one program
> with two executaion paths.

I have no idea how communication in gnuplot works at all, so I find it
hard to comment on any of that.

> Either approach is way more complicated that just adding a few lines to
> the existing code.  It seems more reasonable simply to document that the
> qt terminal is not available under OSX.
>
> What ever happened to your efforts to get aquaterm working again?

AquaTerm works. (OK, mouse events are not implemented and there is
still a tiny unresolved bug which makes it impossible to link against
one version and use another one, but as long as a single version
exists, it should work fine.) The only problem is that gnuplot doesn't
properly handle the flags for building. It should test whether
"-framework AquaTerm" works and use that flag, but uses -laquaterm
instead. But I don't know autotools, so I don't know how to fix this.
It is a simple fix in ./configure script, but since ./configure script
is generated, just replacing
    LIBS="-laquaterm ...
with
    LIBS="-framework AquaTerm
in apple.m4 won't work since another "-laquaterm" gets generated
automatically with
    AC_CHECK_LIB(aquaterm, aqtInit,
This means that somebody should write a macro "AC_CHECK_FRAMEWORK" to
do it properly. Or maybe switch to CMake which would probably be a lot
better in the long run.

Still, if a symlink from libaquaterm.dylib to
/Library/Frameworks/AquaTerm.framework/AquaTerm exists on computer,
-laquaterm will work. But if it doesn't, it won't work without
modifications. Also, if one only installs AquaTerm with MacPorts,
gnuplot won't find it (even though it will find all other libraries
installed with MacPorts). So at the moment there is no reason to claim
that AquaTerm doesn't work on Mac.

(I have a serious problem making it work in Octave, but that's a
separate issue.)

> Do you have a set of instructions we could include with 4.6 that tells
> people where/how to get a version of aquaterm compatible with current
> OSX and gnuplot?

The latest released version of AquaTerm *is* compatible with Mac OS X
10.4-10.7 (and probably later), with PowerPC, i386 and x86_64, so that
should be no problem.

> As with qt, if this isn't really an option perhaps
> we should simply document that aquaterm is not supported under
> [OSX 10.6?  64-bit?  I kind of lost track of where the limitation
> entered].

For a long time AquaTerm didn't work on x86_64 (the binaries for
x86_64 weren't released and sources didn't compile without changing
project files). Now it works. But configuration in gnuplot is somewhat
unfortunate and often doesn't work as it should.

(Also: AquaTerm has a nasty "feature" that gnuplot will link against
one version, and when called, it will use the first one that the
system finds. If more incompatible versions are installed, this may
lead to problems. AquaTerm versions have always been compatible with
each other, but the 64 against 32-bits cause mysterious problems when
passing arguments in function calls. Environmental variables may
influence the behaviour, but it is still a bit problematic.
Nevertheless, at least it works.)

Mojca