The window behavior KCM has several values for configuring the focus stealing behavior: None, Low, Medium, High, Extreme These names do not tell anything about what kind of behavior they are introducing, so the user has no idea what suits their needs. Either the names should be more expressive or an additional explanatory text should be given
Indeed.
That's what the help page is for, no? Do you think these explanations are to short? Or do you think an inline explanation label should be added? Imo, if one starts doings this, it gets difficult to draw the line where to stop doing this because all of the focus stuff is not self-explanatory, and the more help is mixed into the main UI, users may even become less aware that an extra help page with more complete and more detailed explanations exists. Imo, it is better to keep a dedicated, well worked out help page than try to squeeze half complete information into the already cluttered UI. I just recently gave the window behavior docbook an overhaul and can try give that ancient specialist stuff some more love.
The problem is that almost nobody reads the help page. And it shouldn't be expected that a feature is incomprehensible unless you do read it. If this were a QML KCM, we could use KCM.ContextualHelpButton to provide the information semi-inline without cluttering up the page with lots of text.
I can somewhat agree with this. Maybe for the meantime we could add a short sentence what focus stealing in general is about, and refer to help page for more info on the individual options?
I would also be in favor of a general reorganization of the window behavior KCM and not display the focus tab which is probably the most complicated as the landing page, but I think that's for another thread.
Or maybe explaining the options actually is better because then we could add a note like in the window activation policy that the default is probably what they want.
(What I mean is a dynamic label for each option, as opposed to my earlier suggestion of a general explanation for focus stealing prevention.)
(In reply to Natalie Clarius from comment #7) > (What I mean is a dynamic label for each option, as opposed to my earlier > suggestion of a general explanation for focus stealing prevention.) Yeah I think that would be fine.
What about the "whatsThis" texts? We actually already have inline help for all of the items in the KCM - except it doesn't seem to be working; I assume these texts are supposed to be shown on hover, but that's not happening for me. This does not necessarily preclude adding a label text in addition and/or porting to QML some time in the future, but it would be nice if we could actually make use of the help we already have. Does someone know what's up with this feature?
WhatsThis text doesn't appear on hover, that's tooltip text. It needs to be be seen by explicitly invoking "what's this?" mode via the question mark titlebar button (which isn't supported on Wayland). There's also the secondary mode to make it appear when you press Shift while a tooltip for a UI element with WhatsThis text is visible, but that requires that the UI element have a tooltip.
Ah, that never occurred to me. I can't get that question mark button to show up anywhere even though it's in the title bar according to the title bar buttons configuration, but thats off topic now.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3964
Git commit d25b9ebdb16b78d6ba2190048396d039e8e72289 by Nate Graham. Committed on 12/04/2023 at 14:03. Pushed by ngraham into branch 'master'. kcms/rules: improve text for window rules with descriptions In particular, explain what all of the the focus stealing prevention and protection settings do. My understanding of the different modes comes from reading the code and code comments in activation.cpp. M +65 -31 src/kcms/rules/rulesmodel.cpp https://invent.kde.org/plasma/kwin/commit/d25b9ebdb16b78d6ba2190048396d039e8e72289