Skip to content
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

Merged
merged 2 commits into from
Mar 6, 2017

Conversation

nhthn
Copy link
Contributor

@nhthn nhthn commented Mar 2, 2017

I have no clue what I did here but it seems to fix #1704.

@nhthn nhthn added this to the 3.9 milestone Mar 2, 2017
@bagong
Copy link
Contributor

bagong commented Mar 2, 2017

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?

@nhthn
Copy link
Contributor Author

nhthn commented Mar 3, 2017

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.

@nhthn nhthn added Work In Progress (WIP) - don't merge yet comp: Qt GUI sclang Qt components -- for IDE tickets, use "env: SCIDE" instead labels Mar 3, 2017
@nhthn nhthn force-pushed the topic/linux-tooltip branch from d91e7c9 to 44e7b8e Compare March 3, 2017 00:53
@nhthn
Copy link
Contributor Author

nhthn commented Mar 3, 2017

I've force pushed a commit that removes the dependency on QGtkStyle and just hardcodes the colors on Linux.

@bagong
Copy link
Contributor

bagong commented Mar 3, 2017

Maybe wise:
https://bugzilla.redhat.com/show_bug.cgi?id=1386404
So what do we have here? Window-manager vs. OS, Qt-company shaking of competitors, distribution policy, Linux flavor differences, supporting styles and configurability vs hardcoding... Just a little preprocessor macro, and composers become engineers. We were hoping Qt would make things easier ;)
Nevertheless this looks really promising. I think it will be the favorite fix in 3.9!

@bagong
Copy link
Contributor

bagong commented Mar 3, 2017

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)?

@nhthn nhthn force-pushed the topic/linux-tooltip branch from 44e7b8e to 9e00881 Compare March 4, 2017 02:36
@nhthn
Copy link
Contributor Author

nhthn commented Mar 4, 2017

OK, Q_OS_LINUX it is. This should be ready to merge after we've confirmed that the colors are correct on Linux, Mac, and Windows.

@bagong
Copy link
Contributor

bagong commented Mar 4, 2017

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 😄

@nhthn nhthn force-pushed the topic/linux-tooltip branch from 9e00881 to 4384ef3 Compare March 4, 2017 18:12
@nhthn
Copy link
Contributor Author

nhthn commented Mar 4, 2017

No worries about nitpicking. ✔️

@bagong bagong requested review from bagong and removed request for bagong March 4, 2017 19:38
Copy link
Contributor

@bagong bagong left a 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
Copy link
Contributor

I tested on my system and i get black. Should i be looking at text colour elsewhere?
tooltips-colour

@nhthn
Copy link
Contributor Author

nhthn commented Mar 5, 2017

@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.

@bagong
Copy link
Contributor

bagong commented Mar 5, 2017

@patrickdupuis What did you expect? It's hard-coded to black now...

@patrickdupuis
Copy link
Contributor

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 ;)

@bagong
Copy link
Contributor

bagong commented Mar 6, 2017

3.9 can come 😄

@mossheim
Copy link
Contributor

mossheim commented Mar 6, 2017

Waiting for @snappizz to add a comment about the #if as requested, and then I'll be happy to merge.

@nhthn
Copy link
Contributor Author

nhthn commented Mar 6, 2017

@brianlheim done, thanks for the reminder

@mossheim
Copy link
Contributor

mossheim commented Mar 6, 2017

Woah. Very thorough, thanks @snappizz 👍

@mossheim mossheim merged commit 9157fd7 into supercollider:master Mar 6, 2017
#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 );
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how it looks in Ubuntu Studio (xfce) with your dark scheme:
tooltip

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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?

@nhthn nhthn deleted the topic/linux-tooltip branch March 7, 2017 05:00
@smoge
Copy link
Contributor

smoge commented Mar 31, 2017

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp: Qt GUI sclang Qt components -- for IDE tickets, use "env: SCIDE" instead env: SCIDE
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants