I tried that too - whoops, no, I didn't quit & save, I saved, then
quit. Will try again and let you know.
thx

On Mar 30, 12:42 pm, AquaMethod <[email protected]> wrote:
> 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, reply using "remove me" as the subject.

Reply via email to