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

Description

We should consider removing this UI paradigm from our software. It's not supported on Wayland and on X11, most of our apps don't implement it at all or to a degree that's actually useful. Generally, out of the whole UI, only one or two buttons will have "What's This?" text, which is not a useful user experience; this is a feature that's really only useful if it's implemented truly universally, which it definitely is not.

See also D15307: Remove Context Help button by default. Let's figure out a path forward for removing this mostly-useless functionality. Instead, I think it would be better to focus on improving the the docbook documentation and the user interfaces themselves so they're as self-documenting as possible and have good tooltips.

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