0

Sometimes it is really unpleasant and not efficient to use the mouse just to change focus or press a button.
In my opinion, it would be great if KWin would be able to generate on windows, upon some key combination, hints on clickable items labelled with letters a bit like the vimperator for firefox or vimium for chromium extension are doing on a webpage:

The mock of course looks terrible and is incomplete, but should be enough to get the idea.
I think this would be really comfortable in a lot of cases, as well as a very good accessibility tool for people less able to use the mouse properly. It would not solve the problem of right click versus left click and so on (maybe with different modifier keys and hint color?), a mouse would still be needed, but the vast majority of clicking could actually be replaced by simple typing.

Thanks for considering this!
Cheers,
Samuele

The WM has no idea about client internal features. This has to be provided by the client/toolkit (for each client).

Indeed, you're perfectly right; there is no way to implement it directly in a WM. But...
I guess the question mark here could be shifted a bit to answer the questions:

0) Would it be worth it to extend the question to toolkit developers?
1) Suppose each toolkit provides the needed information. Would this feature be useful/interesting to enough people to be worth developing?
2) Supposing it is a useful wanted feature, should it be implemented as I imagined (WM asking clients about clickable attributes and labeling them) or should be handled independently by the tk?

How much this is required, I cannot say.

Webbrowsers usually have such feature to directly access links.

For "normal" applications the initial challenge would be to have a sane tabfocus chain in the first place. Then serial navigation is usually sufficiently fast (because you just keep pressing the same huge key until you are where you want instead of 1. triggering a shortcut to show the hints, 2. check the proper key to got to the elemtent and 3. invoke that)

Implementationwise, the compositor should (if at all) only optionally extend the internal feature, because
a) it actually has no advantage (the hints will be displayed inside the client, thus can be composited internally - ie. translucent etc)
b) because fragility multiplies here, ie. you'd require Client AND WM to support this (and not be buggy and if required for a11y, this is probably not "nice to have" thus primarily should work, then be cute.