Delete "What's This" inline help functionality
Open, WishlistPublic

Description

QML apps don't support the feature at all.

3rd-party apps don't support the feature at all.

QWidgets-based KDE apps only intermittently implement the feature, mostly defeating the purpose; arguably it's only useful when implemented for close to 100% of the UI elements. When you click on the titlebar's question mark button to invoke it and find that many, most, or all of the UI elements you click on have no text, it's just frustrating and makes you wonder why so buggy a feature is still present.

I'd like to propose that we deprecate WhatsThis functionality, think about removing it from apps that implement it, and remove the WhatsThis titlebar button from the set of available Window Decoration buttons.

To replace the feature (in the few apps that implement it), we can improve our software's tooltip text and explicit documentation in the docbook.

ngraham created this task.Nov 4 2018, 4:38 PM
ngraham triaged this task as Wishlist priority.
ngraham updated the task description. (Show Details)Nov 4 2018, 4:41 PM

It won't be available in Qt 6

Citation?
The other phab doesn't say that.

ngraham added a subscriber: broulik.EditedNov 4 2018, 4:43 PM

Perhaps I'm misremembering (or misinterpreting), but I recall hearing that from @broulik.

No. It says the but that means dialogs have this on by default will be fixed in Qt6.

I don't think there's anything to solve here.

Ah, ok, my bad then.

I think there is something to solve here. Even if the button correctly appears only when some "What's This" help text is available, it's still not useful if only like 10% of the user interface supports it. In this case, it's an exercise in frustration as you hover over things and get the error cursor for nearly everything. Like I said, this feature only has value if it's implemented nearly universally. Having only 10%, 20%, or even 30% of the UI support it is useless and frustrating.

ngraham updated the task description. (Show Details)Nov 4 2018, 4:48 PM

AFAIK the context help is a KDE/Qt proprietary extension to EWMH. The property is called _NET_WM_CONTEXT_HELP, but if one searches the EWMH for it, it's not found. The feature got added in 64acd7375d6cb65611b8c225143d15bc41dc5343 by Matthias and mentions that it works together with the Qt snapshot of the next day.

I don't think that any non-Plasma application should rely on it as it's not cross desktop. Also I don't think many users know about it. I would not be surprised if KWin's KCM's are the most heavy users of this functionality given that Matthias added them (and yes most of our KCMs are that old).

I don't think we should just remove the button, but instead look for all usages in Plasma and migrate them to something more appropriate. Once all are gone I would say we remove the complete feature as nobody else supports it anyway. And we should update Qt doc (e.g. https://doc.qt.io/qt-5/qwhatsthis.html ) to make it clear that it's not available on all platforms.

Windows also has the "what's this" feature. I would favor setting the Qt::AA_DisableWindowContextHelpButton in plasma-integration and evaluate where it makes sense to explicit set it. Then we only really show the button if there actually is any help available.

KSysguard, for instance, makes extensive use of it. I have also seen it in various KCMs and KDE PIM applications. There may also be places (e.g file properties dialog and file dialog) where whats this texts are set but it is relied upon the fact that dialogs always get this button.

Perhaps we could also add a component to Kirigami (or even upstream one to QtQuick) as there is currently no support for that in QML.

Are there any Windows users who have actually used it in the last 15 years? :p

I think there is a threshold that must be crossed before the feature is useful. If close to 100% of the window's controls have "What's this" text, it's useful, because you can actually explore the app that way. But if only 50% do, then it's frustrating since there are big gaps in what's explained. You feel uneasy, rather than informed. When only 10% is covered, it's worthless. So I don't think the threshold of "show the button when there is even one control with 'what's new' text" is adequate. It's just user interface noise if the window hasn't fully committed to using it.

Given that we would need to add support to QML and Kirigami and Wayland, and it's not very widely used even in QWidgets land... should we even bother?

I don't think we should just remove the button, but instead look for all usages in Plasma and migrate them to something more appropriate. Once all are gone I would say we remove the complete feature as nobody else supports it anyway. And we should update Qt doc (e.g. https://doc.qt.io/qt-5/qwhatsthis.html ) to make it clear that it's not available on all platforms.

+1, I fully support this.

rjvbb added a subscriber: rjvbb.Nov 4 2018, 9:45 PM

