I already spoke about this bug in my previous post.
When setting a share ratio in the preferences dialog, that ratio is not saved.
(Say I want a ratio of "1,10", it will return to "0,00", the default value.)

I investigated it further and tried other values, suspecting some localization bug with decimal separators. So I tried integer values such as "2" or "1,00" and it worked : if I reopened the preferences dialog, my setting was still here.

But finally, I don't think it is a localization problem: I went to the KDE control panel, and chose an american "." instead of a french "," as a separator. Then I did my tests again. The bug was still there.

In conclusion : the share ratio field will accept only integer values although that is a float field, and that does not depend on the decimal separator character.

I'd very much like to say I can trigger this behavior but it simply works here. It worked before, it works with final 2.1 and it works with the latest SVN.
We need to find the cause of your problem...

To clear something: You set max share ratio in preferences, then you close settings window and return to KTorrent. Opening preferences dialog again does not show you max share ratio you just entered? Or is it not saved when you restart KTorrent?

The setting is reset when I close the preferences and open it again. And it is always reset to 0.00.

(If I managed to set 1.00 and then I set 1.10, it will be 0.00 again.)

I just checked ktorrentrc. In fact, ktorrent does store the right value in [downloads] maxRatio !!!
It is just displayed wrongly in the preferences box when I open it.
Maybe I should test whether it actually stops the uploading when it reaches the wanted ratio.

When I try to set it to 2.50 it will revert back to my original value, however when I choose 2,50, it stays that way.

This must be some locale issue.

Ivan, couldn't we just be really flexible and accept both point and comma ?

We are not doing locale formatting at all. We're using KDoubleNumInput which obviously uses locale settings to format the number internally.

BTW, how do you manage to enter both comma and point? Here I can only enter point (locale settings) and when I try to enter a comma I can't. As far as I can tell, this KDE class is using a validator to prevent users from typing the wrong decimal character.

Anyway, I changed KDoubleNumInput to KDoubleSpinBox maybe we'll get lucky
Try the latest SVN and see what happens.

Still reverts back when I use a dot.

Damn. I'm still confused you does it let you enter dot and a comma...
I've tried some things with localization but I simply can't trigger it.

Could you try adding the following line to pref.cpp createWidget()

Code: Select all

dp = new DownloadPref(parent);
   [b]dp->num_max_ratio->setAcceptLocalizedNumbers(FALSE);[/b]
   updateData();

Try with both combinations False/True (the docs are not very clear on what this function actually does), it doesn't make a difference here but seeing that I don't have the problem maybe it'll help you.

On my PC, it won't accept a comma when my KDE locale says the decimal separator is a point and vice versa.
The setting immediately reverts to the old value if I do wrong (no need to even close the prefs window).
The value stored in ktorrentrc uses a point.
However, if the number has figures after the point (i.e. it is not an integer), it won't be restored correctly when read by ktorrent.
(I did the test : this is not only the prefs window, but also the new torrents that do not have a max ratio.)

This works here. We use KDE code to read from the rc file, so this could be a bug in KDE which is fixed in my version (3.5.5).

Could be. I'm running KDE 3.5.6 and I don't have problems with display nor rc file... Though the last time you've reported I was running 3.5.5 and didn't have problems either