On Nov 25, 2010, at 7:35 AM, Uli Kusterer wrote: > 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?
First of all the Scripting Bridge uses Launch Services if the app is not already open. I just forgot that it has different default parameters from the NSWorkspace calls I was replacing. Previously the gitx tool used NSWorkspace (launchAppWithBundleIdentifier:...) to open GitX.app and then sent it's commands through a DO proxy. The problem I was having was that the repository document would already be open when the commands (like setting the branch, branch filter, or search terms) happened and would cause the UI to flash from the default state to the new state. Once I switched away from using DO I then implemented the non openURL commands (init, clone, diff, search) as AppleScript commands. Note that I do use NSWorkspace's openURLs:... to open repository documents. BTW, thanks for bringing this up again, I apparently forgot to put this in my todo list. >>> 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. I think you're right. I thought you were talking about the gitx command line tool but it seems you were talking about gitx_askpasswd. > 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. This sounds like a much better way to do the UI. I had wondered why the GUI was in gitx_askpasswd to begin with, thought maybe it had to be there. --Nathan http://brotherbard.com/
