I'm not sure if this changed in b56a6 but i noticed how when you do a google search with the web search module, it defaults to "open URL" rather then "Search For..."
On Apr 16, 10:03 am, Howard Melman <[email protected]> wrote: > On Apr 16, 2009, at 3:20 AM, Etienne Samson wrote: > > > > > Le 16 avr. 09 à 04:05, Howard Melman a écrit : > > >> On Apr 15, 2009, at 9:50 PM, Chris Cairns wrote: > > >>>> I'm not sure of your terms "hotkey area" and "description area". > > >>> I did not know how to describe them."Command" though is correct > >>> term, it is used in so for so many other things. > > >> <Picture.png> > > >> Gotcha. In such cases I usually describe how to get there. "In the > >> Triggers preferences in the command column..." > > >> I don't know that I've seen that field be "(null)" in B54. That's > >> not quite the Triggers.plist corruption problem I described though > >> it does sound vaguely familiar. > > > This (null) happens because QS fails to recover the command it > > stored in the Triggers.plist file, so it defaults to nil (and > > displays as "(null)"). This is a side-effect of me trying to fix the > > issue you've mentioned, the inability to save certain kinds of > > triggers (encapsulated commands, mainly). > > > On the corruption of the Triggers.plist file : I'm not sure it's > > exact to tell it like this. Most of the bug reports I've seen that > > show this are actually caused by the Trigger system failing to find > > the needed class for a trigger type. This is a known issue, and > > should be fixed. To reproduce, install one of the plugins that add a > > trigger type (Abracadabra, Mouse Corners, ...), create a trigger > > that use this trigger type, then disable the plugin and restart. B54 > > should hang with the now famous "Trigger.plist corruption > > problem" ;-), while B56 shouldn't. > > > I'm sorry I don't have much time to devote to QS right now, and so > > much still needs to be done... I'm currently trying to get > > uncrustify to work "perfectly" on Obj-C code, so that I can cleanup > > the whole trunk in one blow, then I'll start looking at it. > > Thanks, that all makes a lot of sense and clears up some things that > were mysteries to me. I certainly knew that removing plugins when > there were triggers defined that depended on the plugin was > problematic. I'm not sure I knew it was limited to those defining > trigger types vs any action that might be used. > > Encapsulated commands (aka command objects) were also problematic in > triggers. Here's what I wrote in the manual about them: "There’s also > an Add Trigger action but in B51 all it seems to do it open the > Triggers preference pane. It actually does add a HotKey trigger > representing the command but it doesn’t show up in the Triggers list > until you restart Quicksilver. You can then assign a HotKey to it." > > It's great to see progress being made in these areas. Thanks. > > Howard
