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) On Feb 10, 8:16 pm, Howard Melman <[email protected]> wrote: > 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 > > On Feb 10, 2009, at 6:08 AM, Etienne Samson 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. > > > 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
