[Fwd: Qt/Mac can't find the display server]

Getting desperate, asking the Qt folks too now.  =)

-------- Original Message --------
Subject: Qt/Mac can't find the display server
Date: Wed, 21 Jan 2004 09:20:58 -0500
From: Benjamin Reed <[email protected]>
Organization: DFT
To: [email protected]
CC: Trolltech <[email protected]>

I know this is documented as "you must put your application inside an
app bundle for it to work", but I was wondering if you have any input on
another way to handle things.

I'm one of the guys working on porting KDE to Qt/Mac.  We're running
into an issue that seems to have no reasonable workaround, and it's a
problem with the way Qt talks to Quartz.

The lowdown is:

KDE, in many places, forks, and then dynamically loads code that may or
may not put up windows.  Fork, however, *loses* all references to the
display server because references to mach ports are not preserved across
a fork.

I can changes things so that applications are always launched through
their app bundles, but this means that it's impossible to pass arguments
to the app.  ie, instead of:

kdeinit fork()s
kdeinit instantiates a KApplication (which is really just a QApplication)
kdeinit dlopens kcmshell.so
kdeinit runs the kcmshell main-equivalent

...I would do:

kdeinit fork()s
kdeinit open(1)s /Applications/KDE/kcmshell.app
kcmshell instantiates a KApplication and shows it's GUI

The problem is, there's no way to pass arbitrary arguments to an app
bundle with open (or even launchservices, as far as I can tell).  The
only way for me to do so is to run
/Applications/KDE/kcmshell.app/Contents/MacOS/kcmshell -foo -bar

But when you do that with a Qt app, it can't talk to the display server.
  (If you open, say, iPhoto with a direct path to it's bundled
executable, it *does* work, though, so it must be some limitation of Qt,
and not necessarily any MacOSX GUI app).

The only workaround I can think of is to make Contents/MacOS/kcmshell a
shell script that sources it's arguments from a file that's been
previously written before the app gets launched, but that's prone to
horrible race conditions, since there's no way to uniquely identify
multiple simultaneous executions of an app.

Do you have any suggestions?  Is there a way to make Qt apps properly
talk to quartz without calling them through launch services?

This is a showstopper for the KDE port.  There's no simple way to
rearrange the way kdeinit starts things for it to play nicely.

-- 
Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
gpg: 6401 D02A A35F 55E9 D7DD  71C5 52EF A366 D3F6 65FE
You had me at HELO.