Version: (using KDE KDE 3.2.2)
Installed from: Debian testing/unstable Packages
Received through the Debian BTS (#251466).
Some msgid seem to cause "Process output" to take a long
time. Screenshot in
This particular case takes about 60 seconds for the progress
bar to complete.
I can not see anything useful that is done during this 60 seconds. It
seems to me that every time the "Process output" takes so long that I
can seen the progress bar, it does nothing. If I go back to the same
msgid it takes again about the same time, so kbabel is not even saving
the results, if any, that it so laboriously generates.
This is annoying since I wait while "Process output" creeps along, it
does seem to take a lot of resources since kbabel is very sluggish if
I try to write during the processing.
Could this be fixed? If not, perhaps an option to turn this thing off?
Or at least please make it show what useful purpose this "Process
(end of Debian bug report)
FWIW, I tried to diagnose this problem myself -- I got as far as KDBSearchEngine::startSearchNow() but I ran out of steam, mainly because the code was quite hard to read. This was largely because the indentation in the latter half of KDBSearchEngine.cpp seems almost random, which makes it difficult to get any sense of the overall flow of the code. Might be worth cleaning up at some stage.
Anyway - forwarding this bug report on to the KBabel people. The user didn't send in a PO-file or any other attachments, but I assume the problem arises when KDBSearchEngine::searchWords() returns no good keys and we have to process the whole database.
The code for new KDBSearchEngine (cleaner faster etc...) is on my HD since
september 2003 but I really have no time to finish & commit it, sorry.
THe processing output can be skipped selecting in the option dialog of db
search engine the third search mode (return good keys) or by limiting the
number of "good keys" to < 100 (last tab of the options dialog)
> THe processing output can be skipped selecting in the option dialog of db
> search engine the third search mode (return good keys) or by limiting the
> number of "good keys" to < 100 (last tab of the options dialog)
Thanks, will pass this on to the original bug submitter.
Using the latest kbabel from cvs, with "number of good keys" limited to 50 and "return good keys" selected, I still get the same behaviour. For some strings it hangs at "processing output" for minutes, keeping the CPU at 100%. If I press ESC or CTRL-S, after 10-20 seconds it jumps to the next string (sometimes to the previous).
My translation db is about 8-9000 entries.