Odd non-fatal GIMP Behavior

Michael Crawford mdcrawford at gmail.com
Tue Nov 18 14:22:32 PST 2014

If you select a document in the Finder, then ask that it be opened in
an application - or just double-click it - the Finder will launch the
application, then shortly after it will send the application an "Open
Document" Apple Event.

However, GIMP is a *NIX/X11 application, so it does not natively
support Apple Events, which were introduced in Mac OS System 7.  So
somewhere in there, there must be a "wrapper" that receives the Apple
Event as if it were a regular sort of native OS X program - Cocoa or
Carbon - then it translates the request into something that the native
Linux GIMP builds would do.

Quite likely the problem is not actually in libiconv, but something
else is screwed up earlier in time, but only causes trouble when
libiconv is called.

My understanding is that the original Apple Event Manager as
documented in Inside Macintosh, Volume 6 works completely unmodified
to this very day - it's binary compatible, you don't even need to
recompile old source - but you're going to have a hard time getting
anyone at Apple to admit to that fact.  The closest any of today's
"Official" Apple developer doc comes to mentioning Apple Events is
that Cocoa provides some support in Cocoa/Objective-C code that's
required to support AppleScript.  But what AppleScript actually does
is send Apple Events to event-driven applications, as well as receive
them from those apps.

More or less an Apple Event is a network packet that's dropped into
your GUI event quite along with mouse clicks and keypresses.

I wrote a paper on the Word Services Apple Event Suite for the MacHack
'94 conference proceedings that explains Apple Events in general
pretty well, there is also a Develop magazine article called "Apple
Event Objects and You" that I have a PDF of.

However my old site fell over, I haven't put this stuff up on my new
site yet.  I'll do so in the next day or so.  Also I have some
straightforward sample code in C.

Hope That Beats The Subject Completely To Death,

Michael David Crawford
mdcrawford at gmail.com

   Available for Software Development in the Portland, Oregon Metropolitan

On Tue, Nov 18, 2014 at 10:58 AM, Jeff Singleton <gvibe06 at gmail.com> wrote:
> On 11/18/14 12:34 PM, Ryan Schmidt wrote:
>>> On Nov 18, 2014, at 12:30 PM, Jeff Singleton wrote:
>>> On 11/18/14 12:20 PM, Ryan Schmidt wrote:
>>>> otool -L/Users/USER/*/GIMP.app/Conte
>>> jsingleton at minimac ~ $  lipo -info /opt/local/lib/libiconv.2.dylib
>>> Non-fat file: /opt/local/lib/libiconv.2.dylib is architecture: x86_64
>>> jsingleton at minimac ~ $  lipo -info
>>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib
>>> Non-fat file:
>>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib is
>>> architecture: x86_64
>> Ok, so the architectures match.
>>> jsingleton at minimac ~ $  otool -L
>>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib
>>> /Applications/GIMP.app/Contents/Resources/lib/libgobject-2.0.0.dylib:
>>>         /opt/local/lib/libgobject-2.0.0.dylib (compatibility version
>>> 4201.0.0, current version 4201.1.0)
>>>         /opt/local/lib/libglib-2.0.0.dylib (compatibility version
>>> 4201.0.0, current version 4201.1.0)
>>>         /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0,
>>> current version 8.1.0)
>>>         /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
>>> version 1.0.0)
>>>         /opt/local/lib/libffi.6.dylib (compatibility version 7.0.0,
>>> current version 7.2.0)
>>>         /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0,
>>> current version 10.2.0)
>>>         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
>>> (compatibility version 2.0.0, current version 157.0.0)
>>> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
>>> (compatibility version 300.0.0, current version 1151.16.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>>> version 1213.0.0)
>> This looks reasonable. It's linked with the correct libiconv library.
>> You're sure we're looking at the correct GIMP.app here? The error message
>> implied the GIMP.app was in /Users but this one is in /Applications.
>>> jsingleton at minimac ~ $  echo $DYLD_LIBRARY_PATH
>>> jsingleton at minimac ~ $
>> Ok... so you don't have it set in your terminal. But does GIMPskel set it?
> I launched GIMP.app from /Applications ... and I don't really get why the
> crash dump would substitute my actual Users folder with /Users/USER/*/? Is
> that a built-in alias for my actual Users folder?
> Because GIMP.app is definitely not in my Users folder. Has my Yosemite lost
> its marbles?
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

More information about the macports-users mailing list