Closed vallhund closed 8 years ago
:+1: But I think it should only apply on "Down Speed", "Up Speed", "Down Limit", "Up Limit".
:-1: I am opposed to this change.
Then make it as option, so user can change how it will be shown.
This is not an issue just suggestion.
I guess there can be three ways to look at this (via a setting): 1) Always hide zero values regardless of the torrent state 2) Only hide such values for paused torrents 3) Always show all values
I guess this will satisfy everyone.
I don't like this idea. Having yet another configurable option for the user is not good either. I don't consider the current state exceptionally bad to warrant a change or an additional setting. I am sorry. @birdie-github I am sorry that you spend time implementing this and I am rejecting it.
Having yet another configurable option for the user is not good either.
I think this is not a problem if it's in advanced options. Instead, I see a little performance problem because we have to check if the option is enabled for each cell in the transfer list.
Checking against 0 will take a few CPU cycles which is nothing, whereas rendering this data will tax the CPU much more.
So, exactly the opposite to your words is true.
So, exactly the opposite to your words is true.
I don't know how Qt does the things but I suppose that when you display an empty string there is some rendering... Anyway the discussion is pointless because is not going to be implemented.
I guess there's no rendering involved at all, but I cannot verify this theory since I'm not a programmer.
I'd be happy to implement this feature because without worthless zeros the UI looks a lot better, leaner and more importantly EASIER to read and comprehend.
Besides, world famous uTorrent nowadays has more than 50 advanced options and no one cries foul. I wonder why @sledgehammer999 and you think more options means any difficulties for the user. Most users never open advanced settings so they simply don't care.
Those, who open advanced settings, want to see more and have control over more things like this one. Besides, if we were to have a poll on this feature, I'm quite sure, the elimination of zeros would be a clear winner.
I have created a poll at phoronix.com: http://www.phoronix.com/forums/forum/software/general-linux-open-source/814903-qbittorrent-interface-survey-please-vote
I wonder why sledgehammer999 and you think more options means any difficulties for the user.
I would like to have all the features uTorrent has. The problem for me is not to have another option, is that I don't like how it looks and worsening code readability. I think qBittorrent is and advanced client, if you want a client which displays lees info try Transmission.
Besides, if we were to have a poll on this feature, I'm quite sure the elimination of zeros would be a clear winner.
I don't know if you are allowed to start a poll in the forum http://qbforums.shiki.hu/
I don't like how it looks and worsening code readability
I'm sorry I don't understand what you meant by saying that. You don't like the way the UI looks if this feature request is implemented?
if you want a client which displays lees info try Transmission.
I've never actually said anything like that.
As for code readability, I guess adding a simple function/macro/etc to check against zeros and return nothing in case of zero won't inflate the codebase much and won't cause any troubles in regard to the understanding of the source.
I really dislike how this feature request is being handled and please don't tell me to fork QBitTorrent and have this feature implemented in a fork. This won't work for far too many reasons.
You don't like the way the UI looks if this feature request is implemented?
Yes, but if it's optional and by default 0's are displayed I'm not opposed. Anyway I'm not going to continue this conversation because it's pointless. sledgehammer999 has the final word and his point is clear.
Sane people usually change their opinion/preferences when they are given enough information to have their mind changed so let's not dismiss this issue just yet.
So far no technical arguments have been given against the implementation of this feature.
Hiding zero values doesn't mean displaying less data.
In fact, displaying zero download speed for a finished torrent is not logical. Downloading at 0 kb/s and not downloading - two very different states.
'Infinite' speed limit for a torrent doesn't make sense too - the speed can be limited by global speed limit option, so it may be confusing.
The reason I registered on github is because of this issue. I switched to qbittorent from ut today and this is quite a drawback. The torrent list is much worse readable with all the zeroes and [unlimited signs] for ETA visible in the list. Please add the option to hide all the zeroes and unlimited signs.
The only way to move forward with this feature request is to write a patch and humbly hope that it's gonna be merged.
Hiding zero values doesn't mean displaying less data.
Not quite, the conversion does increase the string length from '0' one character, to '0 B/s' (five characters), Whereas bypassing the conversion to display a NULL or empty string removes the processing required to convert the speed parameter to "0 B/s" for display. So on a client running a large number of inactive tasks the reduced CPU usage could be significant. Currently I have 85 tasks loaded, with 73 - 75 of them inactive for most of the time and my average CPU use since making the change, is down 1% - 1.5%. Right at this moment qBittorrent CPU use is varying between 0.33% and 0.86% (2 x Dual Core Xeon processors )
I might have a change of heart here. What does the rest of @qbittorrent/qbittorrent-frequent-contributors think of this wishlist item? (assuming that @birdie-github still has his patch code around)
also positive feedback from dupe #3873 too.
I wouldn't mind having it as an option.
And in https://github.com/qbittorrent/qBittorrent/issues/3543#issuecomment-127264776 @ngosang seems to agree to be optional. So unless he has changed his mind @birdie-github can you open a PR?
I keep my opinion.
So it is yes, but making it configurable. (I expect the delegate code to look like a bunch of if tests)
For anyone looking to implement this: The option should be put in tools->options->behavior->transfer list
:+1: This would be great!
See PR: #4675.
I don't like this idea. Having yet another configurable option for the user is not good either. I don't consider the current state exceptionally bad to warrant a change or an additional setting. I am sorry. @birdie-github I am sorry that you spend time implementing this and I am rejecting it.
Why a configurable option for the user is not good? What is the point of having a control panel?
I really don't understand your judgement and others who oppose to this kind of features By this logic I think that in real life: We shouldn't build ramps for people in wheelchairs because we don't need them We shouldn't add a sound device to traffic lights for blind people because we don't need them In software: We shouldn't add accesibility tools for visually or hearing impaired people We shouldn't add translations and a configuration option for the language because they should know english, etc.
I think the important thing that we all should learn is that we are different, our DNA, our brains, our eyes. Maybe, your brain works like acomputer and it's easy for you to filter throught tens, hundreds of torrents, but for me and others, it seems that is not that easy and it would be nice to have an option to change that I've been using uTorrent 1.8.5 for many years there's no B(bytes), no 0(zeros) values which is great. Half a year ago I've upgraded to qbittorrent, but I'm still thinking if it's indeed an upgrade on this side...
Anyway, I'm glad that it's open source and maybe someone will fork it oneday and add these features for the rest of us there
@Danny3 Read through all posts in this thread then consider remove your post. The function is already implemented and it's just waiting to be merged (it's not rejected).
@Chocobo1 I came from #4675 where other people are asking why a feature like this is needed. Slegehammer in the past closed this #4137, somewhat related to this, the easiness of reading values. I think this will be closed too with no good reason, beside people's preferences and taste. And I don't know what the point of commenting after a PR has been closed. I'm just disappointed because in the real life we have adjustable seats, seatbelts, steering wheels, chairs, colors, etc. and we can't do the same thing in software where it's actually easier because people think either that "One size fits all" or their taste is better. I'm sorry if I upset someone and for bumping this. If my posts bothers you, I'll remove them.
@Danny3 to clear things. Yes, in the past I was against this. But after some time I changed my mind. @Chocobo1's PR will be reviewed and merged. And this will be closed as implemented.
Just compare: this is now![scr1](https://cloud.githubusercontent.com/assets/1698538/9025568/28796d46-3912-11e5-94c9-4553e8172320.png)
And this is how it could be![scr2](https://cloud.githubusercontent.com/assets/1698538/9025570/3f61c83c-3912-11e5-879c-b7c6f2654389.png)
Looks much neater and cleaner to me. Maybe an option ('omit zero values' or something) can be added to preferences.
The code in gui/transferlistdelegate.cpp allows this, as far as I see. (Not familiar with c++).