Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#5278 closed Bug (fixed)

Something strange with the color of progress bars

Reported by: taem Owned by: jordan
Priority: Normal Milestone: 2.80
Component: Qt Client Version: 2.76
Severity: Normal Keywords:
Cc:

Description

Hi,

There is something strange with the colors in Qt client. Steps to reproduce:

  1. start client
  2. color of progress bars will be blue (first screenshot)
  3. scroll to the bottom of the torrent list
  4. color of progress bars will be green (2nd screenshot)

Is it intentional?

Thanks.

Attachments (4)

tr-qt-color1.png (86.4 KB) - added by taem 8 years ago.
tr-qt-color2.png (85.7 KB) - added by taem 8 years ago.
010-progress-bar.diff (4.6 KB) - added by rb07 8 years ago.
Addition of a 3rd color.
new-color.png (33.5 KB) - added by rb07 8 years ago.
Sample of new color.

Download all attachments as: .zip

Change History (22)

Changed 8 years ago by taem

Changed 8 years ago by taem

comment:1 Changed 8 years ago by taem

Forgot to add: svn r13981, Qt 4.8.2, debian sid.

comment:2 follow-up: Changed 8 years ago by jordan

I'm not sure what's causing it and am not able to repeat it, but looking at the torrent-delegate.cc code I see there's something that's not right with how the progressbar's palette is being used...

comment:3 Changed 8 years ago by taem

If you show me right direction, I can take a look at it :)

comment:4 Changed 8 years ago by jordan

Thanks!

qt/torrent-delegate.cc's TorrentDelegate::DrawTorrent()

Last edited 8 years ago by jordan (previous) (diff)

comment:5 in reply to: ↑ 2 Changed 8 years ago by rb07

Replying to jordan:

I'm not sure what's causing it and am not able to repeat it, but looking at the torrent-delegate.cc code I see there's something that's not right with how the progressbar's palette is being used...

Those are my changes, perhaps you don't understand them, but "not right"? I don't think so.

The objective of those changes is to have the same look as the Web client, a blue progress bar for downloading, a green one afterwards. Ticket #4281.

The default progress bar color depends on the desktop settings, in most cases this means a blue (over white) bar. Since some desktop styles use the background color, while others use the base color, I changed both... is that what looks "not right"?

Last edited 8 years ago by rb07 (previous) (diff)

comment:6 Changed 8 years ago by jordan

To be more specific, on my desktop the progressbars are always the same color, regardless of seeding or downloading. They follow the desktop preference, which is reasonable but inconsistent with #4389.

Anyway there was no offense meant, so please don't take any.

Last edited 8 years ago by jordan (previous) (diff)

comment:7 Changed 8 years ago by rb07

Jordan, did you test with HEAD or released 2.76?

It might just be a bug in the back-ports that went on 2.76, because it was working before (on Linux), and still works for me (which never used 2.76 as released).

comment:8 Changed 8 years ago by jordan

rb07, it's that way for me in both released 2.76 and in trunk. It's definitely not a new regression.

comment:9 Changed 8 years ago by rb07

Not "new", but it was working in some Linux environments (there's even a screenshot in the ticket, and I've seen others).

My guess is that something changed in the desktop since we know nothing changed in Transmission.

One possibility is what I mentioned about modifying QtCurve's default, perhaps its the same case for other (all?) Linux desktops. Maybe this will ring a bell, what I change in QtCurve is:

-    opts->progressGrooveColor=ECOLOR_DARK;
+    opts->progressGrooveColor=ECOLOR_BACKGROUND;

As I mentioned, some styles use the background color for the bar, some use the base color, and there is that default used by QtCurve: dark (I'm not sure what is the equivalent in Qt terms http://qt-project.org/doc/qt-5.0/qtgui/qpalette.html#ColorRole-enum -- Background is obsolete in Qt5, I'll have to test QPalette::Window to see if it works on Qt4.8, or get rid of it and use the default if QPalette::Dark is the one used by the default style).

comment:10 follow-up: Changed 8 years ago by taem

I have bisected the code and found that this issue introduced in r13244. And I found that issue isn't reproducible when there are no active torrents.

comment:11 in reply to: ↑ 10 ; follow-ups: Changed 8 years ago by rb07

Replying to taem:

And I found that issue isn't reproducible when there are no active torrents.

You mean the opposite, right?

