Element-specific help should be displayed consistently

In situations like this, I’m always perplexed why kcm_kwinrules’s new method of displaying that help is available (with dedicated buttons)

isn’t standard, since knowing where and for how long to long-press (when using a tablet) or hover (when using a pointing device) isn’t whatsoever intuitive.

As an example, would you be aware, as a new user, that you can hover over some of these items to see tooltips?

I don’t think so.

Consequently, I propose that we add help buttons beside each element in all configuration pages, which are disabled when no help is available.

As you point out, the pattern is somewhat new. I used it for the first time about four years ago. Previous to this it wasn’t a really a pattern KDE contributors were considering. Since then it was used more and more, but this is one of the reasons you aren’t seeing it in some places where it might make sense.

The other reason why the pattern wasn’t used in QtWidget’s applications like Konsole much until now is that we didn’t have a dedicated component for it. This has changed very recently when I wrote it (Introduce KContextualHelpButton - QtWidgets Edition (!240) · Merge requests · Frameworks / KWidgetsAddons · GitLab).

So now it is very easy to put such help into a button, but it still needs people to actually spend the time to do it. IMO it is very easy to do now even for total programming beginners. There are also currently new Human Interface Guidelines being written which will contain explicit advice on when to use this pattern, so new contributors wouldn’t even be left alone when it comes to the design aspect of this.

2 Likes

That’s absolutely perfect, @felixernst. If we had the Solutions plugin available for this topic, I’d mark that as it.

1 Like