One fix I've used is to open the file they mentioned above (/Users/ name/Library/Application Support/Quicksilver/Triggers.plist) after you create a trigger, but before closing Quicksilver. Keep the file open as you quit Quicksilver, and once Quicksilver has terminated, save the file you have open.
On Mar 30, 9:26 am, tuniTMF <[email protected]> wrote: > my problem with the triggers disappearing on shut down continues tool. > Do not understand all the technical scripting stuff you and Paul > describe - that is totally beyond me - however, this just is so > frustrating. Have totally removed and reinstalled the application so > many times. Even went to a previous version (34) I believe but it does > not play well with Snow Leopard. Unless I can get this trigger issue > resolved, unfortunately, QS is really of little value to me at this > point. I don't give up easily but have been trying to get it to work > properly for almost a month....It should not be this complicated. > Does any one know of an easy (to understand for a non-geek person) > fix???? > many thanks, > tuni > > On Mar 28, 3:53 pm, rectalogic <[email protected]> wrote: > > > > > I'm having the same problem. The trigger is enabled in the plist. But > > on restart, the trigger shows up in the Custom Triggers list, with the > > enabled checkbox checked and the correct hotkey, and the correct "Run > > script" action, but the script arguments are all null. i.e. it shows > > "Run script: (null)" > > > This is the trigger I'm using, but the "Get IP" trigger you posted has > > the same issue (if I paste that XML into my Triggers.plist, it shows > > up enabled but with "Run Script: (null)" and nonfunctional. > > > <dict> > > <key>ID</key> > > > > <string>A4885393-359A-49C3-8A43-F82A3646AEF2</string> > > <key>command</key> > > <dict> > > <key>actionID</key> > > <string>QSShellScriptRunAction</string> > > <key>directID</key> > > > > <string>/Users/aw/Projects/rectalogic/window-manager/ > > window_manager.rb</string> > > <key>indirectID</key> > > > > <string>/Users/aw/Projects/rectalogic/window-manager/layout.yaml</ > > string> > > </dict> > > <key>enabled</key> > > <true/> > > <key>keyCode</key> > > <integer>83</integer> > > <key>modifiers</key> > > <integer>2490627</integer> > > <key>onPress</key> > > <true/> > > <key>type</key> > > <string>QSHotKeyTrigger</string> > > </dict> > > > If I set a breakpoint in QSCommand-dObject and bring up the Triggers > > preferences, when my custom trigger hits the breakpoint both QSObject- > > objectWithIdentifier: and QSAction-actionWithIdentifier: return nil > > because the identifier being used is the "directID" in the commandDict > > and that's the path to my script. So dObject (and also iObject) never > > get set. It's using the pathnames as identifiers and trying to look > > them up in the objectDictionary or actionIdentifiers. > > > (gdb) po [self commandDict] > > { > > actionID = QSShellScriptRunAction; > > directID = "/Users/aw/Projects/rectalogic/window-manager/ > > window_manager.rb"; > > indirectID = "/Users/aw/Projects/rectalogic/window-manager/ > > layout.yaml"; > > > } > > > When I manually reset the trigger in preferences, it is calling > > QSCommand-initWithDirectObject:actionObject:indirectObject: and > > QSCommand-setIndirectObject: etc. which is why it works then. > > > So maybe QSCommand-dObject etc. need to handle the case where > > "directID" exists in the commandDict, but is not a valid QSObject or > > QSAction identifier, and in that case do > > [self setDirectObject:[QSObject objectWithName:[[self commandDict] > > objectForKey:@"directID"]]] > > > Andrew To unsubscribe from this group, send email to blacktree-quicksilver+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
