• rebase
• use QStringLiteral

Thanks for the review. I have more small patches like that slowly making it through the pipeline, I hope you don't mind me requesting yet another review every other day ;) (Still fighting with the cursor issues though, sorry for the wait in that Diff of yours…)

@ngraham I've got a couple of questions regarding your RFC:

In D14700#305594, @rkflx wrote:

(I'll clean up the #ifdefs separately, mainly asking for general consensus for the version bump here.)

Thanks! I added the context menu back, cleaned up the blur and most importantly redacted the window title :)

(You might want to use Rectangular Region, because none of the other modes can capture both a shadow and a context menu at the same time. It's a bug in Spectacle, I actually had to GIMP the screenshot for Gwenview…)

In T9273#154856, @vkrause wrote:

I can try, the problem is that I need to blur most of it since that's full of my folders/emails, I don't have a clean demo setup handy.

confirm -> correct

KMail, KDE's powerful email client, features some improvements in the travel data extraction engine. It now supports UIC 918.3 and SNCF train ticket barcodes and Wikidata-powered train station location lookup. Support for multi-traveler itineraries was added, and KMail now has integration with the KDE Itinerary app.

@cfeck Sorry for not providing screenshots earlier. Was just about to capture some when I noticed your commit.

• Update wording with my suggestion from yesterday.
• Remove empty line.

In D14700#306303, @ngraham wrote:

Distros that are still shipping very old versions of Qt aren't going to be shipping bleeding-edge versions of Gwenview--or KDE Applications more generally.

In D14755#307623, @muhlenpfordt wrote:

Looks good to me. Works as stated and I can't find any issues, also zooming by Ctrl+DoubleClick still works.

Hi, thanks for reaching out.

In T9273#153875, @cfeck wrote:

If more time is needed for the text, I can commit it Friday night.

@faridb Are you still around?

(I'm aware that the size slider for Reduce Red Eye now is quite long. There will be a follow-up fixing that along with a bunch of other issues.)

Thank you everyone who wrote and improved the text! It's in a pretty good state now as far as I could tell when checking thoroughly (at least for the apps that are present in the etherpad, we might want to expand next time…).

@progwolff Any comments on the proposal below?

Anybody else from Spectacle wanna review this, since @ngraham is busy? (When I asked in the task whether to commit directly, the answer was a bit ambiguous…).

Thanks, works great. Unless @asturmlechner or @kmorwinski find anything wrong with this until Monday, let's land this to the frameworks branch.

@muhlenpfordt I'd say go ahead with landing (after updating the version). It would be good to still have some testing time before the next Frameworks release.

(I'll clean up the #ifdefs separately, mainly asking for general consensus for the version bump here.)

In T7927#154112, @abetts wrote:

In this mockup, is the bottom section dedicated to choose fonts differently than general but for specific elements, like a titlebar, window, buttons, etc?

One more quick idea (have not really thought about it, no final wording etc.):

In T7927#154107, @ngraham wrote:

Yes, I had worried about that, but hadn't come up with a solution.

Have you thought about how to keep the simple and the advanced tabs in sync, in particular when the user chooses conflicting options in both of them at the same time?

In D14578#303087, @muhlenpfordt wrote:

It seems to come from a Phonon::AudioOutput::volumeChanged signal but no idea why this happens only sometimes.

Thanks for the help. Works great, just one inline question about an edge case (everything else LGTM).

Thanks, LGTM now.

In D7581#304708, @hetzenecker wrote:

how to handle the freedesktop.org thumbnail caching spec

In D13901#304086, @ngraham wrote:

Are there some quirks we didn't account for when you git checkout a specific revision and build it?

In D14583#304621, @anthonyfieroni wrote:

What fullscreen issue?

In D14610#303987, @dfaure wrote:

Hmm, well, for IconApplet's use case

Thanks for the update. This leaves us with the Browse mode and Fullscreen issues.

• Use function instead of static const

There are two more problem I noticed, this time in View mode:

• Repeatedly clicking fast on one of the forward or backward buttons will only change the image for every second click.
• Doing the same for videos will accidentally trigger fullscreen mode.

Yeah, a lot has happened since last year. After the finishing touches are done, this should be checked carefully again.

In D14449#303766, @shubham wrote:

In D14449#300327, @ngraham wrote:

+1 for using the same label but putting the information on more than one line like @rkflx suggests.

In T9250#153580, @xyquadrat wrote:

3. Batch: Oldest kamera bugs (https://bugs.kde.org/buglist.cgi?chfieldfrom=2000-01-01&chfieldto=2009-08-10&component=kamera&list_id=1534763&product=kio&query_format=advanced&resolution=---)
4. Batch: Still old kamera bugs (https://bugs.kde.org/buglist.cgi?chfieldfrom=2009-08-10&chfieldto=2013-07-01&component=kamera&list_id=1534765&product=kio&query_format=advanced&resolution=---)

This comment has been deleted.

Thanks, looking better than before now. There are still some improvements you could make:

• There is a superfluous space before the comma in the second line.
• I'd prefer the bar to be a bit wider by default. However, it turns out there is a problem with my original suggestion (see inline comment).
• The vertical spacing between the first and the second line is too big, it should be the same as for Size:. However, there should still be enough spacing so it also looks good with the Oxygen style. As far as I can see this is an issue with how Breeze renders the KCapacityBar, in particular the bounding rect contains unnecessary margins (⇧+Ctrl-click on it in GammaRay and compare Breeze and Oxygen). Of course that's material for a patch in a different repo, but the "hole" in your current screenshot does not look good (the second line is closer to the bottom than to the first line, which is bad!), and it would be better to fix the problem there before landing the KIO patch.

In D14610#303537, @rkflx wrote:

KPropertiesDialog::setFileNameReadOnly
m_bFromTemplate

In D14449#303660, @shubham wrote:

Let me plug my suggestion again:

Device capacity: ==----- 24% used of 94.4 Gib
                 22.5 GiB used, 71.9 GiB free

if this design is used , then the capacity bar would look elongated and stretched, which doesn't looks good.

In D14378#303463, @pino wrote:

... that change the role I have in this review. Sorry, I will not do that. You have already all the data needed, including the fact that the patch is acked already. Unless you really care about the green tick, just to see that "everybody accepted it".

@shubham Thanks for helping out with T9297!

Thanks for the updates, LGTM ;)

In D13901#303037, @ngraham wrote:

In D13901#302769, @rkflx wrote:

To properly test whether your patch introduces a regression, you would have to compare Gwenview's behaviour with 2324a8681a44 against that with D13901.

Yep, that's exactly what I did. 2324a8681a44 does not have the bug.

Initialize HudSlider for video controls after widget is setup

Nice! This fixes even the time slider which showed the same issue when trying to open a video with an unsupported codec.

Happy birthday D7087, you are now 1 year old.

In D14583#302948, @anthonyfieroni wrote:

Yeah, click in Browse window buttons are not handled, it's needed there ?

In D14583#302946, @anthonyfieroni wrote:

It works everywhere, i use such a mice for years (more than 5) you miss a lot :)

Okay, seems nobody around here has such a mouse anymore, but I think in View mode this is working fine.

Thanks, I'll have to look for such a device. Meanwhile, I've got a couple of inline comments.

Thanks for the patch.

In D13901#302768, @steffenh wrote:

after
git checkout 2324a8681a44
and
arc patch D13901
I have found the same issue.

In D13901#302514, @ngraham wrote:

@steffenh, I'm afraid I've found a regression in your patch as compared to git master from the point where you branched (2324a8681a444cd1b9b441e481adb15c09f92837)

Thanks for the patch.

In D13249#301827, @muhlenpfordt wrote:

Spectacle seems to have a similiar issue when dragging the screenshot preview to the desktop.

That's interesting, thanks for the hint! I assume you are running Spectacle 17.12, but since Spectacle 18.04 there is D10427, which actually removes setImageData to make it work for Chromium, and apparently also fixes the issue you are reporting when dragging to the desktop.

Correct - I used 17.12.3. Tested with 18.07.80 in a Neon VM does not show this problem (but drop on desktop does nothing).

Let's hope for the best ;)