Bug 413434

I'm mostly worried about consistency here - do we not usually show close buttons on our dialogues? (which is what this is - the button specifically only exists in the KNSQuick Dialog, not in the Page)

Yeah that's true. However this window somehow doesn't feel very dialog-ish to me. It offers rich interactivity far in excess of the kind of simple questions asked by most dialogs.

However in the interests of consistency, I can accept the button, but in that case the visuals need to be improved. so there isn't a weird row on the bottom of the window with only one button in it and a different background color and no separator between it and what's above it.

I can't think of another dialog without a close button.

All dialogs have a close button in the titlebar.

Dialogs that use the ok/apply/cancel paradigm have buttons in the bottom to answer in the affirmative (Accept, OK, etc), and one to cancel the operation. This makes sense because those dialogs don't actually do anything until closed, so the dialog needs to know how you want to proceed.

However this dialog currently uses the instant apply paradigm, rather than the ok/apply/cancel paradigm. Instant apply dialogs don't need OK and Cancel buttons because there is nothing to affirm or cancel. When you're done with the dialog, you just close it. Because the titlebar already has a close button, it's redundant to add a second one in the bottom.

Right, i'll just say this again: If there are /no other/ dialogues in our software which use a singular close button, then i'm perfectly fine with getting rid of this one (since of course in that case there's nothing to be inconsistent with, or even worse, this one is inconsistent). However, if there is, then this one stays until there is a decision within the community that we get rid of all of them (at which point i'd be quite happy for KNSQuick to be a trailblazer ;) ). It's one of those options; i will not make this different just for the sake of making it different.

That is to say, i do not particularly disagree with your argumentation, i just think this is the wrong place to be making the argument :)

Fair enough. I'll be on the lookout, but I haven't seen a KDE dialog with only a close button on the bottom row. Nearly all of them instead have one of the following:
- Yes/No (which is wrong, see https://hig.kde.org/components/assistance/message.html#appearance)
- Ok/Cancel
- Ok/Apply/Cancel

Are you aware of any KDE dialogs that have only a "close" button on the bottom row?

And FWIW we already do have this paradigm of "you can close it with an x in the corner but there's no explicit 'close' button at the bottom" in notifications and Kirigami sheets. So I don't think it's really very weird or unfamiliar.

(In reply to Nate Graham from comment #6)
> Fair enough. I'll be on the lookout, but I haven't seen a KDE dialog with
> only a close button on the bottom row. Nearly all of them instead have one
> of the following:
> - Yes/No (which is wrong, see
> https://hig.kde.org/components/assistance/message.html#appearance)
> - Ok/Cancel
> - Ok/Apply/Cancel
> 
> Are you aware of any KDE dialogs that have only a "close" button on the
> bottom row?
> 
> And FWIW we already do have this paradigm of "you can close it with an x in
> the corner but there's no explicit 'close' button at the bottom" in
> notifications and Kirigami sheets. So I don't think it's really very weird
> or unfamiliar.

Sorry it took a while to get back on this one, have been busy with other things... A quick look around says that yes, we have quite a lot of them. The most prominent examples are the About dialogues, and the bits underneath that (like the License description), but also things in KSysGuard uses it, as well as plenty of our applications.

This is a non-exhaustive (and also somewhat polluted, as it's not entirely straightforward to create a good search for that that only shows those that're creating such a thing, but it's a start) list of instances of the explicit mention of the standard Close button in our codebase's c++ bits (be ware long load times): https://lxr.kde.org/search?_filestring=&_string=QDialogButtonBox%5C%3A%5C%3AClose&_casesensitive=1

As i said above, i'm not in principle against getting rid of it, and even agree that it would perhaps not be a silly idea to do so (based in part on the bits you mention), but this is not a decision that can be made in a random KNewStuff bug, this must be considered by at least the VDG's HIG people... In other words: we'll need to move this to a more reasonable product (not sure which), so a decision can be made on a HIG level, at which point i'd be more than happy to get rid of it in any software i'm involved with.

All right, I'll open a VDG/HIG discussion.

In the meantime, can you fix the bug that makes the background of the bottom row use the wrong color? Even if it's just a matter of putting a Rectangle the window background color under everything. With that bug fixed, there isn't so much pressure to remove the row and its button.

Started a Phab task here: https://phabricator.kde.org/T12655

(In reply to Nate Graham from comment #8)
> All right, I'll open a VDG/HIG discussion.
> 
> In the meantime, can you fix the bug that makes the background of the bottom
> row use the wrong color? Even if it's just a matter of putting a Rectangle
> the window background color under everything. With that bug fixed, there
> isn't so much pressure to remove the row and its button.

Absolutely, i'll get a patch worked up for that tomorrow (and the Rectangle's probably going to be the most reasonable workaround for now, since as David identified, changing the Dialog to a Window would annoyingly break bci...)

Cool, thanks. The bug report tracking that one is Bug 415606.

*** Bug 434520 has been marked as a duplicate of this bug. ***

Fixed by Felipe Kinoshita in version 5.97 with https://invent.kde.org/frameworks/knewstuff/-/commit/d3a3a2ae6a3d49c65ed547ef041ad7927824d8f4!