Your screenshots show all torrents paused (and you said you just started the application), in that case the blue color is normal (the code is using the desktop's default, which usually is blue/white -- foreground/background colors).

That explains what you are seeing:

The code (my code) only tests 2 torrent states: downloading, and seeding. It uses those states to set the progress bar colors. There's no explicit control for other states. For other states I see consistent operation: blue for finished, green for paused, and just about anything else (there is an odd effect which I assume comes from QtCurve, when the mouse pointer hovers over the torrent, after some delay the color flips).

To get a more consistent operation I could get rid of the second if, just test for one state and use the blue/gray colors, and for everything else green/light_green.

All this doesn't explain what Jordan reported... my guess is that he is using Qt3, while I'm using Qt4, or his desktop is really intrusive (native styles in Windows and Mac OSX don't let you change colors according to Qt's documentation).

Side note: Loking at updating the code, I tested QPalette::Window and it does work the same as QPalette::Background with Qt4; on the other hand QPalette::Dark doesn't affect the background color when QtCurve is configured to use ECOLOR_DARK.

comment:12 in reply to: ↑ 11 Changed 8 years ago by taem

Replying to rb07:

Replying to taem:

And I found that issue isn't reproducible when there are no active torrents.

You mean the opposite, right?

I mean that if there is at least one active torrent (downloading/seeding) issue is reproducible. And if all torrents are paused, issue isn't reproducible. Sorry, my English is not very well :)

comment:13 in reply to: ↑ 11 Changed 8 years ago by jordan

Replying to rb07:

To get a more consistent operation I could get rid of the second if, just test for one state and use the blue/gray colors, and for everything else green/light_green.

This would work. I'd also be open to a third set of colors, if you want to distinguish non-downloading / non-seeding torrents as the Mac and Web clients do. Either way is fine.

Wrt using Qt 4 vs. Qt 5 calls, is there any

All this doesn't explain what Jordan reported... my guess is that he is using Qt3, while I'm using Qt4, or his desktop is really intrusive (native styles in Windows and Mac OSX don't let you change colors according to Qt's documentation).

I'm running 4:4.8.4+dfsg-0ubuntu4 here.

The behavior I'm seeing is due to my desktop settings: Qt here is configured to use the GTK+ rendering engine, which apparently disregards the progressbar colors set in torrent-delegate.cc.

Side note: Loking at updating the code, I tested QPalette::Window and it does work the same as QPalette::Background with Qt4; on the other hand QPalette::Dark doesn't affect the background color when QtCurve is configured to use ECOLOR_DARK.

Sounds like an #ifdef is in order.

I don't know how quickly the Linux world will be jumping to Qt 5, but we should be ready for it when it happens. And, of course, trqtw doesn't need to wait for the Linux world...

Last edited 8 years ago by jordan (previous) (diff)

comment:14 Changed 8 years ago by rb07

I'd also be open to a third set of colors

I agree, a different color for finished/paused/whatever sounds better.

Wrt using Qt 4 vs. Qt 5 calls, is there any

any? As I said, Qt5 made the color role QPalette::Background deprecated, that's the only change needed w.r.t. progress bars.

Qt here is configured to use the GTK+ rendering engine, which apparently disregards the progressbar colors

That explains it, in general some Qt styles do their own changes with gradients, so they have to disregard the style set by the programmer, or even the color (using one defined for a different role).

Sounds like an #ifdef is in order.

No, we can just use the newer option, works on both versions.

In general for Qt5 the code will need some #ifdef, you can see it in my code (look for #if QT_VERSION ..., and #if defined(USING_QT5) which I defined in qtr.pro for the case when the version is not yet known; qtr.pro also has a conditional change for using Qt5). One other change I made with no condition testing is getting rid of all the QString::fromAscii, I either deleted them (I like compact code), or used ::fromLatin1 which is the Qt5 recommended way (and works on both Qt versions).

Changed 8 years ago by rb07

Addition of a 3rd color.

Changed 8 years ago by rb07

Sample of new color.

comment:15 Changed 8 years ago by rb07

About the sample: the first paused torrent has 0%, so it shows the (darker) background, the 2nd has 100% and its showing the silver color.

This new pair of colors follows the opposite of the others, instead of light background, here a darker background is used... just an idea, giving more weight to what is missing (for non downloading/seeding torrents).

comment:16 Changed 8 years ago by jordan

  • Milestone changed from None Set to 2.80
  • Status changed from new to assigned

r14019: (qt) #5278 'Something strange with the color of progress bars' -- patch by rb07

comment:17 Changed 8 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

Works for me, at least when I change desktop themes. :)

comment:18 Changed 8 years ago by taem

Cool. Works for me too.

Note: See TracTickets for help on using tickets.