BookONO wants to be a Calibre alternative

[elcreative]

Originally Posted by poglad

"If you want to replace Calibre, then replace it, not use it to drive your own product. At this point in time, this software only seems to be a new front-end / user-interface for Calibre."

So you're saying that making an alternative front-end to Calibre's GUI should be dismissed as a valid project? He should either rewrite the back-end too, or give up?

Personally I think the back-end is where the real power lies, and when it comes to designing new approaches that get that power into the hands of more users, I'm all for it. Calibre's front-end is gross (IMO) and something less 1995-looking would be a pleasure to use.

Why??? As a matter of interest, why is it gross?? I find using it no problem and its front-end does something I regard as vital - it doesn't get in the way of the data I'm actually trying to use - too many programs are a triumph of style over function/content and actively get in the way of actually doing something... what great improvements would stop it (IYO) being gross?

Originally Posted by elcreative

Why??? As a matter of interest, why is it gross?? I find using it no problem and its front-end does something I regard as vital - it doesn't get in the way of the data I'm actually trying to use - too many programs are a triumph of style over function/content and actively get in the way of actually doing something... what great improvements would stop it (IYO) being gross?

Different people have different tastes in software. Some people want tonnes of features, or are willing to put up with tonnes of features to have the features that they want. Other people want software that has just the features that they need, without putting up with a lot of distractions.

Unfortunately, there doesn't appear to be much choice out there at present. You have calibre and ADE, then you have the vendor specific software. Vendor specific software only plays with the vendor's hardware, and only sometimes handles third-party books. That leaves ADE and calibre, which are the two extremes.

That being said, it would probably be straight-forward to offer a customized version of calibre. The option to simplify the interface is already built into the interface. It's just that the people who want that cleaner interface rarely have the patience to do it themselves.

[Bompa65]

Originally Posted by AlbertaCowboy

Not just big shoes to fill, but also socks, pants, shirt and hat!

I agree 100%.

If it ain't broke....don't fix it!

[Terisa de morgan]

Originally Posted by BWinmill

Different people have different tastes in software. Some people want tonnes of features, or are willing to put up with tonnes of features to have the features that they want. Other people want software that has just the features that they need, without putting up with a lot of distractions.

Unfortunately, there doesn't appear to be much choice out there at present. You have calibre and ADE, then you have the vendor specific software. Vendor specific software only plays with the vendor's hardware, and only sometimes handles third-party books. That leaves ADE and calibre, which are the two extremes.

That being said, it would probably be straight-forward to offer a customized version of calibre. The option to simplify the interface is already built into the interface. It's just that the people who want that cleaner interface rarely have the patience to do it themselves.

Patience or interest. What some people look like are missing here is not everybody is interested on playing with a program with a lot of options till get the two or three options they need but prefer other people to do it. It's not lack of patience but interest.

[Mivo]

I only use or need some of Calibre's basic features, but I nevertheless much prefer to use a program that is more powerful than what I presently need, because in time I may want to do things that I will then need the extra features for. I'm not bothered by a program having 10,000 features even if I only need 20 of them.

In case of Calibre the stuff I have currently no use for doesn't even get in the way, so I'm still unclear why people would want a more dumbed down software. (I do understand that it's about the GUI, though again, I think the basic features are all easily accessible and prominently offered.)

[Terisa de morgan]

If I recall right, they won't use calibre as is in the backend but for converting, so the file structure that the user has defined will be kept as is, with no changes. I'm sure I'm wrong but that's the idea I've got. And please, no comments about calibre needs this, calibre approach is wonderful, etc, etc. Everybody has opinions and I'm not giving an opinion but what I think they offered.

[citac]

Originally Posted by Sefiriot

Oh I'm not worried about the published ebooks in my library; those are fairly okay tags wise. It's the saved fanfics I have in Calibre that are nightmare inducing, and they make up most of my electronic reading material since most of my serious reading stuff are still in pbooks.

Really, the Archive of Our Own is awesome for downloading fics for offline reading when paired with calibre and the FFDL plugin: but their tagging system, or lack of one makes me want to shoot something when I see the jumble of tags in calibre courtesy of the downloaded metadata. I like the canonical tags on AO3 sourced fics, and there are freeform tags that are particularly useful. However downloading that data also entails downloading useless drivel in the tags too and it drives me crazy as well as slows tag browsing. How many times must I delete tags that go along the lines of "I was drunk gaiz!" and "OHMAHGERD I HAVE SO MANY FEEEELS"from my library?

If you EVER figure out a way to beat those tags into submission, I will worship at your feet!

[auspex]

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.

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.

[auspex]

Originally Posted by Terisa de morgan

Patience or interest. What some people look like are missing here is not everybody is interested on playing with a program with a lot of options till get the two or three options they need but prefer other people to do it. It's not lack of patience but interest.

It's both. I certainly have the interest — I've started three different calibre plugin projects, but I haven't had the patience to finish one (not that they ever are really finished )

[dalai]

Originally Posted by auspex

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.

I was referring to development effort since a previous post seemed to imply that C++ is also more work. With respect to execution speed, PyQt wraps C++/Qt so you wouldn't get any improvement in Calibre, at least where Qt is used.

Having said that, Python is indeed generally slower than C and C++ although there are things you can do about that. I also disagree with your statement regarding C and C++. You can write proper C++ that is as fast or faster than C (see the shootout for a couple of examples). Of course you can also abuse either to make any speed comparison between them meaningless.

In general, it is better to just go with what you are comfortable with - faster development, less errors. Using well-designed libraries like Qt instead of reinventing the wheel also helps. If it turns out that something is slow then you can do some local optimizations (e.g. replace some python code with C or change a container type).

[Katsunami]

Originally Posted by auspex

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.

First: You are probably not good enough in programming in assembler to best the compiler. The chance that you write better assembler than a current compiler is very slim.

Second: C++ is not slower than C. During compilation, almost all of the "sytactic sugar" that C++ provides is stripped out. Writing a program in C++ does not have a detrimental effect on speed, as long as you DON'T go and use some huge STL-objects that can do a lot of stuff and then compare it with a bare-bones implementation in C. For example, it's not really fair to compare a generic <List> with your own linked list implementation that only handles integers, and does only adding/removing entries.

Third: Why would rewriting Calibre in C or C++ gain nothing? I'm sure things such as the conversion process would become faster if rewritten in a compiled language.