My first impressions using Calibre

[bluexp]

Hi everybody!
After searching for a while and examining different applications for managing my ebooks, I found Calibre.There are some positive and negative points about it and I wanted to submit some of negative points as new ticket but I was not sure whether that is a good place for that. I hope my mentioned experiments and suggestions help Calibre to improve faster.
Calibre is most feature rich application I've ever found. The best part is that it is free and cross-platform.
But honestly say,it has worst gui among the others.It uses large buttons which waste a lot of screen space(even when set to small icon).The cover browser is really amazing but it overlaps tag browser and makes it unusable.
There is a row under top large buttons (with a red heart at right) which is totally useless I think.
The procedure of getting book info form server works really excellent.I am really happy with getting book info from isbndb server. But fetched covers are a little small. Perhaps a better server for this task like amazon would be better.
There is a strange thing I found while using Calibre. There are 4 runing task with name "calibre-parallel" and another one with name "calibre". these tasks totally use something around 135MB of ram which I think it is really much (I have book label which uses only 30MB of ram). and I don't know why there is so much task for one running application.
Finally I would be more happy if there was possibility of adding book to database without moving them to library folder. I categorized my book in different folders according to their subjects and I want to have them that way without any duplication.This is what prevent me from adding my collection to this app(Please add an option for that if it's possible).
After all, I think this application has a long way to gain user attraction mostly because of its GUI (Bool Label is a sample of ideal user friendly intreface).

I am currently using both windows and linux and this app is the only choice I have for managing books on both of them, so I want to thank the author of this application for providing such application for free.

[itimpi]

Originally Posted by bluexp

There is a row under top large buttons (with a red heart at right) which is totally useless I think.

By default it only has the main Calibre Library icon. However when you plug in your device additional icons appear for the devices internal memory and any plugin cards. You then select the one you currently want to operate on.

There is a strange thing I found while using Calibre. There are 4 runing task with name "calibre-parallel" and another one with name "calibre". these tasks totally use something around 135MB of ram which I think it is really much (I have book label which uses only 30MB of ram). and I don't know why there is so much task for one running application.

The Calibre task is the one that controls the GUI. The other one are sub-tasks to run things in background threads. The number of the calibre-parallel tasks started depends on the number of processors/cores in your machine. Part of the reason for this approach is that Calibre is written in python and having the tasks already running avoids the large startup delays python tends to introduce. It also probably explains why Calibre uses a lot of RAM - but that is cheap and plentiful on modern machines.

Finally I would be more happy if there was possibility of adding book to database without moving them to library folder.

There have been many discussiosn about this. At the moment Calibre treats its own library as a "Black Box" into which anything it is working on is copied, and this will not change without some fundamental re-writing. Therefore it certainly will not change in the near future.

[user_none]

Originally Posted by bluexp

There is a row under top large buttons (with a red heart at right) which is totally useless I think.

Plug in a supported reader and you will understand. Also, the GUI tweaks branch has this hidden when a reader is not plugged in. I can't say when GUI tweaks will be merged into a release.

Originally Posted by bluexp

I am really happy with getting book info from isbndb server. But fetched covers are a little small. Perhaps a better server for this task like amazon would be better.

Amazon does not provide an API for this and last I checked they have restrictions on the use of all images from their site. There is an experimental scrapper for Amazon but it doesn't look like it will be included any time soon.

Originally Posted by bluexp

these tasks totally use something around 135MB of ram which I think it is really much (I have book label which uses only 30MB of ram).

A native application written in a compiled language can use less memory than an application written in a dynamic language that runs in a virtual machine. Calibre is written in python which tends to produce applications that use more resources it is very easy to program and makes mulit-platform development easier.

A really good example I can give is Azureus and utorrent. utorrent would often add features at a slower pace and isn't multi-platform. But it uses less resources due to using a compiled language and not using cross platform tools.

calibre could use less memory but that would take more time and energy. Time and energy that can be put to fixing bugs and adding features. Right now the approach is, if necessary rewrite in C but only if there is a good reason to.

Originally Posted by bluexp

After all, I think this application has a long way to gain user attraction mostly because of its GUI

I agree. The GUI is slowly being improved. A lot of improvements are in the GUI tweaks branch I mentioned earlier. The major issue is neither Kovid or I like GUI work very much. I also don't use the GUI either so its short coming aren't very apparent to me. The best thing you can do to help is open tickets about what doesn't work for you. I won't guarantee that your suggestions will be implemented but at least it gives some bearing as to what people want to see and don't like.

[bluexp]

Thank you for your replies.
There are some good cross-platform GUI toolkits like Qt and wxWidgets which can help in case you want to make a native compiled app.An example of a good native compiled cross platform application is LMMS that uses Qt4.

Anyways I will try to add tickets for GUI improvments which I hope can help. But I think before releasing GUI tweaks it is useless.so I hope to see it soon.

[user_none]

Originally Posted by bluexp

Thank you for your replies.
There are some good cross-platform GUI toolkits like Qt and wxWidgets which can help in case you want to make a native compiled app.An example of a good native compiled cross platform application is LMMS that uses Qt4.

calibre uses Qt4.

[bluexp]

I thought it uses pyQt4 to access Qt4 libraries!
Therefor It seems to be easy to get rid of python in this application and build it completely based on Qt4 c++,isn't it?

[gwynevans]

No idea, but even if true, while the runtime of C++ might be faster than Python, the development time is a lot slower than Python and there's a fair bit going on behind the UI.

Also bear in mind that the question isn't 'Can this run faster?' but 'Does it run fast enough for most users?' (or even 'Does it run fast enough for Kovid? :-))

[itimpi]

There is also the fact that those who are really obsessed with speed can avoid using the GUI at all and do everything via the command line interface.

[user_none]

Originally Posted by bluexp

I thought it uses pyQt4 to access Qt4 libraries!
Therefor It seems to be easy to get rid of python in this application and build it completely based on Qt4 c++,isn't it?

That is correct and it wouldn't be "hard" to convert the entire GUI to C++. The issue is that the GUI is only one part of the overall application. All of the rest is written in Python and does not use Qt. rewriting those parts would be a horrendous task and while calling C/C++ code from Python is easy going the other way is not. Making a C++ worthless because it would be able to do anything. Also, as gwynevans said, the development time for C++ is a lot slower than Python.

Originally Posted by itimpi

There is also the fact that those who are really obsessed with speed can avoid using the GUI at all and do everything via the command line interface.

The command line is still Python and is still slower than if it was written in C++. It is faster than the GUI because it doesn't have to take the time to start and stop tasks (i.e. waiting for queued job message and pushing it into a parallel process). The actual per item conversions for instance will take the same amount of time to run.

Even though it is written in Python and could be faster the majority of the intensive parts are written in C. For instance PalmDoc de/compression, zlib de/compression, PDF to html conversion, PDF output rendering to name a few components. Basically if it really needs to be faster it's written in C, otherwise if it could be faster it is left in Python because the benefit does not out weigh the work it would take. Even the C parts could be faster if they were written in Assembly but that would be an utter waste of time. Does it run fast enough is the metric.