-
Notifications
You must be signed in to change notification settings - Fork 757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scide: make tooltip text black on Linux #2762
Conversation
Hmm, this would indicate that the Q_WS_X11 branch is not used in a Linux compile, and in fact stackoverflow show various topics (but nothing very clear) that Q_WS_* should be changed to Q_OS_* when switching from Qt4 to Qt5. I think that makes sense with when that error turned up. See for example here: https://www.kdab.com/porting-from-qt-4-to-qt-5/ So rather than changing the Mac/Windows code to Linux code, it might be worth trying if Q_OS_LINUX does the job? If that turns out to be correct, some stuff Q_WS_X11 headed stuff might be worth inspecting too. Are the shortcut-key problems in linux fixed? |
Aha, hopefully we'll manage to kill several birds with one stone here. Unfortunately, the code depends on QGtkStyle, which seems to no longer exist in Qt 5. |
d91e7c9
to
44e7b8e
Compare
I've force pushed a commit that removes the dependency on QGtkStyle and just hardcodes the colors on Linux. |
Maybe wise: |
Hah, it's the only spot where QGtKStyle is used in the entire app. That looks like a worthy sacrifice until we get a Qt crack... But: UNIX includes MACOS. Is that intended (I checked, if I change the color in the Q_OS_UNIX branch, the color changes on the mac too)? |
44e7b8e
to
9e00881
Compare
OK, |
Really sorry for being nitpicking here, it would definitely be nice to get this out of the room. The only quick logic that seems safe here is UNIX but not (MACOS or netBSD). What is typically done actually is that things are defined for MACOS and Windows (together or separate) first, and then code for "the rest" (assuming that IOS is not an issue). I am not sure what LINUX covers (I used that in the beginning as a quick demonstrator, not as a final), and there are/used to be/could be quite a few unixes that are not covered by LINUX but could be covered by your "safe" code. HAHA, for checking if the colors are right, we do not need to test. We'd have to use a different color to verify (and I did on OSX) ;) Btw, I'd like to see a unittest that catches the wrong color 😄 |
9e00881
to
4384ef3
Compare
No worries about nitpicking. ✔️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Built with red on MacOS and Windows and got black ;) Thanks. A Qt-crack could maybe do something more nifty, but for our manpower I think this is an adequate fix and solves a tiny but annoying and much complained about problem ;)
It also can serve as model to fix some other problems at places using Q_WS_X11 which seem to have been overlooked when switching from Qt4 to Qt5. Those must all be going wrong, but they don't complain in the build as the alternative code compiles (but likely creates runtime bugs). I bet a bottle of wine that the keyboard problems on Linux have to do with this. ;)
I'll be so bold to approve this ;)
@patrickdupuis As I understand the issue, the problem is that the tooltip text color matches that of the window manager's text color, but the background color is fixed at pale yellow. Therefore, the text is only unreadable on systems where the native tooltips are light-on-dark. |
@patrickdupuis What did you expect? It's hard-coded to black now... |
Indeed it is. My system was never affected by this, and I can confirm that this change has no negative side effects for me. Let's merge and make our Ubuntu users happy. Favourite fix of 3.9 for sure ;) |
3.9 can come 😄 |
Waiting for @snappizz to add a comment about the #if as requested, and then I'll be happy to merge. |
@brianlheim done, thanks for the reminder |
Woah. Very thorough, thanks @snappizz 👍 |
#if defined(Q_OS_UNIX) && !defined(Q_OS_MAC) && !defined(__NetBSD__) | ||
QPalette p; | ||
p.setColor( QPalette::Window, QColor(255, 255, 220) ); | ||
p.setColor( QPalette::WindowText, Qt::black ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will break dark color schemes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Break them or have an unfavorable appearance in them? We are not able to implement configurability and theme support tooltips on linux. If you could provide it, that would be highly welcome! The current state is unacceptable for a lot of Linux users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If someone would step up and make the tooltip colors more attractive, I'd much appreciate it. I have no expertise in Qt and I was just fumbling around here to fix an issue that's been bugging users for almost a year and a half.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
read the colors for the color roles and fix them up. hardcoding colors should be avoided. futhermore, if it is related to gnome/gtk, netbsd would suffer the same issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that hardcoding colors is a bad idea, but I'm afraid to say I just can't dedicate the time to finding a better solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would need to compare the QColor::lightness() of both QPalette::ToolTipBase and QPalette::ToolTipText, and if they are unacceptably close, QColor::darker() the lighest one and QColor::lighter the darkest one by a significant factor?
@snappizz I think uncontroversial commits like this one should be merged back into the last stable branch (3.8 in this case), where users can get the version with less bugs. Maybe a policy to follow? |
I have no clue what I did here but it seems to fix #1704.