What happens with Quicksilver?

[Jo_y]

The development of Qs is really stopped?
sounds absurdly,
what can i do without Qs?
everything of handy for mac seems to vanish without Qs
(please don't remember me of spotlight....grr )

[Howard Melman]

There hasn't been any QS development for the average user to make use
of for well over a year. QS still (mostly) performs what it did
before. The interesting news is that the author is working on Google
Quick Search Box and that seems to be the spiritual successor of QS.
It's still to early to replace QS for all but the most basic
functions, but development is active on it.

Howard

[Jo_y]

> There hasn't been any QS development for the average user to make use  
> of for well over a year. QS still (mostly) performs what it did  
> before. The interesting news is that the author is working on Google  
> Quick Search Box and that seems to be the spiritual successor of QS.  
> It's still to early to replace QS for all but the most basic  
> functions, but development is active on it.
>
> Howard

Thanks for the info, Howard.
I can't understand why developers continue to produce new
applications, if millions of people has been loved Qs for so long
time. (Perhaps because everything has his price, and this successfully
free app has never harvested enough support and donations..all the
time of his products life)
In the last times Qs crashes very often, so i will begin to trash some
plugins and in the same time to look for something similar (gestures,
file actions, clipboard and shelf, trigger system)
Google Quick Search Box is only in alpha, and i hope in a worthy
successor in this one; i hope that GQs are really better as Qs, if
Google pays something for this new project, instead to refresh the old
one Qs. What are the requirements to run Google Quick seach?
Internet ? HOPEFULLY NO. Google is spying everything...

(The same senseless situation is to apply at Cinepaint and Gimp:
everybody tries to "rock" for his own way, insteady to unify the
forces and to continue to believe and develop for the better one
application.)

[Dorian]

Yea, it's a real shame but quicksilver seems to be dead.
The original author has said how QS needs a re-write and how other
software has a better idea on how thinks should run. (check out the
google talk he gave).
if you goto: http://code.google.com/p/blacktree-alchemy/issues/detail?id=15#c3
someone has been wanting to help but nobody from the Dev team has
replied to the original post. It's really sad but i can't think QS any
else but dead.QSB is great, but still missing some key stuff. Any
information sending can be disabled but they claim that most info is
for crashing/etc. I really don't like the idea of using QSB b/c it is
google and they have enough of my data as is. You can disable that
'feature' but still, i don't feel that crazy about it.

I really don't understand what's been going on, but it's clear we
should really either get the QS dev team to wake up, let people help
out or just move on to QSB.

I'm really upset that there hasn't been news in monthes.

[Etienne Samson]

Hi !

Update from me, as I had been the primary workforce of QS's branch
development ;-). My opinion is that I'm a little sad to see QS slowly
dying, especially since it has been one of the first application (that
I know of) to provide such a powerful integration with the system. I'm
still planning to do some work on QS, but as I now have a real work
ongoing, I can't really afford the time to some of my others (dare I
say "geeky") projects ;-).
What I would like to see (since this thread is so aptly named), is
some kind of discussion about QS's future, if there are people willing
to give some help in development (because this is what I tried to do,
but failed, for some reasons I'll try to explain thereafter), and try
to move on.

There have been several shortcoming with my developments : I didn't
have access to QS's own update mechanism. This means that although I
provided some builds from my work, very few people have found them,
and this meant people kept refiling bugs I had fixed in the branch. I
also had a few issues with Howard stating "stick with the last
official build" (that's not against you, but I could have understood
it as "you're doing this for nothing since nobody will use your
build", and I had a hard time with this ;-)).

I guess I also went overthrown with some of my changes (I tried to fix
some of the ugly stuff, like the wierd class hierarchy around
QSCommand (which seems it was added after, while providing the main
object/action/argument paradigm, which is the base of QS), tweaking
the ranking system (means it doesn't match as well as it does between
ß54 and ß55a*).

Now I'm wondering on what can be done, we could continue working on QS
ß54/55, or try to complete the trunk version and release QS
"v2" (since we could call the ß54 series "v1"), but this has some
pitfalls :

The plugin system in incompatible, this means that every plugin from
(what I'll call v1 from now) will need to be updated for v2. There are
numerous unimplemented stuff in Crucible, and stuff that needs to be
updated (no triggers, or at least need to be checked, since Alcor
wanted to provide that as a system-wide Preference Panel, allowing for
a trigger that could launch QS).

I'm not really against ditching v1 totally in favor of the new
architecture, because that means I can restart a development cycle (I
had been breaking people's triggers file while trying to fix
encapsulated triggers).

Opinions ?

Etienne

[Steven Noonan]

On Tue, Feb 10, 2009 at 3:08 AM, Etienne Samson <tien...@gmail.com> wrote:
>
> Hi !
>
> Update from me, as I had been the primary workforce of QS's branch
> development ;-). My opinion is that I'm a little sad to see QS slowly dying,
> especially since it has been one of the first application (that I know of)
> to provide such a powerful integration with the system. I'm still planning
> to do some work on QS, but as I now have a real work ongoing, I can't really
> afford the time to some of my others (dare I say "geeky") projects ;-).
> What I would like to see (since this thread is so aptly named), is some kind
> of discussion about QS's future, if there are people willing to give some
> help in development (because this is what I tried to do, but failed, for
> some reasons I'll try to explain thereafter), and try to move on.

I certainly don't want Quicksilver to die because of a lack of
maintenance, and I'm sure there are others that feel the same way. I
don't know much Cocoa yet though, so I wouldn't be the _ideal_ person
to contribute to the project.

I -really- don't mean to hijaack this thread, but I would need to get
answers about some of the problems I mentioned in the "Build problems
and other issues" thread before I could give many helpful suggestions
about the future of QS... Is the SVN code really so terribly broken as
I saw? Or is it just incomplete? The latter would make sense to me (as
I wasn't aware that the current SVN code was so radically different
from the ß54/55 series.

If v2 -is- as incomplete as it seems, perhaps the generic solution is
to have two dev teams. Have a few developers maintain ß54/55 until the
v2 code is fully usable. Once v2 is viable, start stating that ß54/55
are based on legacy code and will be phased out. After a while, simply
stop maintaining ß54/55 and work solely on v2. At this point, there
should be no reason not to switch to v2.

- Steven

[i.aten...@gmail.com]

In an ideal world, I think having two teams working on both would be
great. However, as it is, we're having trouble getting enough
developers for one, let alone two products. So, my 2p is that we need
to collectively decide on one, and stick to it.
Etienne, I think you hit it on the head with your comment about the
update mechanism: from my outsider view, I think the biggest problem
with working on the old branch is how much of quicksilver any would-be
developers simply don't have access to. Correct me if I'm wrong?
So from that point of view, version 2 seems like the way forward.
However, as noted, the problem with that is it's a long way from
complete...
I have no idea what it all looks like from behind the scenes though,
so what are the views of folks who have actually been working with the
code?

The important bit: Like many, I am also no Cocoa whizz, far from it :).
However, I am up for learning, especially for the future of
Quicksilver. I expect I can probably help out eg. porting across old
plug-in stuff if someone gives me a little direction.
It'd be nice to hear a few more people offer to help than simply
herald the death of such a crucial app. Come on folks!

[Steven Noonan]

I disagree. Just because Quicksilver development has stagnated does
not mean there is a shortage of developers. After all, I only noticed
recently that there hadn't been Quicksilver updates in a while. Now
that I know Quicksilver development is in jeopardy, I can ask my
friends, such as Alastair Lynn (CC'd: Alastair, mind pitching in?),
whether they'd be willing to help keep Quicksilver going.

> Etienne, I think you hit it on the head with your comment about the update
> mechanism: from my outsider view, I think the biggest problem with working
> on the old branch is how much of quicksilver any would-be developers simply
> don't have access to. Correct me if I'm wrong?

I concur.

> So from that point of view, version 2 seems like the way forward. However,
> as noted, the problem with that is it's a long way from complete...
> I have no idea what it all looks like from behind the scenes though, so what
> are the views of folks who have actually been working with the code?

I think version 2 is probably the way to go, but version 1 worked
alright (it had some niggling bugs, of course, but what doesn't?), it
just needs minor maintenance. It would be ideal to keep version 1
maintained until version 2 is stable enough (if what I saw was any
indicator, version 2 is in a basically worthless state).

> The important bit: Like many, I am also no Cocoa whizz, far from it :).
> However, I am up for learning, especially for the future of Quicksilver. I
> expect I can probably help out eg. porting across old plug-in stuff if
> someone gives me a little direction.
> It'd be nice to hear a few more people offer to help than simply herald the
> death of such a crucial app. Come on folks!
>

Same here. I'm mostly a game developer (and occasional kernel-level
coder), but I can spend some time to work on Quicksilver.

- Steven

[Howard Melman]

Sorry I don't have a lot of time this week. I did want to say, I in no
way wanted to discourage you or anyone from working on QS code.

I was merely commenting on my own perceived stability of versions for
(mostly new) users to make use of. And I recall saying several times
the newer versions fixed some things and broke others (like my Current
Application Proxy Hide mouse trigger). Also you had said you didn't
have a lot of time for QS so people having problems with the newer
version I thought would have fewer resources for help.

I'm another programmer with little cocoa experience and have wanted to
dive into the code. I appreciate all the cleanup you had done, that's
certainly a help for everyone. In a couple of weeks I may have more
time to dive in and will have to evaluate where best to put the time.
To me, the most annoying thing about QSB is that while I thought the
QS main trunk was the future of QS, it seems it really is QSB unless
some dev group forms to take over either of the QS code bases.

Howard

[Dorian]

I'm glad to see there is some traction discussion about the future of
this project. Here are some things i think we need to do to keep this
going (long and short goals).
I can't see any more development going into v1 then what has gone in
already. I do mostly frontend web design and use a CMS called Drupal.
One idea they use in there version releases is ditching the old code
and starting over with the key parts. I think the same should be
applied here. Just focus on development of v2 of QS. (which has
started already).

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.

Summer of Code should a great place to get some more talent apart of
the comunity. We really should look into that once it's annouced this
year.

Another thing is we need more information on the code base landing/
homepage about Quicksilver. Speaking of documentation, what is our
standing with the current Quicksilver documentation page on Alcher's
site? Alot of it is out of date now. Maybe we should look in starting
our own page but linked from Blacktree's page?

Finally, we do have an IRC chat room, but is mostly dead.
irc://irc.freenode.net/quicksilver I'll be there under ErifNeerg. I
really think that should help start talking more. (if you looking for
a client, I've been happy with Colloquy)

[Etienne Samson]

Thanks for the feedback here, folks ;-)

I'll cherry-pick stuff from your replies, and reply again.

Dorian said :

One idea they use in there version releases is ditching the old code
and starting over with the key parts. I think the same should be
applied here. Just focus on development of v2 of QS. (which has
started already).

Yes, this is what I had been planning to do, because trying to fix v1 (fix in the sense of fixing QS) means I'm likely to break people's existing installations. I agree we should be able to make some bugfix releases for the v1 branch (which is what I started to do, but then do dragged by the amount of stuff that looked wierd to me, and thus required a more consistent rework).

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.

For triggers, this is another kind of problem, but I guess I'll have to redive into the trunk code to remember what was the point...

Summer of Code should a great place to get some more talent apart of
the comunity. We really should look into that once it's annouced this
year.

We could do that, but frankly, the issue I have is that no one (even me) knows the full intricacies of the code base. And there is stuff in there that are badly in a need of rewrite (IMHO, all the view stuff).

Another thing is we need more information on the code base landing/
homepage about Quicksilver. Speaking of documentation, what is our
standing with the current Quicksilver documentation page on Alcher's
site? Alot of it is out of date now. Maybe we should look in starting
our own page but linked from Blacktree's page?

I think most of the docs out there still applies, but I haven't checked it thorougly...

Finally, we do have an IRC chat room, but is mostly dead.
irc://irc.freenode.net/quicksilver I'll be there under ErifNeerg. I
really think that should help start talking more. (if you looking for
a client, I've been happy with Colloquy)

I do agree having some dedicated chat place would be a great thing, the main problem is Earth's curvature ;-). I'm in France (GMT+1), so most of you won't be online when I will. I had this issue with Alcor too.

Howard said :

To me, the most annoying thing about QSB is that while I thought the  

QS main trunk was the future of QS, it seems it really is QSB unless  

some dev group forms to take over either of the QS code bases.

Let's not let this happen then ;-).

Now, I will make a few updates to both codebases so that everyone can build, starting from scratch. The last thing I was trying to do was consolidating the build system again, so I could easily integrate the slew of plugins Alcor gifted us with, and trying to prevent it from rebuilding everything as soon as I changed one file. But this has been fraught with hazards and was boring as hell ;-).

More on development later.

Etienne

[i.aten...@gmail.com]

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. ^_^

[Dorian]

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.

[Etienne Samson]

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, i.atent.d...@gmail.com 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.

[nontoppo]

On Feb 10, 11:08 am, Etienne Samson <tienn...@gmail.com> wrote:
> I'm not really against ditching v1 totally in favor of the new  
> architecture, because that means I can restart a development cycle (I  
> had been breaking people's triggers file while trying to fix  
> encapsulated triggers).
>
> Opinions ?

First off, thanks a huge bunch Etienne, your builds are significantly
better than the original when running Leopard IMO, and I really
appreciate your effort. I'm very happy to hear fighting talk on
keeping QS alive for a while longer. Though QSB is promising, it is
severely limited in functionality terms compared to QS, and I seem to
see that many of the power features will never make it to QSB. The
fact it doesn't even handle a third pane input means its UI will never
be as elegant as QS.

I don't think you should be trying to get V2 working. That is a
significant undertaking, unless you feel confident you can get a
working system with the resources you are able to afford. I'd love to
see Elements, Crucible and others working on an optimised new core,
but it doesn't seem like the most practical path. Fixing V1 some more
to make it robust under Leopard bit by bit seems like a better option
to me. You give the community a great present to have a tool we
already all use daily and make it better. Would be great if you could
add some of the V2 bits into V1 over time. But the problem with QS is
not that it needs new features, the problem many people have with QS
is that it is unstable for some, which you can have a greater impact
on fixing.

I'd love to see some more Cocoa programmers willing to help you out,
and as we've seaid many times before, I think we could get a paypal
money pot set up to pay developer bounties on bugfixes and feature
additions...

[Etienne Samson]

Le 12 févr. 09 à 23:36, nontoppo a écrit :

>
> On Feb 10, 11:08 am, Etienne Samson <tienn...@gmail.com> wrote:
>> I'm not really against ditching v1 totally in favor of the new
>> architecture, because that means I can restart a development cycle (I
>> had been breaking people's triggers file while trying to fix
>> encapsulated triggers).
>>
>> Opinions ?
>
> First off, thanks a huge bunch Etienne, your builds are significantly
> better than the original when running Leopard IMO, and I really
> appreciate your effort. I'm very happy to hear fighting talk on
> keeping QS alive for a while longer. Though QSB is promising, it is
> severely limited in functionality terms compared to QS, and I seem to
> see that many of the power features will never make it to QSB. The
> fact it doesn't even handle a third pane input means its UI will never
> be as elegant as QS.

Thanks ! Quick head up, I had a talk yesterday with Alcor, and
although he doesn't mind whatever we do with the QS code base, he told
me that my time would be better used on porting features to QSB than
trying to fix QS, which I do agree he's right stating this, since they
have a whole slew of developers working on the code, while I'm pretty
much alone here. Alcor also told me that he was planning to write a
"Porting plugins documentation", then he'll start converting QS
plugins to QSB.

Frankly, I'm unsure about completely selling my soul to Google, so I'm
not sure I'll ever switch from using QS (advantage from being a
developer, when it crashes, I fix it ;-)).

