On Oct 19, 2010, at 6:23 AM, Nathan Kinsinger wrote: >> What are you using to launch the app? You *should* be using Launch Services. >> Launching it directly leads to issues like this one. One *could* use >> TransformProcessType() like the password command line tool does, but avoid >> that if you can. > > It's using the scripting bridge, but apparently I need to set the launch > flags (SBApplication -setLaunchFlags:) as the default includes > kLSLaunchDontSwitch.
Why would you use the scripting bridge for launching an application when there's a perfectly good Launch Services call that does it in one API call? >> That reminds me, would be nice if someone rewrote the command line tool to >> be faceless and send an Apple Event to GitX.app to do the actual asking, >> then retrieved the string from that and printed it again. > > I did rewrite it to use scripting, but I don't have anything that returns > content. If you want to see output in the terminal why wouldn't you use git? Huh? What output in the Terminal? I think there's a misunderstanding here. Right now, we launch two GUI applications: GitX, and the password helper. The problem with that is that GitX is blocked in the background, and the helper doesn't have a proper menu bar with Copy & paste menu items and the other things a user expects. What users really expect is that the password dialog is part of GitX itself in the GUI, just one more window (or a sheet on a window). So ideally, we'd turn the password helper into a faceless background tool (we need to keep it because that's what SSH_ASKPASS expects). Then the background tool's sole job would be to send an Apple Event to GitX and tell it to show a password panel, and wait for GitX (blocking the git command line tool until the user has given an answer). When the user closes the password panel, GitX would send an Apple Event back to the password helper tool, and the password helper tool would give that password back to git (which it currently does by simply echoing the password to the console). This would move the password panel into the GitX process proper, and make it share GitX's menu bar (so it'd have Copy and Paste menu items etc.), and even more importantly bring the *password panel* to front when a user clicks GitX's dock icon, not put a weirdly-waiting GitX in front of the password panel the user really wants to deal with right now. NB - I'm not hell-bent on using Apple Events for the communication. It'd be fine to use something else, mach messages or DO or whatever you feel like. Also, we'd probably have to pass some identifier as a parameter to the password helper tool (specify it in SSH_ASKPASS, I think one can do that) so it can tell GitX for which repository and on which window it should show the password sheet. After all, users can have several repositories open. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..."
