On 10 Feb 2009, at 15:53, Steven Noonan wrote:
On Tue, Feb 10, 2009 at 3:08 AM, Etienne Samson <[email protected]>
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.
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
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
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!