> I don't think you should be trying to get V2 working. That is a
> significant undertaking, unless you feel confident you can get a
> working system with the resources you are able to afford. I'd love to
> see Elements, Crucible and others working on an optimised new core,
> but it doesn't seem like the most practical path. Fixing V1 some more
> to make it robust under Leopard bit by bit seems like a better option
> to me. You give the community a great present to have a tool we
> already all use daily and make it better. Would be great if you could
> add some of the V2 bits into V1 over time. But the problem with QS is
> not that it needs new features, the problem many people have with QS
> is that it is unstable for some, which you can have a greater impact
> on fixing.

Frankly, there are only (IIRC) two fundamental changes in v2, this is
the new plugin architecture, and the fact that triggers are outsourced
to Catalyst. This means almost everything else is copied code from v1
(without the changes I made), so I'm almost restarting from scratch,
but with a much more robust plugin system. The problem I see with
improving v1 is that I cannot fix some of the fundamental issues in
the code :
- the fact that QS model doesn't handle serialization nicely, which
is shown by trying to make a trigger using an encapsulated command
- the fact that the class named QSCommand (which is used by the
trigger system) is a recent addition, and thus isn't used anywhere
else, where it could be used in the command interface and allow for an
arbitrary number of arguments, and some others I don't remember ;-).

