Le 12 févr. 09 à 23:36, nontoppo a écrit :
On Feb 10, 11:08 am, Etienne Samson <[email protected]> wrote:
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 ?
First off, thanks a huge bunch Etienne, your builds are significantly
better than the original when running Leopard IMO, and I really
appreciate your effort. I'm very happy to hear fighting talk on
keeping QS alive for a while longer. Though QSB is promising, it is
severely limited in functionality terms compared to QS, and I seem to
see that many of the power features will never make it to QSB. The
fact it doesn't even handle a third pane input means its UI will never
be as elegant as QS.
Thanks ! Quick head up, I had a talk yesterday with Alcor, and
although he doesn't mind whatever we do with the QS code base, he told
me that my time would be better used on porting features to QSB than
trying to fix QS, which I do agree he's right stating this, since they
have a whole slew of developers working on the code, while I'm pretty
much alone here. Alcor also told me that he was planning to write a
"Porting plugins documentation", then he'll start converting QS
plugins to QSB.
Frankly, I'm unsure about completely selling my soul to Google, so I'm
not sure I'll ever switch from using QS (advantage from being a
developer, when it crashes, I fix it ;-)).
I don't think you should be trying to get V2 working. That is a
significant undertaking, unless you feel confident you can get a
working system with the resources you are able to afford. I'd love to
see Elements, Crucible and others working on an optimised new core,
but it doesn't seem like the most practical path. Fixing V1 some more
to make it robust under Leopard bit by bit seems like a better option
to me. You give the community a great present to have a tool we
already all use daily and make it better. Would be great if you could
add some of the V2 bits into V1 over time. But the problem with QS is
not that it needs new features, the problem many people have with QS
is that it is unstable for some, which you can have a greater impact
on fixing.
Frankly, there are only (IIRC) two fundamental changes in v2, this is
the new plugin architecture, and the fact that triggers are outsourced
to Catalyst. This means almost everything else is copied code from v1
(without the changes I made), so I'm almost restarting from scratch,
but with a much more robust plugin system. The problem I see with
improving v1 is that I cannot fix some of the fundamental issues in
the code :
- the fact that QS model doesn't handle serialization nicely, which
is shown by trying to make a trigger using an encapsulated command
- the fact that the class named QSCommand (which is used by the
trigger system) is a recent addition, and thus isn't used anywhere
else, where it could be used in the command interface and allow for an
arbitrary number of arguments, and some others I don't remember ;-).
This mean I could write a "Plugin porting guide" somewhere (this is
valid both for v1 and v2, since the slew of v1 plugins I got are in an
unknown state), and outsource this to those of you that have little
knowledge in development, so I can keep working on fixing bugs in QS
itself. I'll try to have a quickstart guide before the end of the month.
I'd love to see some more Cocoa programmers willing to help you out,
and as we've seaid many times before, I think we could get a paypal
money pot set up to pay developer bounties on bugfixes and feature
additions...
About this, I guess this could be a motivating idea ;-). The issue I
have with this is that I'm unsure how much time I'll lead QS
development, since my time is pretty scarce, and the fact that I'm
improving an app alone, while QSB gets support from a full-fledged
Google team...
Etienne