I actually like the feature as a way to provide more complete (and better formatted?) contextual help for UI aspects that could use it, without obliging the user to open the handbook. AFAIK you have to find the relevant paragraph or section in there yourself, so it's less than ideal in terms of optimising productivity. Handbooks *are* important ("RTFM"...) but I think the whole KDE help centre feature could use a good overhaul too.

I'm a bit surprised to see claims that the what's this feature doesn't work everywhere. I've seen it work under MS Windows, it works on Mac, on my Linux/X11 workstation and I just confirmed that it works with Qt's "wayland" QPA (and their qwindow-compositor example app) too. What cannot be expected to work cross-platform is adding a "what's this" button in the window titlebar, but there must be other ways to activate the feature that do work everywhere (like the Shift-F1 shortcut).

I'm less surprised that the feature isn't available in QtQuick* ... there's a reason those frameworks have "quick" in their name.

It might be a good idea not to add a "what's this" button to window titlebars even if the platform supports them. I don't agree however with the idea to make it impossible to use "what's this" at all beyond providing (strong) guidelines on how the feature is to be deployed.

In T9986#166357, @rjvbb wrote:

I'm a bit surprised to see claims that the what's this feature doesn't work everywhere. I've seen it work under MS Windows, it works on Mac, on my Linux/X11 workstation and I just confirmed that it works with Qt's "wayland" QPA (and their qwindow-compositor example app) too.

Replace X11 with KWin. It only works with KWin and thus the feature is not cross-desktop although it is cross platform. Given that cross-desktop applications need to think about whether this is a good way to present help.

On Wayland this feature is not available - a Qt internal demo compositor doesn't count. We would need a specification for it and implement it in toolkits and compositors. Personally I think the feature is too little used as to invest the time into it. Getting a cross desktop specification is something I consider as impossible as gtk will say: just use csd. Doing a Qt/KWin protocol is possible but given the large success of this on X11 I'm not interested.

rjvbb added a comment.Nov 5 2018, 10:00 AM

Exactly what is the feature we're talking about?! I highly doubt that Qt will NOT show the popup window with the what'sthis text when you request it via

1a Help/What's This
or
1b the keyboard shortcut associated with that QAction (Shift-F1 by default)
2 Click on a widget that actually has the information set.
3 Watch the info appear.

After all this is (most likely) just a tooltip triggered in a different way and why would that not work everywhere? Quite frankly, if that doesn't work in a fancy Wayland compositor (I'm guessing we're talking about KWin) while it does work in a simple demonstrator, well, maybe the fancy one is a wee bit too much form-over-function?

So I have to assume that the non-cross-desktop feature is the titlebar button, and I reiterate my opinion that this is just one way to inform the user that some widgets can offer context help and to provide a handle to access that information. A very straightforward way to achieve basically the same thing would be to add a tooltip to widgets with what's this info saying something like "Hit Shift-F1 and click this control to see what it does" (no need even to move the mouse back and forth to the toolbar button). Outline this approach (one that works in modal dialogs too) in the HIG and let application devs decide whether or not they want to adhere to the new guidelines or not...

I really like how certain applications like KSysGuard provide additional contextual usage information via what's this popups and it'd be really stupid to disallow this just because it cannot be accessed the same way everywhere.
Just as stupid as removing fullscreen support just because only the Mac has a window titlebar button to toggle fullscreen mode (in addition to the usual maximise-this-window button) - after all, no application appears to use that feature beyond providing the menu action, right?

In T9986#166387, @rjvbb wrote:

Exactly what is the feature we're talking about?! I highly doubt that Qt will NOT show the popup window with the what'sthis text when you request it via

The button in the window decoration

GB_2 added a subscriber: GB_2.Apr 15 2019, 8:36 PM

Windows also has the "what's this" feature.

And by "has" you meant 'Supported for legacy applications only and axed from their HIG and UWP toolkit many years ago', right? Windows moved to an in-line display for short snippets (usually linking to their website for more extensive help) with Windows 8 or so, maybe even earlier.

How about not displaying the button in the title bar by default but leave it for now, accessible via Shift-F1 or so to give devs time to migrate to a system that displays the same amount of information under any desktop?

ognarb added a subscriber: ognarb.May 13 2019, 1:34 PM
ngraham updated the task description. (Show Details)Feb 3 2020, 11:21 PM
ngraham edited projects, added KF6, Plasma, KDE Applications; removed KWin.
ngraham removed subscribers: VDG, KWin, Plasma.

