That sounds like a great idea! I want to think that some of that grown work might be in place. I know some apps will show you recently opened file if you arrow over.
On Feb 11, 3:01 pm, [email protected] wrote: > On 11 Feb 2009, at 10:38, Etienne Samson wrote: > > > > >> That said, as someone who has no knowledge of programing am more > >> concerned with testing out the bleeding edge of QS. First we need > >> some > >> method of a lot people test out the current builds without effecting > >> there current setup (much). Using the current builds seems to be hit > >> or miss with people. Basic funcations such as activation QS just > >> don't > >> work for some people. I would like to know if the current plugin > >> system ready to have plugins? if so, i think documention is in order. > >> Triggers would be the next to that would needing solidifying. > > > IIRC, v2 is able to recieve plugin, but as you say, it requires > > documentation. It's not completely different from the old system > > (which stores plugin stuff in Info.plist), because I've been able to > > slacking port old plugin to the new architecture without much > > trouble (means I just had to write the element.xml file, converting > > it from the data in Info.plist, and it was at least partially working. > > It'd be really nice to get some solid development documentation down > about plugins anyway, I think. > If we could get to a point with quicksilver where apps were able to > register their own plugins (as with growl) or similar, that would be > really cool. But even just to a point where it's easy enough to write > one that it will motivate application writers into contributing the > plugins themselves, that would be a good place to be. ^_^
