Now this is some exciting news. I have been thinking about a rewrite in ruby too for some time.
I think ruby is a very clever choice because there are many Ruby opensource Developers on the Mac platform, so this would increase the amount of potential devs enormously. Second, you could design it to be crossplatform from the very beginning, which would increase the amount of devs again. This would mean to use osx specific libraries and datatypes only where absolutely necessary (eg activerecord instead of coredata ). If this is where you are heading, I'd be happy to help out. I think I'm quite skilled at designing and writing ruby (web)apps but not so much in objc or it's ruby bindings. Marcel Am 18.01.2011 um 23:46 schrieb Etienne Samso. <[email protected]>: > Le 18 janv. 2011 à 14:35, Rob McBroom a écrit : > >> On Jan 18, 2011, at 1:03 AM, Patrick wrote: >> >>> A rewrite is definitely the best plan, but that's not to say people haven't >>> thought about it already. >> >> Alcor started [a rewrite][1] and there's [another][2] underway. (Not sure if >> that second one is supposed to be talked about, but I figure I'm allowed if >> it's on GitHub.) > > Oh, you're allowed, I was showing my current plans to Ankur Oberoi after a > little "development" meeting we had ;-). But this is only preliminary stuff, > and it's using MacRuby which I just discovered and which really speeds up > Cocoa development. But my mind isn't made up on the MacRuby thing. > >> Just pointing those out for the benefit of anyone who's thinking about >> starting from scratch. >> >> I know the people having this discussion are pretty familiar with >> Quicksilver, but still I have to wonder if you really understand the glut of >> features Alcor was able to implement. It almost seems impossible that one >> person did all this. Are you sure a rewrite is realistic? > > I'm pretty sure a rewrite is realistic (:-P), it's just that personally I'm > time-crunched on other things atm. Right now I have (another) ObjC only > rewrite with a little part of the basic model stuff "working" (as in, you can > create objects (files, urls, text, collections) from a *program*) and tested. > It just lacks some more model classes (actions, commands), and... also > everything else :-S. > > I just want to point out that I would prefer the main development repository > to be https://github.com/quicksilver/quicksilver. It's just that my > notification queue is getting messy, and the one there actually has Alcor's > rewrite removed (since IMHO they don't belong to the same repository, having > their history separated). > > Now, I do have some plans on continuing my rewrite, it's just that I'm at a > loss at how to handle things like the Catalog in a CoreData world w.r.t > performance/ease-of-use in such a flexible object world. And the catalog is > the thing that's used for providing search results to the interface. I have a > test project ongoing to check that performance with CoreData is acceptable > enough to warrant its use, but I'm not done yet. > The plugin system (https://github.com/tiennou/qs-elements, extracted from > Alcor's rewrite because I guess it's general-purpose enough to warrant such a > move) is mostly working, though it lacks updating and some kind of > repository-like function like current QS has, which are also on my rewrite > queue but lower that the Catalog thing, since that's the thing preventing my > rewrite from advancing. > > IMHO, the main problem with the current code is that it predates stuff like > KVO/KVC, Core Animation, Core Data, which means a lot of code (even whole > classes on the Core Animation POV) could be removed, which adds up to more > files and more bugs :-(. > > If you're interested in helping development, I'm planning to publish a basic > rewrite with some kind of Catalog thing and documentation (BTW, thanks Jordan > Kay for the link to AppleDoc, I guess I'll go with that) as soon as I feel > it's a good start, so maybe during February. > > Cheers to all, and thanks again for the support ;-). > -- > Etienne Samson > [email protected] >
