Makes sense to me. Now that I see them all together, I agree that /_ is a bit better. It seems much better for the folder, and at least no worse (and probably a bit better) for the disk.

In D16677#356620, @dhaumann wrote:

Unless you have a KDE commit account you can not commit yourself. Unfortunately we cannot see on Phabricator whether you have one or not.

In D8912#357052, @ndavis wrote:

Ah, that's much better. The buttons and D-pad are much easier to see. Try making the sides straight since the angle is pretty small for that size already. Kind of like this:

OK, will do!

If you do need to, you click on the Add Action... button that's above the comment text box and choose "Commandeer Revision"

Lovely. Consider it VDG-approved! I'll let @elvisangelaccio handle the remainder of the code review.

Ahh, much better! Reviewing...

+1 for making the text say "Show Hidden Places".

All right, let's wait then. You wanna keep an eye on this and make sure it doesn't get lost again?

Now that I think about it, you can probably commandeer it and finish it up now, and once it's ready we can land it with @andreyorst's authorship information. Does that sound okay?

In D15739#356449, @elvisangelaccio wrote:

In D15739#356003, @ngraham wrote:

This blows up the places tests; will fix them in this patch.

It will also break the test in dolphin :(

Cool, thanks! Will test later. In the meantime, please hange Solve https://bugs.kde.org/show_bug.cgi?id=400860 to:

I want to make clear that @renatoo was the original author, and this work was committed in da6f8fe0862585287153f0d90e19eab0b34bfbef.

The test has since been fixed, but unfortunately there's no way to re-close this revision unless the original author (@renatoo) does that, or someone else commandeers and abandons it. Since @renatoo hasn't been active recently, I'll do the latter.

Oh gosh, how did we miss this? Yikes, I'm very sorry about that.

The image in this patch is out of date since it was added before other changes were made; I need to update it and will do so later today.

+1, works great for me.

In D15739#356010, @davidc wrote:

I do think changing the default label of Root's mounted device would prevent the confusion of the one user who wanted it removed from Devices.

IMHO it generally makes sense to improve strings--as long as they are genuine improvements!

In D15739#356008, @davidc wrote:

Are you referring to the mounted device under the Devices section?

Yes.

I do not understand why this change provokes any negative reactions. Right now, the Places panel has two items that both lead to the exact same location. This patch simply removes one of them by default, and adding it again if you want is a 10 second operation. No functionality is lost; / can still be accessed with a single click on an item in the Places panel by default. There will still be a "direct shortcut to the root directory".

This blows up the places tests; will fix them in this patch.

Thanks for the explanation! Just what I needed to feature this in https://pointieststick.wordpress.com/2018/11/07/this-week-in-usability-productivity-part-44 (link will work starting this Sunday).

...Yet another thing that would be made far easier by using arc. ;)

Thanks, this fixes it for me. +1

Ah, thanks. And presumably shipping that networkmanager plugin would be up to distros, right?

If there's a better way to support watching videos in a little frame in the corner, I'm all for it. Alas, I lack the technical understanding to imagine how that would be implemented in an optimal and video-source-agnostic manner.

Very cool! Does this actually implement full native WireGuard support, or only add support for the NetworkManager plugin available at https://github.com/max-moser/network-manager-wireguard?

Even if you can't interact with the content, isn't is still potentially useful for other reasons?

Thanks for the impeovement! :)

In D14631#355791, @mlaurent wrote:

For me seems good +1

In D7446#355675, @andreask wrote:

I would suggest to have by default detail view instead of icon view cause with detail view it's easier to read the paths.

Rebase on master

• Revamp the whole section

How about removing the "drawer header" UI concept from Kirigami entirely? ;)

Uh-oh, now the patch doesn't apply for me anymore:

But you can plug speakers into the headphone jack on a laptop. They can use the same 1/16 minijack as actual headphones.

Thanks, this works great for me.

Does this have the potential to inappropriately show a headphones OSD when you plug in speakers, or vice versa?

What is a "typical PiP"?

