Ah, so simple! I had worked on a patch for this same issue and suspected it was something like this in here, but couldn't quite figure it out. Nicely done.

It's important to test your changes before submitting. :) This now causes Gwenview to segfault when you try to edit its Trash entry. The reason is because now that m_iconButton isn't added to the layout, the line beginning with layout->labelForField() crashes when it tries to run, since `m_iconButton isn't in a layout. That needs to be moved into the conditional as well.

This works fine for me, and I think the code is sensible. It's quite a mess to not set m_iconButton at all in this case, so I'm okay with the patch as-is.

Is this the right diff? It doesn't include the earlier changes.

Er, yeah, oops. Or just reverse the ordering of the statements inside the if and else blocks.

Yeah, I think they're already fine. :)

Much better!

Also, can you add CCBUG: 391200 to the Summary section and edit your Test Plan to indicate that it should be done in Dolphin?

Didn't we already do this?

This works from Gwenview (for example), but does not work from Dolphin, because sadly Dolphin has its own duplicate of this code. :( Could you submit another patch for Dolphin too? It's the same change, to a file by the same name. :(

Looks nice!

Thanks, that should have been obvious! :p

Add the right import (this somehow works without it, so there must be an implicit import somewhere...)

Use zopflipng to squeeze the image down even smaller (thanks @bruns!)

Something like this set:

Now that I look at my screenshots more closely, it seems weird to have:

Use consistent casing

Anyone? Does anyone use this? What's the use case for it instead of simply clicking on the Default button at the bottom of the window?

Funny story: after multiple attempts to use Inkscape to make an SVG of this, all versions were much larger than the new png! I don't think that's an option. @broulik, does the current approach look sane to you? I wasn't able to make it work simply adding an @2x image without code changes.

Thanks for the history! Two questions:

Oh. Maybe I don't know the history here. Why do we have PC2 and PC3 versions of this control, with the PC2 version using QQC1, and the PC3 version using QQC2, but not having all the features of the PC2 one? And why can't we change the PC3 version at all?

In D14345#297329, @davidedmundson wrote:

PC3 was previously designed to be a drop in QQC2 implementation. There is currently no new API.
It /might/ have changed after we made plasmastyle instead. Check with Marco.

In D12946#295395, @rooty wrote:

hey guys, resident grammar nazi reporting :D
it says Click Behaviour (british spelling), and the rest of the module uses Behavior (american spelling)
a great idea otherwise

sorry :D

Sorry for the long delay in reviewing. I gave this a shot with a huge batch of 400 updates on Neon. It was a huge improvement in user experience. It's hard to express how much better Discover felt during the process. Somehow I felt more in control (a completely illusory feeling, of course) and more aware of what Discover was doing (not at all illusory). Even without animations, it's still fantastic. Strong +1.

I agree. +1 on how it looks with a combobox. Is there any way to manually remove resolutions so I can get it to use a slider and test that case?

When there's only a single screen (the common case), I think it's pretty clear that everything in the KCM is about the single screen that you're currently looking at. IMHO no need to have a separate "here's your screen!" UI.

Hmm, instead of removing them, I'd prefer if we used better icons. Maybe like that little icon of a mountain and a sun within a frame that we already have--but rotated.

We've got this in 5.13 now!

I'm centralizing the discussion here so we don't have three Phab tasks tracking the same thing. I've migrated the original description (with some editing) from T3464.

Let's centralize the discussion in T7254. I've closed the other two.

Let's centralize the discussion in T7254.

Yes, definitely. Let's centralize the discussion in T7254.

Shall we merge this with T7254? Seems a bit redundant to have two tasks open about essentially the same thing.

Let's take an even bigger step back! :)

+1, change seems sensible. Works nicely for me with the few .ico files I've got, and nothing else appears to be negatively affected.

In D14326#296957, @gladhorn wrote:

In D14326#296857, @broulik wrote:

The slider case after looks misaligned here now. I think you should set margins to zero only for the ComboBox case where there is only that single widget?

I disagree, before the 720x400 in your example would have double spacing and not be alined with the checkbox above or combo below. It also had extra space on the right for no good reason. Why should it have extra spacing?

Don't explicitly mess with the combobox sizes; just use a QFormLayout and let it handle that for you.

Approved; having a single item under an Advanced section didn't make much sense. Also, in the next patch we can use a nice simple QFormLayout for everything here, which is good because the misalignment of the Resolution ComboBox is driving me bananas! :)

Darn, that's a shame. "Not Provided" it is, then. @bruns, are you okay with this?

What a dramatic set of before-and-after images! It's like we jumped from 1991 to 2018.

Hah! Well in that case, that won't be a blocker.

<teach-a-man-to-fish-mode>Check out https://community.kde.org/Get_Involved/development#Get_the_code :)</teach-a-man-to-fish-mode>

It's the edit-clear-history icon in the breeze-icons repo.

Yes, I like it the idea. The chosen shortcut makes sense, and I'm always in favor of standardizing these across apps. Let's hold off on landing this patch (if accepted by everyone) until Cirkuit has had a release with D14202 so we don't wind up with the dreaded "Ambiguous Shortcut!" dialog.

Gwenview's bugs are already fairly well triaged these days. I would recommend going through the old kio bugs. I think this will yield more fruit since there's lot of crusty stuff in there that's already been fixed over the years or is no longer relevant, and the work will have a real benefit since it will bring us closer to being able to have 0 bugs in kio with everything in the new frameworks-kio and kio-extras components instead. At that point, we can go through those bugs. KIO is super important since it underpins the operation of many KDE apps and features.

Great work. Zoom speed in View mode now feels perfect, pinch zoom gestures now zoom into the midpoint between the fingers and zoom-and-pan works perfectly, the thumbnail bar works reliably, and we use the single-touch paradigm in touch mode. I feel like we're getting really close! Here are the few remaining things that still don't work perfectly for me:

@davidedmundson does this look okay now?

"Not Provided" makes it clear that someone didn't provide the information, but who? If we can't agree on anything else, I'll agree to compromise on "Not Provided", but I'd still prefer something a little bit more descriptive like "Not provided by <application>"

+1 conceptually.

@wbauer, does this work for you now? Or @bruns? Still cannot test as I have no NTFS partitions.

Could we get Plasma or KWin review for this?

Could we get Plasma or KWin review for this?

Could we get Plasma or KWin review for this?

Go for it then!

Can we commit this?

I'm not comfortable with the string "Missing". It's a developer-centric string that's not user-friendly, and it doesn't help the user figure out what's wrong or whose fault it might be. We'd get bug reports over this; people would say, "If it's missing, KDE should provide it!!!" And we'd reply, "It's missing from the app, not from us," and this would happen a dozen times.

Explanation makes sense and the patch works as expected.

No objection, please proceed.

ref https://bugs.kde.org/show_bug.cgi?id=396435`