This mean I could write a "Plugin porting guide" somewhere (this is
valid both for v1 and v2, since the slew of v1 plugins I got are in an
unknown state), and outsource this to those of you that have little
knowledge in development, so I can keep working on fixing bugs in QS
itself. I'll try to have a quickstart guide before the end of the month.

> I'd love to see some more Cocoa programmers willing to help you out,
> and as we've seaid many times before, I think we could get a paypal
> money pot set up to pay developer bounties on bugfixes and feature
> additions...

About this, I guess this could be a motivating idea ;-). The issue I
have with this is that I'm unsure how much time I'll lead QS
development, since my time is pretty scarce, and the fact that I'm
improving an app alone, while QSB gets support from a full-fledged
Google team...

Etienne

[nontoppo]

On Feb 13, 8:52 am, Etienne Samson <tienn...@gmail.com> wrote:
> Thanks ! Quick head up, I had a talk yesterday with Alcor, and  
> although he doesn't mind whatever we do with the QS code base, he told  
> me that my time would be better used on porting features to QSB than  
> trying to fix QS, which I do agree he's right stating this, since they  
> have a whole slew of developers working on the code, while I'm pretty  
> much alone here. Alcor also told me that he was planning to write a  
> "Porting plugins documentation", then he'll start converting QS  
> plugins to QSB.