I would say let's think about where users are supposed to find help and then we'll see if What's This is part of that solution. I see the following help "concepts" but I am unsure about the details:

1) Focus on comprehensive tooltips
and change it so they do show up in menus so tooltips are actually available when needed (https://doc.qt.io/qt-5/qmenu.html#toolTipsVisible-prop). Try to agree that they should be way longer than they currently usually are. Rework What's This help into tooltips.

(This text is copied from the corresponding "What's This" help I wrote. Keep in mind that there are cases where it makes sense for them to be even longer.)

+ Familiar and easy concept
- Users might get annoyed when they hover something unintentionally and a big tooltip pops up (Not sure how big of a problem this is)
- Can't offer help where users might want to rest their cursors or in main working areas (KSysGuard's problem)

2) Keep What's This and improve on it
by solving it's discoverability problem with @rjvbb's idea to

add a tooltip to widgets with what's this info saying something like "Hit Shift-F1 and click this control to see what it does"

and/or by deciding that we do want a "?" in the titlebar (when appropriate) under Wayland as well.

+ Help can be offered for anything, anywhere while being nearly invisible for users that don't want help
+ Help can contain hyperlinks so users can jump to tutorial-webpages or passages in the manual
- Users still need to learn how to call for "What's This"-help

3) RTFM
We have manuals so contextual help isn't needed. (We definitely shouldn't decide on this last one IMO!)

+ Less work
- Users need to learn to open the manual when they need help
- Users workflow is severely disrupted when they need even the smallest amount of help
- Getting help requires finding the right text passage

How about another approach: A collapsible tooltop. We could keep the current tooltip text, but add a button marked "Show more" on the bottom of the tooltip. When clicked, the tooltip expands to show the full "What's this" text for that widget, if it exists. This would require allowing the cursor to move into the tooltip area without closing it, of course.

I like that as well. How would you want to handle menus then where tooltips don't show up currently? It could seem a bit redundant to hover Dolphin>Tools>Open Terminal and get a tooltip labeled "Open Terminal [linebreak] Show more". Well in most cases the tooltips aren't identical to the label so it wouldn't be that bad most of the time.

Hi, I think that the discussion "What'sThis vs. tooltip" is also a consistency problem. Referring only to SystemSettings, it seems there is no a rule: in some module "tooltip" are used, in some other What'sThis are used. In this moment I prefer tooltip, to be honest, because I dont't think users know how What'sThis can be triggered. Now What'sThis are simply generally "hidden", and users need all the information someone have provided: if there is a tooltip you just have to hover. Anyway What'sThis can carry more informations, but they should be grafically visible (for example after pressing the "Alt" key, or similar, their area should be colorize in some special way) and everyone should know they exist, too...

GB_2 added a project: Goal: Consistency.EditedMay 8 2020, 4:42 PM

Almost every app has a help button or menu item that opens the documentation. Having tooltips and the help center is enough in my opinion, because the What's This text would otherwise be a duplicate of the documentation. I think good tooltips and good UI should be enough.

In T9986#229886, @GB_2 wrote:

Almost every app has a help button or menu item that opens the documentation. Having tooltips and the help center is enough in my opinion, because the What's This text would otherwise be a duplicate of the documentation. I think good tooltips and good UI should be enough.

+1

I think good tooltips and good UI should be enough.

So "1) Focus on comprehensive tooltips" it is?

In (Re-)Add tooltips using a contextual help button I am proposing a way how we could be replacing "What's This"-help in system settings with contextual help buttons in the future. I believe this is a right way forward for settings pages specifically because those pages' main task (aside from organisation of settings) is to communicate the effects of settings which is why buttons to display tooltips seem sensible to me here.

Other than that I think the original goal of this task to find a way to delete/replace "What's This" can't really be generally decided but has to happen on an application-by-application basis. For example the kind of contextual help button I am proposing for settings pages would be way more intrusive in KSysGuard or Dolphin. And while I still think the options I listed in T9986#220391 would be viable to some extent I don't really think we are at the point yet where it makes sense to rule out specific UI elements (like What's This) from ever being used to provide help in any application. I am not sure if that could ever be possible because different applications can have very different requirements there. It's like generally deciding to not use On/Off switches.