On Tue, Feb 10, 2009 at 3:40 PM, <[email protected]> wrote: > 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.
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