Do you think you can get the core power features from QS *into* QSB?
If so, I'd rather see that happen as QSB will have more momentum. My
only issue with QSB is what Alcor via Google will and will not want
let into QSB. If they don't want triggers and more advanced plugins as
they deem it too complex, then QS should live. If you think you can
get that stuff in, then we should all just accept the sad death of QS
and the phoenix of QSB as a new paradigm.

> Frankly, I'm unsure about completely selling my soul to Google, so I'm  
> not sure I'll ever switch from using QS (advantage from being a  
> developer, when it crashes, I fix it ;-)).

But QSB is open-source, anyone can make custom builds stripping out
anything that may be compromising privacy - this is already done for
Chrome. I wouldn't worry about this.

If the best QS II will come from QSB, then work from that base and
benefit from help from others, otherwise if we can't get the features
which make QS the best interface on the planet into QSB, then...:

> This mean I could write a "Plugin porting guide" somewhere (this is  
> valid both for v1 and v2, since the slew of v1 plugins I got are in an  
> unknown state), and outsource this to those of you that have little  
> knowledge in development, so I can keep working on fixing bugs in QS  
> itself. I'll try to have a quickstart guide before the end of the month.

...it sounds as if working on Trunk is the way to go...

> > I'd love to see some more Cocoa programmers willing to help you out,
> > and as we've seaid many times before, I think we could get a paypal
> > money pot set up to pay developer bounties on bugfixes and feature
> > additions...
>
> About this, I guess this could be a motivating idea ;-). The issue I  
> have with this is that I'm unsure how much time I'll lead QS  
> development, since my time is pretty scarce, and the fact that I'm  
> improving an app alone, while QSB gets support from a full-fledged  
> Google team...

