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
