Remove description box in graphics tabs and use custom tooltips instead #9153
Conversation
iwubcode
force-pushed
the
qt_custom_tooltip
branch
4 times, most recently
from
0f1b2c6
to
06c36b4
Compare
|
This is using modified Qt internal code as a base. It changes the arrow / box direction if there's not enough screen space for it to fit (try moving the window around to edges of the screen). More work would be needed to match some of the specifics of the mockup. EDIT: |
iwubcode
force-pushed
the
qt_custom_tooltip
branch
from
3981f96
to
83fe0eb
Compare
iwubcode
force-pushed
the
qt_custom_tooltip
branch
3 times, most recently
from
17afab0
to
e98e7a2
Compare
|
Updated to support most General/Enhancement tab options. Will wait on @MayImilae 's feedback before doing the rest of the tabs and cleanup. |
|
Just gave a try, and I'm neutral on this one. On the plus side, it'll allow getting rid of the description box, which made the Graphics config window too tall to fit on a 1080p screen at 125% scaling since the recent DPI fixes, but on the negative side:
With that said, isn't there any way to make Qt spawn "regular" tooltips, that follows the theming of the OS and that doesn't spawn new windows (like the tooltips that appear when hovering over a file/folder on Windows Explorer and on Finder)? That would address all of that points in a single shot... Edit: QWidget::setToolTip() seems to be suitable to produce OS themed tooltips... |
|
@mbc07 - these tooltips are completely custom code. I did this so as to reproduce the theming and the arrow that was presented in the mockup. "Qt" tooltips allow styling of the text and I believe you can set the background color but nothing more. The different style is intentional. I originally suggested normal tooltips but the consensus was they weren't attractive enough to be used for big blocks of text that the current description box allows. The arrow points to the bottom left corner of the control. I can move it but wasn't sure where would be best. I tried centering but that wasn't great either. Honestly, I am ok with other suggestions but my end goal is to remove the description box. All the tasks I've been doing could use some descriptions but I don't want to bring the description box over for each UI I implement. About the window issue. The tooltips produced were not their own window but when I introduced the fade-in logic, the whole widget wasn't fading, just the contents and background color. A black background for the tooltip appeared instead. To avoid this, looking online I used the flag 'FramelessWindowHint'. That fixed the animation but also inadvertently made it a window. I saw the window was losing focus but didn't realize it had actually become a window, so I thought it'd be ok. I guess I will take the animation out for now, until I can figure out a proper way to have my cake and eat it too. |
Regular tooltips will follow the OS theme, that's the whole point. If we go custom and pick a different style, how can we assure whatever style we pick will display nicely on all OSes we support? That becomes a mess very quickly when you take Linux in consideration, as there's a HUGE variety of distros, each one with their own visual style. By using regular tooltips they will follow the OS theme and that's guarantee that they will "fit", regardless of which OS Dolphin is running. Going completely custom just to have an arrow and different border seems counterintuitive. You can also use HTML-style formatting with the text of regular tooltips, which is probably enough to make it stand out more while retaining the OS theme, and it's probably less code to write too... |
|
@mbc07 - it's not that hard to make this tooltip follow an "OS" theme (my initial code had that) but again the mockup that was provided to me had custom colors. The idea is to have a high contrast color so it stands out. We might be able to request that from Qt. I haven't looked. I don't mind switching to the OS colors if that is what the consensus is but again, that wasn't what was suggested. I do think the arrow and rounded corners are a nice touch. I guess one could argue that we should save these sort of modern changes for a UI overhaul (which Dolphin desperately needs) but I see nothing wrong in slowly updating things. Hence why I decided to do this and also implemented #8823 as well.
This is custom but this is pretty typical to how users create "cool" visuals. In this particular case, a majority of this tooltip code was pulled from Qt themselves for one of their internal solutions.
I'm well aware of what they support. It just wasn't desired. I don't have a strong opinion of my own on this particular feature and I do appreciate the feedback. This is a build of a mockup, so opinions are definitely encouraged. I'm just trying to mention why things are the way they are. |
|
Fair enough. For me the custom style (at least the current design) feels very out of place, at least on Windows, and I would rather go with the regular tooltips using the OS theme instead. If the consensus ends going with fully customized tooltips, the window spawning and focus change problems should be definitely fixed, and I would rather rave those custom tooltips somehow inherit a suitable color scheme from the host OS than hardcoding a specific theme that there's no way to ensure it will display nicely on all OSes Dolphin can run on... Edit: QBallonTip might be another candidate, it seems to provide a style similar of the mockup out of the box. However it seems to be a private Qt API and I couldn't find any official documentation about it. Also don't know how it would behave outside of Windows, nor if it would display at all ¯\_(ツ)_/¯ |
|
@mbc07 - thanks for looking! |
iwubcode
force-pushed
the
qt_custom_tooltip
branch
from
e98e7a2
to
5d0aca3
Compare
|
@mbc07 - as far as I can tell, qt requires the use of a window in order to do transparent effects. Looks like a qt bug was opened at one point but then closed due to age... I was able to get rid of the focus loss but the hidden window remained. So I removed the fade-in logic for now, the tooltip is no longer a window. Please retest when you have time. |
|
So the whole point of this is that standard windows tooltips... suck. Like, they are the worst possible tooltips. White box on black text over white box on black text, with only a tiny shadow and a faint touch of blue to distinguish it. It's awful. Tooltips need to be attention grabbing so users know they exist at all, and they need to be very clear what it is pointing at and what its contents are so users can quickly understand what the new information applies to and what that information is so they can move on. The Windows standard tooltip fails on both fronts. The standard windows tooltip is not good enough to replace our description area, which is why it was created in the first place. But a better tooltip just might. As for it not fitting in? Well, that's totally fine with me. OS level tooltip support has languished for 15 years, we aren't going to have a lot of luck trying to fit in when fitting in means being terrible. So let's just not! Besides, a rounded rectangle with a triangle is extremely generic on account of its simplicity, so it won't clash with anything too severely. So, I said standard windows tooltip here because, well, windows HAS better tooltips! But no one uses them, go figure. None of them are as good as the mockup I presented though, and all of the unusual ones also haven't been updated since Windows Vista so... they look like Windows Vista. I suppose that's a good reason not to touch them for us right now. |
|
@iwubcode - gave another try. It's a bummer the fade effect got axed, but not having the constant flashing from the focus changes and the windows spawning is a huge improvement. It won't replace the fade effect but perhaps adding a delay of one second before showing the tooltip might somehow help? About the tooltip arrow, have you tried making it point to where the mouse cursor is located instead of always pointing to the left corner of the checkbox/dropdown lists? Or perhaps add a little bit of padding on the left so it always point to the middle of the checkbox when hovered (although I have no idea how that padding would behave in right-to-left languages)? It would mimick the behavior of regular tooltips a little bit better... @MayImilae - nearly black balloon tooltip with an arrow (current design, and hardcoded) on a mostly white window isn't any better, definitely looks out of place and worse than a regular tooltip TBH. Even the dated Windows Vista/7 style found in some Win32 apps looks better than that, and unlikely the current approach (and my main issue with it), they will react to OS theme changes. MSI Afterburner is a perfect example of that*, the tooltip always point to where the mouse cursor is and it properly reacts to OS theme changes. It's also very comparable to Dolphin since Afterburner also has a tabbed config window with various checkboxes/dropdown lists and big descriptions on each one. On this PR, however, If I enable dark mode or turn on high contrast mode, the custom tooltip will retain the same hardcoded style and the border and arrow will get essentially invisible as result, looking way worse. That wouldn't happen when using the regular tooltips nor with the standard balloon tooltips because they would inherit the OS theme by design, regardless if you're using Windows, macOS or one of the thousands of Linux distros available, which is where that hardcoded approach has the most potential for issues. TL;DR, unless there's a way to ensure that same "inherit theme from OS" functionality on the proposed custom tooltips instead of a hardcoded style, I strongly think regular or balloon tooltips should be used instead (although I'm not sure if the latter is available on other OSes). Going with a custom solution that (currently) looks and behaves worse than the standard solution available across all OSes just for the sake of "regular tooltips sucks" seems very counterintuitive. It should at least be on the same level of functionality and the current approach isn't, TBH. *@iwubcode mentioned this PR was based on QBallonTip, which seems able to produce this kind of tooltips on Windows (and that's what MSI Afterburner uses), so let's hope it can be extended to other OSes |
|
Hmm, we have a bit of a language issue here, so I'll try to clarify. By better, I'm specifically referring to functionality. The standard windows tooltip that dolphin has been using functions horrifically as a tooltip. It just doesn't do the job well at all. This one, however, is far FARA superior at doing the job a tooltip is meant to perform - letting users know about auxillary info and allowing them to quickly consume it. How it looks is a separate matter to that, and we need to keep the apart as we discuss it. It's totally fine if you don't like how it looks, I made the mockup to demonstrate as many function tooltip techniques as possible, after all! When talking about tooltips, it's very hard to talk about them if the only thing anyone has ever seen is the garbage windows standard ones. So yea, you may not like how this looks, and that's ok! We can talk about the aesthetics. But the point of this is that functionality improvement, and as we talk about this, we need to be sure to keep the aesthetic wants and functional separate clearly defined. Speaking of functionality, here is all of the functionality that is in the original mockup. I outlined it in IRC but it hasn't been spoken here yet, so, I'll just outline the techniques it is demonstrating. https://i.imgur.com/cAeAO7X.png
I never thought that we'd have ALL of these in a tooltip, and yea, most of these aren't in this PR. That's fine! ...though a couple of them I miss, I'll be making another comment later. But yea, we could use some of the other techniques to counteract the loss of the high contrast theme, if everyone really hates it. For example, the fade out in particular would allow for white box with black text on white box with black text to work, because then it is white box with black text on white box with light grey text! |
|
It still has a hardcoded style instead of inheriting the OS theme and reacting to changes made to it, that's what I meant when I said it's not on "the same level of functionality" and the entire point I'm arguing since the beginning. That single point alone can cause various readability issues because it's simply not possible to hardcode a theme or color scheme that will magically fit in all OSes we support and in all themes they might or might not have (again, Linux and its thousands of distros). Regular tooltips and even the current description boxes that are going to be replaced by this PR doesn't have this problem since they'll always have have a consistent and "readable" visual regardless of the OS or theme being used, because they inherit the OS theme and will react to changes made to it, by design. If this can't be achieved on the custom solution this PR is proposing, then it's not worth the trouble IMO, it simply won't matter how much better our custom tooltip implementation is if they have the potential of being unreadable depending of the combination of OS and theme our end-users might be using. |
|
I honestly had no problem with the description box, infact I found it to be a great idea that I included in some of my own apps because I liked it in Dolphin. I find the tooltips in general to be distracting and blocking the window/text behind it. I generally do not support removal of the description box, but I wouldn't mind it if this is an option one can choose to switch between. However if the tooltip or some later variation of it would be made to be as good as it can in preventing getting-in-the-way and popping up at wrong times, then I might change my mind, but if the vertical size of the config dialogs is really that of a problem I'm not sure yet.
On what OS/Distro/Theme is that statement based upon anyway? Who or what is behind the term "modern"? I bet it's about the (IMO ugly) Google's Material design no? It is not fair for some specific trend that comes and goes to seize the context of a common english language term, and we are helping it if we do not recognize this mistake. At each milestone of such propositions, let's pause and ask what we have is really art and design, is it really original and unique to a specific project like Dolphin, or it's just about submitting to the styles that tech giants have been heavily forcing upon us. Everwhere I look around FOSS, there's usually this peer-pressure and some sort of IMO made up need to follow and switch closer to the popular trends, just for the sake of being part of that trend almost, styles and liknessess of the biggest actors who are behind promoting and persuading us why we should all use their kind of GUIs and why theirs is the best, and most importantly, why there is no need for anything else to coexist. I believe many such GUI redesigns are influenced by the tech giants remotely/passively, by their users, who have been heavily influenced, including from early age, to their styles by the use of their smartphones and other devices that are completely unrelated to a project the user is trying to project* their ideas onto. *(different context of the term "project") So I would like that such proposers are fully informed about this key aspect of conscious and subconscious bias and that they have to put some more effort into their propositions to be more fair to the project it self when desiging a new GUI for a project that never had any relation to any of sources of these external influences. The external influences should have a lesser weight in decisions and ability to drive the development and design process. That said, I am by no means defending the old and existing designs, anything could still improve or it could change, some things are never obsolete or worse or better, some things are more equal than they seem, and in the end it's just down to subjective taste. What I'm warning about is that this "personal taste" can be manipulated with, unknowingly. It also happens that these tech giants and the world of advertising are masters at this. In the end the existing themes and styles that most desktop application had are also influences, external ones too, yes we users didn't really build them ourselfs at the births of various operating systems, I don't deny that ofcourse. The new solution usually has a high mountain to climb, not only it has to persuade why it's better, how it's better, why it's the only way to go, it needs user's trust so they get trained and used with it and only a long way later when the user got used to it, only then can the user evaluate whether it was worth it. Was the transition fast enough or slow? Was it annoying and hard? Did it pay off? Was the new solution really good enough over the old one on day one? How long did it take to be perfected and polished? New solutions that replace old ones simply need more time, even when they are completed they have to linger and coexist, this gives the users vital real-time ability to compare and analyze how either one feels for them, and this is also the crucial beta-testing stage that discovers previously undetected issues with the either old or the new solution.
I agree with that, IMO if an existing solution +95% works and is tried and tested over time, then something replacing it should be quite a bit better to justify, it even goes into philosophical debate, it has to be good enough to eliminate any feeling of loss from existing users who are quite attached to the existing solution. If a new solution is the same or even slightly worse it usually becomes a popularity contest and taste, which makes things unfair. I'm not totally against this idea if the community fairly determines that vertical space would be a big issue warranting removal among other things, because I've seen rounded "?" icons appearing at the end of option or statement labels, even with Microsoft's GUIs (IIRC) to click on which shows the tooltip and that feels a lot better, it means only a conscious and intended manual action from the user triggers a tooltip. Except ... the process of determining what are the existing problems with the description box and whether these problems are heavy enough to first warrant changes to it, which then proceeds into research and prototyping if those changes work out, and if they don't, only then the research and prototyping for a replacement should occur, all this before a replacement is proposed. Optimally in a proper development team, but ofcourse since this whole FOSS ecosystem is all free-for-all unless specifically managed and depends on whether project has such rules or not, everyone just brings in their ideas day-one, which is another subject and I'm not arguing about that now. |
@mbc07 - to address your concerns, the plan is to have two preset themes for the tooltip: dark and light. The dark theme will be applied when the window color the users are using is determined "light" and the light theme will be applied when the window color the users are using is determined "dark". We have to do something in code since there isn't a way in Qt to request a "contrast" color, at least not as far as I know. I'm still looking into it. But rest assured, I don't intend to have dark theme users have this dark tooltip and I'd like to get something ideally that mimics the style the user is using.
Thanks for your comments. I will look into these suggestions!
@altimumdelta - thanks for your comments! My feeling is that no other application presents its "help" information in this way. We don't necessarily need to conform like you say but I think there's a reason that other apps behave differently. I'd honestly prefer much of this information outside of Dolphin in a wiki or some other resource but if it needs to be in app (which others on the team expressed) then I'd like to not have it take up valuable screen real estate.
I do agree that many UI changes are done when the users are perfectly happy with what was there. Whether this is influenced by other trends, I can't always say. But as developers and designers, we want to get as close to the best solution possible. So we are always iterating on our work. Many times users don't know they needed or wanted something until it is implemented.
I made the modern comment as I was referring to the rounded corners, soft shadows, etc suggested by the design but I feel this could extend out to Dolphin's UI design as a whole. As I said, I think it needs a refresh. Dolphin is still using its WxWidgets base and hasn't really improved on it since adopting Qt. We have space issues like #8785. There are klunky parts of the UI like the game-specific settings or for me personally hotkeys. A number of users would like to modify settings via their controller and the only workaround at the moment is to use IMGUI to build a secondary UI. See: #7930 and #8010 . And then there is the description box which works well for the graphics configuration but is hard to extend to other systems due to its size and always-on nature. It's things users (myself included) are used to but we could fix these things at the very least. We may not need a complete overhaul but it would allow us to rethink these features and how users are interacting with them. And we might be able to pickup newer design philosophies or take the software in a different direction visually (think of PPSSPP).
I suggested this but the thought was there would be so many "?" icons, it might be distracting. I don't necessarily have a problem with making the tooltip be displayed on demand. Again, my only goal of this PR to get rid of the description box so we can leverage a "help" system across our entire UI |
iwubcode
force-pushed
the
qt_custom_tooltip
branch
2 times, most recently
from
bb1e5a3
to
dccf98d
Compare
|
Updated with light/dark theme logic. Tweaked the arrow point location on all controls. |
|
Still not a fan of having dark tooltips on a light theme and vice-versa, but the dark/light detection works and properly switches the tooltip color scheme when necessary. A future improvement would be retrieving dark/light color values from the OS or the currently applied Qt theme instead of hardcoding two sets of different colors for the dark/light tooltip variants, but regardless of that the current approach pretty much addresses my concerns with readability. The tooltip arrows, however, still behave oddly. If you just open the Graphics config window, they'll point to the middle-ish of checkboxes/radio buttons and somewhere between the left border and the center of drop-down lists (like on the screenshots from the OP) and that looks fine. However, it starts falling apart the moment you start messing with the window:
I wanted to test a right-to-left language to see how it would behave with the repositioned checkboxes, but just changing Dolphin's language doesn't seem enough to trigger that, as the checkboxes remained at the same place. Might give a try later by changing the OS settings to a right-to-left language instead, but I kinda can't do that at the moment... |
|
@mbc07 - thanks again for testing!
Hmm strange, I didn't change the text size. Are you sure it was bigger? MayImilae's mockup was bigger but I never implemented that. Looking at your before and after I think the size is the same? EDIT: I did test the text size change locally an hour ago, just wasn't sure how big to make it. Maybe I'll push that up tomorrow |
|
Hmm, they do look the same. Maybe I confused May's mockup as an actual, implemented version of this PR? Don't know. Anyway, this PR now LGTM, at least there's nothing else I feel discussing about with the actual implementation... |
|
Gave this a try on my desktop. No problems with mixed scaling (200% or 150%, the text was and the tooltip were the correct size) and the text was nice and sharp! Sadly though, the tooltip itself is not HIDPI at all and is bad aliased. At 200%, it's pretty jarring (see below). Plus, to echo everyone else, the corners are rarely correctly round. And I know, Qt problems, I don't know how much you can fix. but just pointing them out. I'm just glad we don't have mixed DPI problems.
|
|
Idea: Could you try if you can clamp the tooltips to be placed inside the borders of the dialog behind it (parent), and see how that looks overall, perhaps it may help with the sizing of those cases where it looks off (like super wide) due to a lot of text and such. |
|
While I think we can all admit things aren't completely perfect, after using it for a while this morning I'm more than happy enough with the performance to switch over to this. Our GUI is simply too tall in spots and is a pain in the ass to use on my Linux Laptop that isn't fully 1080p, so I think this is a good first step toward fixing that problem. The tooltips keep my eyes in one place instead of constantly having to look down toward the bottom of the page every time I hover over something. I think the rest of the GUI will have to be ported over at some point, but for now just doing the Graphics Tabs will be a nice start. |
|
Yeah, I think this is a great improvement. I agree with everything JMC47 says. Hopefully we can sort out the corner, aliasing and hidpi issues in due time. As for macOS, it's unfortunate that we can't seem to fix the crashes and have to just use the OS tooltip, but I agree with MayImilae that we can't let that stall progress. Definitely would like to see this used for all settings eventually, but the graphics settings is a good start seeing as we already have descriptions there. There's some settings in the NetPlay dialog that I think would really benefit from this as well. |
|
However I wouldn't rush to conclusions just yet, secondly, if the reasoning behind it is space that doesn't look well on a "monitor that isn't fully 1080p", isn't what is taking place here that it's a change that is designed to fix a problem on low-end device that isn't even up to the mainstream standards for gaming if we care about those, while again not taking into account that on a proper device, according to my knowledge, wasn't a problem at all? So is it about technicalities or subjectivities, or personal experience, because if one's monitor size is one of the deciding factors, I could just forget all the discussion and just say well I have a 1440p screen that has enough space and so I don't need any changes, that just seems low effort kind of a reasoning IMO that I try to avoid. If this must be merged, I'd hope that it gets a few better reasons than "my screen isn't fully 1080p ... in 2020", sorry. |
|
Unfortunately sub-1080p displays are still extremely common for things like laptops, or sometimes HiDPI reduces their effective size and creates the same problem. But yes, this is not the only reason. As JMC47 said, not having to move your eyes up and down so much is a great improvement. Many other apps are utilizing tooltips of this variety, and they seem to be received very well in terms of UX, so I think this is a good direction to go in. I for one much prefer them over the box at the bottom. There's less wasted space, you can see the description directly adjacent to the option, and we could even fit larger descriptions if necessary rather than being limited by the fixed size description box (this might be especially helpful for localizations which bulk up the text a lot). |
|
Hmm, allright, I wonder if these laptops are even powerful enough to get that top Dolphin experience, but I'm not familiar. As long as the behavior of these tooltips is fine tuned really good, to not be in the way, I think it'll work for me just great too in the end. |
|
For what it's worth, I do use that laptop for debugging Linux issues sometimes, so having the GUI work on it would be rather nice. As it is, I can use it yes, but it's unwieldy and for users who don't know what the setting mean, it can make things very hard to use. |
iwubcode
force-pushed
the
qt_custom_tooltip
branch
from
3af7287
to
0dc3061
Compare
Source/Core/DolphinQt/Config/ToolTipControls/ToolTipRadioButton.h
Outdated
Show resolved
Hide resolved
… It gives the ability to show a tooltip with an arrow!
iwubcode
force-pushed
the
qt_custom_tooltip
branch
from
0dc3061
to
cc837a5
Compare
|
For future reference - to disable high contrast tooltips, go to Dolphin.ini, and under [Interface] set "UseHighContrastTooltips" to False. |
Instead of a bulky description box for graphics descriptions, we now display a custom tooltip.
Based on @MayImilae 's mockup: https://i.imgur.com/cAeAO7X.png
Could easily be used for other (non graphics) settings later.
Examples of how it looks on each color theme below.
Light theme (windows default):
Dark theme (qt theme "Skyline Nightfall"):
or if you prefer, you can use the low contrast version (enabled via option, off by default):
Light theme (windows default):
Dark theme (qt theme "Skyline Nightfall"):