Yes, I just don't know what Alcor feels about a bounty system...

Etienne, thanks again for all your effort!!! :beer:

[iota]

How does Ankur and his builds fit into further QS development?
<http://lipidity.com/>

> Frankly, I'm unsure about completely selling my soul to Google,

I feel similarly negative about selling my soul to Google. Though the
momentum and manpower behind QSB is quite attractive.

> But QSB is open-source, anyone can make custom builds stripping out
> anything that may be compromising privacy - this is already done for
> Chrome. I wouldn't worry about this.
>
> If the best QS II will come from QSB, then work from that base and
> benefit from help from others, otherwise if we can't get the features
> which make QS the best interface on the planet into QSB, then...:

Sounds like a good idea worthy of more exploration. I haven't found
anything (launchbar, qsb, butler) as intuitive as QS's 3-pane bezel
interface nor have I found a trigger system like QS.

> > > I'd love to see some more Cocoa programmers willing to help you out,

I wish I had the time to learn and do :-(

> Etienne, thanks again for all your effort!!! :beer:

Yes! Thanks Etienne!

[Jon Stovell (a.k.a. Sesquipedalian)]

Until QSB 1) has a third pane, and 2) lets me create Applescript
actions, I'm not interested in it. Maybe one day they will let that
happen, but until then I remain interested in development of
Quicksilver.

