There are message boxes in KDE with the "Don't ask again" checkbox (see example screenshot above).

If the checkbox is activated the message box will not be shown again. After some time, one might want to read the - potentially useful - message box text again but there there is no obvious way of doing so. I think the only way is to edit in the applications config file manually.

1) Is this a problem worth being solved?
2) How? (e.g. put a menu item in the Help menu that resets all message boxes)

gregormi wrote:1) Is this a problem worth being solved?
2) How? (e.g. put a menu item in the Help menu that resets all message boxes)

1) Absolutely
2) Reset all would be the second best solution in case of many notifications. Rather a menu with checkboxes for up to ~6 items/notifications, or an extra dialog otherwise. (6 is an arbitrary number; HIG says 10 items max for context menus and 12 for main menus)

PS: We should consider that main menu is only there for very complex apps [1].

I think that using this kind of dialog is already a problem worth solving
The HIG already restrict the use of message box for warning about an unexpected behaviour. For other types of warning, a Message Widget ( https://techbase.kde.org/Projects/Usabi ... sageWidget ) should be preferred. As it is not disruptive, it can be displayed every time.

For that specific dialog, it seems to rely on Xorg, and it will certainly have to be redesigned for Wayland. It would be much better to ask for confirmation once you clicked than before, but I guess this is how Xorg works and it can't be changed easily. The best solution in my opinion would be that KWin display a warning message at the top of the screen, and when you move the mouse over a window, it gets darken and a button "kill this application" appears.

The problem is rather that this needs to be a "fire and forget" dialog - kwin cannot use an in-process dialog (it cannot create a managed window at all, causes interference with the eventhandler)

The best solution in my opinion would be that KWin display a warning message at the top of the screen, and when you move the mouse over a window, it gets darken and a button "kill this application" appears.

"message on top of screen" requires a compositor as well as darkening the window does.
The pitfall with a "kill this application" button will be that windows are stacked, ie. you might run into a condition where the button would largely be outside the targetted window or stashed below others.

The feature is btw. a knockoff of an acient tool "xkill" - that does not mean it could not be improved

- must work (reasonably) w/o compositing
- must deal with stacked windows
- must *not* rely on a titlebar
- must *not* require interaction w/ a (traditional, unmanaged - ie. no titlebar, no raising/lowering etc.) dialog

@luebking: sorry, I wasn't clear, but I was talking about KWin_wayland, where there is always a compositor (correct me if I'm wrong). For KWin_x11, I think not much can be done. This dialog directly triggers xkill, it seems very difficult to change anything (even the skull cursor). If it is possible to have the same behaviour under both platforms, of couse it is better, but if the wayland version must be crippled to adapt to x11 limitations, then I would prefer separate solutions. This dialog has been there for years, it is not perfect UI-wise, but it gets the job done and can be kept as is.

AGuiFr wrote:I was talking about KWin_wayland, where there is always a compositor.

Yes, but neither does that amend the other issues, nor will "let's please have completely different code branches for some corner case feature" get you much applause from devs

AGuiFr wrote:This dialog directly triggers xkill

Nope - ou can deinstall xkill, if you want. We've total control on the behavior.
It's implemented *after* xkill, not using it

AGuiFr wrote:If it is possible to have the same behaviour under both platforms

Is.

We could
a) change the cursor (to some image, but that's no more really stylable)
b) display a (dynamically positioned, always on top) tooltip whenever hovering a client that will be killed
c) send a notification (defaulting to a message by knotifyrc) when the feature is triggered
d) "enrich" the entire thing w/ compositing features (ie. /if/ a compositor is up, the window could be tinted red, or whatever, in addition)
e) add killing to the alt+f3 menu (though you get offered killing for decorated windows when closing them fails anyway)
f) ...

But the mentioned restrictions hold - this needs to work for stacked, undecorated windows, we need a solution that works w/o compositing (and ideally not entirely different from users and devs POV) and does not involve some "yes/no/cancel" dialog, at least not in terms of "normal" dialog (while something like the window shortcut selector from the Alt+F3 menu would obviously work for interaction)

Heiko Tietze wrote:

gregormi wrote:2) How? (e.g. put a menu item in the Help menu that resets all message boxes)

2) Reset all would be the second best solution in case of many notifications. Rather a menu with checkboxes for up to ~6 items/notifications, or an extra dialog otherwise. (6 is an arbitrary number; HIG says 10 items max for context menus and 12 for main menus)

PS: We should consider that main menu is only there for very complex apps [1].

So what can be done if there is no main menu? For example with the "System Activity" you get when Ctrl+Esc is pressed: there is no help menu. Possible solution: What about looking if the Ctrl or Shift key is held down when invoking the action that shows the "Don't ask again" message box. If the key is held, then the message box is shown in any case. (I am aware that this it not an obvious feature and might conflict with the usage of the message box in certain cases but maybe better than editing config files)

gregormi wrote:What about looking if the Ctrl or Shift key is held down when invoking the action that shows the "Don't ask again" message box.

Nice technical solution. But as you say it's not obvious to the user and therefore questionable in terms of usability.
Anyway, AGuiFr made the point: HIG says to not use dialogs for simple warnings. And if the workflow needs to get interrupted it should be done every time. Therefore the checkbox have to bite the dust.
If you decide to be non-conform with the HIG a menu entry or configuration switch would be the easiest solution.

Heiko Tietze wrote:

gregormi wrote:What about looking if the Ctrl or Shift key is held down when invoking the action that shows the "Don't ask again" message box.

Nice technical solution. But as you say it's not obvious to the user and therefore questionable in terms of usability.
Anyway, AGuiFr made the point: HIG says to not use dialogs for simple warnings. And if the workflow needs to get interrupted it should be done every time. Therefore the checkbox have to bite the dust.
If you decide to be non-conform with the HIG a menu entry or configuration switch would be the easiest solution.

I see. "Don't ask again"s should be avoided when possible. So more work should be done in eliminating existing dialogs of this kind. For the existing ones a help menu entry might be the way to go.