I'm afraid that didn't change anything for me. If the experiment to make the background color adapt to the theme isn't working, maybe we should revert that change for now and just keep it hardcoded for now.

Is this logic correct? Just because we found any entries, we don't use DNSSD? Is there ever a case where we found some entries but might find even more by using DNSSD?

Is this finished now?

Indeed it can. Great job! May it be the first of many. :-)

Thanks Vlad. Correct me if I'm wrong, but there are some things we could trivially change right now: the name, default settings, and whether or not it's enabled by default. What are the technical barriers to allowing mouse interaction and dynamically showing a titlebar button?

In D16538#351260, @sitter wrote:

The size of the ifdef (and the therein contained code copy) isn't making me super excited. OTOH there are some 10 or 20 differences between the two if-branches, so separating it into multiple ifdefs is likely a mess as well. And @asn pointed out that doing it this way makes it easier to drop the legacy branch in the future.

Anyone got ideas how to make it better?

I am somewhat 'meh' about the ifdef but not enough to object, so in the absence of improvement suggests I'd probably go +1

The point is, there is no reason to reference distos (which are downstream from us) when we fix issues here. It does not matter that many or even most reports came from Neon. All rolling release distros have Frameworks 5.51, so it certainly was not just Neon users experiencing the issue.

Looks great and works great! Nice first patch. Just one more thing is required before I can land it: add the following to the Summary section of the patch:

Add a link to the "Get Involved" page

Ping! VDG or Plasma?

Is this good to go now?

Two trivial changes then go ahead and push!

Thanks for making those changes. Now we can see the icon, and also an issue that needs to be corrected. :) Notice how the corners look really bright--especially the bottom corners? That's a problem. I suspect what's happening is that the lines you drew to make the border are semi-transparent, but overlap one another at the corners, so the corners are mor opaque and therefore lighter. Either way, that "dots in the corner" effect must be fixed before this can land.

Thanks for the patch! And thanks for using arc, too. That makes life a bit easier for us. :)

Seems like this is only a problem if you have a single-item menu, and if you have that, you've done something wrong. :) Regardless, this seems to fix the issue, so +1.

Great, thanks! This work well; I just have a few comments, listed below.

Oops, you want to be sure you're on the permeability branch when you run arc diff.

Great job, and nice first patch!

Use isStorageAccess() rather than isStorageVolume()

Address review comments

Hopefully this should fix it: D16678

This broke icons for other things; currently investigating and will fix ASAP.

Yeah, I understand that it can be hard to visualize changes like these before there are pictures. Thing is, we're in a tough spot, because the current design turns the wallpaper into a soupy mess and generates user complaints. I agree that we shouldn't regress usability, but aesthetics are very important too. What's being proposed here is nothing more than a superior version of what we shipped from Plasma 5.8 - 5.12 (which is what I wanted all along during the 5.13 design changes but didn't get because we ran out of time before we had to ship something due to our very short release cycles).

• Improve contrast for bottom buttons
• Correct color names

Hmm, I just deployed with the latest change and suddenly the icons are weird:

Sorry for the extended review time for this! Next time, posting both before and after screenshots might be helpful for people not familiar with the current UI. Anyway, it looks good to me. Let's also see what @Zren says, since he's rapidly becoming the de facto maintainer of this code. :)

Fix embarrassing errors

FWIW, inline "what's this" help is something we're considering removing altogether for a variety of reasons (T9986), so I would prefer to ensure user-friendliness via an intuitive UI, tooltips, and non-inline documentation. Often a little inline note can work. Here's an example from Gwenview's settings dialog, which makes use of this paradigm:

In T9986#166340, @graesslin wrote:

I don't think we should just remove the button, but instead look for all usages in Plasma and migrate them to something more appropriate. Once all are gone I would say we remove the complete feature as nobody else supports it anyway. And we should update Qt doc (e.g. https://doc.qt.io/qt-5/qwhatsthis.html ) to make it clear that it's not available on all platforms.

Are there any Windows users who have actually used it in the last 15 years? :p