Hi !
I've updated both the branch and trunk so that they build.
Only thing you need to do is modifying the Configuration/
Developer.xcconfig file (but I'll try to make this go away) BEFORE
opening the project (else Xcode get some of its paths wrong).
I'll try to have some documentation handy soon, at least for the core
stuff, then I'll merge the changes I did to the branch to trunk, so
that they are in sync, then I'll revert some of the big changes I done
to the branch which broke some stuff (or maybe fix them, I'm thinking
about the issue with non-ASCII characters, which is fixed in the
branch, but it broke the ability to match non contiguous letters).
I'll be hanging around irc://irc.freenode.net/quicksilver, for those
who want to talk about QS and its future ;-). You can also have a look
at the TODO file I added in trunk, to see some of the stuff to be done
there.
Le 12 févr. 09 à 00:03, Dorian a écrit :
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.
One of the stuff I just realized is that when ß5x is ran after a trunk
build, it reverts its settings back to zero, prompting you with the
initial setup again :-(.
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. ^_^
That sounds like a great idea! I want to think that some of that grown
work might be in place.
Yes, having this ability would be nice. What I though was maybe learn
the full power of AppleScripting to QS, so it could parse an
application Dictionary and automatically provide actions and objects
for it. But having this is obviously a plus.
I know some apps will show you recently opened file if you arrow over.
I'm pretty sure this is Quicksilver functionality (but I could be
wrong) that selects among the "recently opened docs" the one
corresponding to the app you've selected.