[nontoppo]

On Feb 13, 6:02 pm, iota <maimaid...@gmail.com> wrote:
> How does Ankur and his builds fit into further QS development?
> <http://lipidity.com/>

It is an old build and the changes he had made were rolled into the
B5X branch that Etienne works on AFAIK...

[Rosso]

To me, QSB without trigger and 3rd pane is just another launcher .
Quicksilver should live as long as they keep it this way . I'm not a
developer , just to express my support.

[mason k]

On Feb 13, 3:52 am, Etienne Samson <tienn...@gmail.com> wrote:
> Le 12 févr. 09 à 23:36, nontoppo a écrit :

> Frankly, I'm unsure about completely selling my soul to Google, so I'm  
> not sure I'll ever switch from using QS (advantage from being a  
> developer, when it crashes, I fix it ;-)).

Google is a great company, but QSB ain't QS, and I don't think we'll
be able to make it so.

>
> Frankly, there are only (IIRC) two fundamental changes in v2, this is  
> the new plugin architecture, and the fact that triggers are outsourced  
> to Catalyst. This means almost everything else is copied code from v1  
> (without the changes I made), so I'm almost restarting from scratch,  
> but with a much more robust plugin system. The problem I see with  
> improving v1 is that I cannot fix some of the fundamental issues in  
> the code :
>   - the fact that QS model doesn't handle serialization nicely, which  
> is shown by trying to make a trigger using an encapsulated command
>   - the fact that the class named QSCommand (which is used by the  
> trigger system) is a recent addition, and thus isn't used anywhere  
> else, where it could be used in the command interface and allow for an  
> arbitrary number of arguments, and some others I don't remember ;-).
>
> This mean I could write a "Plugin porting guide" somewhere (this is  
> valid both for v1 and v2, since the slew of v1 plugins I got are in an  
> unknown state), and outsource this to those of you that have little  
> knowledge in development, so I can keep working on fixing bugs in QS  
> itself. I'll try to have a quickstart guide before the end of the month.

