Quote:
Originally Posted by dalai
They are both using Qt though and in my experience there is no significant overhead using C++/Qt over PyQt.
|
Vice versa, but you're right. Anybody who flat out states that if you want a program to run as fast as possible you use C++, (a) has never programmed in assembler and (b) doesn't understand C++. If I wanted to trim milli-seconds, I'd use C, not C++, but replacing every bit of Python in calibre with C++ would save you almost nothing.
Quote:
Originally Posted by dalai
Anyway I don't understand all the negativity. BookONO is in early alpha and people are already dooming it to failure instead of encouraging the developers. Calibre is great and all but it is not beyond improvement - otherwise you wouldn't be upgrading it every so often. Not to mention that it is virtually impossible to satisfy every user 100%. Any alternative that comes out is a net positive in my view.
|
Otherwise I wouldn't be upgrading it almost weekly
I agree, calibre can stand improvement, but I'd guess that the greatest part of the negativity is because BookONO is taking a great open-source project and building a closed-source project on top of it. That's likely to get a lot of calibre contributor's backs up. And it's doomed to failure because…BookONO is taking a great open-source project and building a closed-source project on top of it. Calibre is as great as it is because (a) it has one extremely dedicated principle developer and (b) it has dozens of dedicated contributors. Projects need both, and the only people who can do that in closed-source are companies who can put whole teams to work on the project.