Quote:
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.
Quote:
|
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.