No response in a week, so I assume the plan there must be acceptable. Time to land this so it makes it in time for Plasma 5.18.

+1 conceptually. I think this is a nice default behavior for the apps that haven't implemented nicer behaviors themselves, or refuse to.

Visually and behaviorally, this is great. Probably needs a Plasma review too.

Yep. This is an odd case of a framework depending on Plasma, not the more typical reverse!

The "Add to Places" action is in fact already in the menu, so I don't think this revision is needed anymore.

Lovely.

I think so!

In D26530#593152, @mart wrote:

yes, i'm saying that the patch besides putting the separation in the frame, it also reintroduces the frame by default, which is unrelated (and i think it should be avoided)

When I try this out, here's what I see:

In D26565#592891, @meven wrote:

It means we will need to write .desktop file on the fly which KOpenWithDialog can do.
Do we want the previously entered commands to appear in the list ?

If we use an icons-only button/checkbox, then this can't go in without the icon, which means it's deferred to Plasma 5.19. There's still (barely) time to get it into 5.18 if we make sure that we use a UI that has both icons and text.

Purely in terms of visuals, I think so. It clearly fixes a bug.

In D26586#593114, @mart wrote:

the reason for it in the beginning was t just be able to say "i don't want normal apps to be able to spam my systray" tough probably things aren't categorize well enough to be able to rely on that.
if that "no normal apps such as mediaplayers" is deemed an useful feature(which i'm not sure it is) , should probably be a checkbox that says exactly that, rather than having the concept of enabling or disabling a whole category

I'll look into it, yeah.

In D26530#592999, @mart wrote:

It would already be much better if the track was actually very visible, visually delimiting the space

Set text only once in the correct place

Thanks!

In D8208#592667, @elvisangelaccio wrote:

Well, that depends on the current sorting mode, right? If I have sort-by-modified then the duplicate file will jump to the top of the view even if it has the "copy" suffix rather than the "Copy of" prefix, no?

In D26586#592707, @kmaterka wrote:

In D26586#592050, @ngraham wrote:

Much better! The scrollview needs a frame around it though. You can do this by adding this to it:

Is it decided (D26530)? Correct me if I'm wrong, in Kirigami scrollbars are overlaying with transparent background, Kirigami just adds some paddings when needed. Anyway, to have scrollbar seprated it is better to just add one margin to the list (and remove "rightPadding" I added to header, section and list item).

Quite nice looking!

Gross, I hate it when Phabricator does that. :( I still haven't figured out what causes this. Whenever it happens, I just go back in the history (in this case https://phabricator.kde.org/D22382?vs=on&id=61521&whitespace=ignore-most#toc) copy the diff, manually apply it to HEAD and force-update the revision with arc diff --update D22382.

In D25100#592375, @mak wrote:

@ngraham Did this have AppStream metadata before? Probably the distribution data still lists this as component, while the new file lists it as addon. The distro data is preferred, so that's why this shows up as app. You need your distro to ship this as update, or set PreferLocalMetainfoData=true in /etc/appstream.conf (that should override the distro-provided data with local one, which is nice for development but not usually desired).

The output of appstreamcli dump org.kde.haenau (or appstreamcli get org.kde.haenau --details is also always helpful to investigate issues like this. On my machine (Debian testing) the component is incorrectly marked as "generic component" instead of "addon" due to its metadata (although I would argue that Discover should hide generic components as well, as those may be things like shared libraries and developer tools as well).
Changing it to addon is reflected in the metadata. but to be a valid addon component, it needs to <extends/> something.

Seems like this isn't the right way to solve the problem.

Hmm, at normal size, the 8, 16, and 22px versions look too busy to me.:

That's not Dolphin, that's their Index file manager. Nonetheless, it does show that having the Breadbrumbs/URL navigator in the toolbar can in principle work. :)

In D26392#592133, @jgrulich wrote:

Can someone please look into this review? Either try it or check the code? I would like to have this as part of Plasma 5.18 and deadline for that is in few days. @ngraham how is it going with the icon?

Hugely improved visibility with this patch:

I notice that this also has the effect of changing the button texts to not have ellipses on the end. I guess NewStuff.Button needs to do that itself?

This patch makes plasma-desktop fail to build without the dependent KNS framework change. That means that the KNS change is in fact a hard dependency and therefore this functionality can't make it into 5.18 with the patch's current state. If you want it for 5.18 (as I assume you do, and I do too!), you'll need to make D26543 not a dependency by only conditionally using the KNSCore::EntryWrapper functionality, or by finding a way to implement the fix in way that doesn't add new classes that have to be used here.

In D26572#592280, @hpereiradacosta wrote:

I would prefer not systematically render the background, because it might break existing applications, like rendering a widget on top of a painted image.

Here's another idea: we rename the existing Breeze theme to "Breeze Legacy" and put it in a different repo, and then we feel free to change Breeze as we see fit.

That seems reasonable to me as a path forward.

• path() not toString()
• Set existing URL's path rather than creating a whole new URL

Fixed, thanks. While you're touching Chromium headerbar button styling, maybe you could also fix https://bugs.kde.org/show_bug.cgi?id=414591.

Address review comments

Yep, that's correct!

Just pushed this again because KIO 5.67 was tagged today, so landing it won't break the CI this time. Phab won't let me close this, so I guess I have to abandon it for some reason. :/

Fix one thing I missed (isn't it weird how you sometimes only notice an issue with your patch right after you've submitted it?)

I agree that separating the list into categories makes it a lot less visually overwhelming to look at. If @nicolasfella was saying that maybe we could remove the feature that allows disabling all elements within a section at once, that I might be able to get behind. I don't really see a use for it.

• Fix bug with copy being put in the wrong place for filenames with extensions
• Preserve existing filename extension casing

That would be nice too. :)

Will fix bugs in text appending behavior

I can do that, sure. But IMO there's a UX problem when you append "Copy of" to the beginning rather than the end. Imagine that you have a file that starts with a Z and you duplicate it. The duplicate appears near the top of the window because it begins with C. If the current view is scrollable, view scrolls up to the top to show you the newly duplicated file. This causes you to lose your place in the view, which could be annoying if you were planning to do something else with another adjacent file or perform another operation on the original file (perhaps to duplicate it a second time to perform some A/B testing on two duplicates with slightly different changes, for example). For this reason, I prefer the macOS behavior of appending "copy" to the end of the filename, not to the beginning.

Very nice, a big improvement visually. Make sure @hein or another Plasma person is good with this too.

Also for toggling individual sections, I would recommend making the button say "disable all" or "hide all" (depending on what's most accurate) and use the view-hidden icon. Then when all items in that category are disabled/hidden, disable all controls and labels for all items in that section.

Much better! The scrollview needs a frame around it though. You can do this by adding this to it:

More generally, I'm not sure the interaction model of the Detailed Settings part of this KCM (both old and new) makes any sense. Once I choose my global locale, if I want to override individual elements, I want to choose the exact format I want, which I currently can't do.

Tweak the wording of the explanatory text

The preview area from the current KCM is missing.

You have to first introduce a group for "us" to refer to, or else it's not clear. :) If "KDE" is no-go, maybe it could say, "You can help the developers"

I think the intention is for human consumption, yes. The intention is to improve the user's confidence in making an informed choice by showing exactly what will be sent.

Oops, forgot the translation domain, sorry! Thanks for the fix, folks.

I'm good with this now as an initial implementation of the mockup. However we're a bit close to the Plasma 5.18 tagging date (January 16th). My gut instinct is to land these early in the 5.19 cycle rather than rushing to get everything into 5.18 and potentially shipping with un-noticed regressions.

Nice.

@fvogt "test.foo" becoming "test.foo copy" is intentional because .foo isn't a known valid extension, and it's valid for files to have dots in their names. In general the approach of using QMimeDatabase supports this, solves the problems of using QFileInfo that @pino pointed out, and also allows seamless support for filename extensions with two dots in them (e.g. tar.gz).

@raddison is a troll, check his history. Sysadmin intervention may be needed.

Looks like this needs a bit of CMake work to stop installing the old icons:

In general I agree with you, as long as we keep it very subtle. I think the password wiggle is a great example (BTW the "you enter the wrong password" timeout is currently 3 seconds so this wouldn't slow down anything).

In D26544#591418, @leinir wrote:

Right, the functionality would all still exist (that is, install/uninstall/update/whatnot would function just fine), what would happen without the dependent patch is that the views will be out of sync with the system state (basically the onChangedEntriesChanged will just fail to call the function it's pointed at due to incompatible types, in all but the desktoptheme kcm (which just calls load anyway, which doesn't expect anything weird).

Still needs more overlaySheet :)

In D26530#591622, @kmaterka wrote:

Example when current way looks bad: D22176. We can live with that and add margins/padding when needed. Or not :)

• Old-fashioned scrollbars are also bad, they look old and sometimes ugly (especially when list has different styles for odd and even rows). All other systems are moving (or moved) away from this.
• Gnome way is not good either, at least from my experience. It is not intuitive, I'm always trying to scroll using this tiny bar, then realize that it shows bigger version on hover.
• Disappearing is also not good, because it confuses user - sometimes they don't know that list has more elements, you need to hover a mouse over each widget to know the status. From the other side it is consistent with mobile, which is now a reference and most user are more accustomed. Maybe lists that have scrollbars (hidden) should have subtle fade-away effect on edges? Nothing is perfect. That's why I hate creating UIs :)

• Don't use QFileInfo
• Improve reliability of "copy" text appending with unusual filenames
• Add the action to the context menu

In D26565#591542, @meven wrote:

Do you mean, we should drop command line text fields, like we have in the terminal and browser section ? Only comboxbox ?