I'm a C & Ruby developer, but saving quicksilver is the kind of
project for which I'd be happy to learn a new language. I could start
with some plugins ports as soon as you have that guide available.

> About this, I guess this could be a motivating idea ;-). The issue I  
> have with this is that I'm unsure how much time I'll lead QS  
> development, since my time is pretty scarce, and the fact that I'm  
> improving an app alone, while QSB gets support from a full-fledged  
> Google team...
>
> Etienne

I'm willing & able to assist the development however I can.

[Jo_y]

i'm very glad to hear some rumors around my preferred and basic
interaction tool, Qs.
i do only applescript, at a medium-high level of interaction,
realizing any of my wishes and necessities which comes across my mind.
But developing an application isn't the same: applescript is only for
hobbists like me, and not for people without degrees in programming.
From my point of view you should have to focus only on a stable Qs
version, _without_ all the old plugins, (maybe later...) but with a
few of essential plugins, like:

-abracadabra
-mouse triggers
-clipboard/shelf
-automator/script
-command line tool
-web search module
-itunes/email modules
((-growl notifier))

-new applescript dictionary for Qs
((-configurable search mode, via catalog -Filter catalog))

with best wishes,
Jo

[pendolino]

i think that abracadabra should be left out until it is more stable.
we've had some issues with it and stopped using it.

[Chris Cairns]

and also everyone's list of essential plugins would differ. But i
like the idea of Jo of starting with less plugins and then
subsequently adding the remaining plugins ensuring that stability is
not lost.

[Jo_y]

On 21 Mar, 09:38, Chris Cairns <nochan...@gmail.com> wrote:
> and also everyone's  list of essential plugins would differ. But i  
> like the idea of Jo of starting with less plugins and then  
> subsequently adding the remaining plugins ensuring that stability is  
> not lost.

Hello Chris,
you are right to assert that everybody has his own favorite plugins.

But i think that abracadabra, how mousetriggers, the shelf and the
clipboard, nothing to forget the applescript support..is fondamental.
For the simple reason while you can realize everything with these
expanded actions. (i use all of these plugins everyday, and very very
often.)
I would say, they are to label as "general" and not as "specific"
plugins.

i'm ready to renounce to ANY other plugin of Qs. (the ones of my last
quote too)

[Jo_y]

On 21 Mar, 09:38, Chris Cairns <nochan...@gmail.com> wrote:

> and also everyone's  list of essential plugins would differ. But i  
> like the idea of Jo of starting with less plugins and then  
> subsequently adding the remaining plugins ensuring that stability is  
> not lost.

[Gavin]

Another vote for continuing quicksilver's development. It'd be awesome
if this gained some momentum.

I mean even the name "Quicksilver" just makes you want to keep using
it. Plus all the reputation it has built up over the past few years.
But "Quick Search Box"..? :/

[Etienne Samson]

Update !

I'm still working from time to time on this, but real-work schedules
are keeping me busy ;-). I'm currently investigating the code
revolving around "finding valid actions for a given object", because
I'm seeing some bugs in this area (eg, try creating a "Current
Selection" > "Find with..." trigger, I haven't been able to). Then
I'll release this, then I'll look at Sparkle and try to use this
instead of the current update system, then I'll release b57, and stop
adding new stuff to v1 (fixing bugs only that is).

Sorry, Jo_y Abracadabra is dead, I don't have the source for it, and
this kind of functionality was the primary reason we have a differing
trunk version (ability to use QS as a framework, not as an
application). Maybe it will come back, but I have no resources at the
moment for it, and since everything must be rebuilt from scratch, it
might be better to wait until I start working on v2 again.

Le 22 mars 09 à 17:23, Gavin a écrit :