Save the comments, this looks reasonable to me.

Note that this behaviour of sddm is not in any release yet - only in git.

As there's no reason to clear the environment, wouldn't it be more useful if StartServiceJob would only allow adding/overwriting variables?
StartProcessJob does not need an option to set the environment at all AFAICT.

Fixing some style issues

Address comments. Still works.

In D27002#605999, @ngraham wrote:

Could this be the fix for https://bugs.kde.org/show_bug.cgi?id=398908, or part of it?

In D27002#605860, @meven wrote:

User feedback: "so far so good, 160 MB Memory usage"
Does not sound reassuring, I guess the user meant 160 MB compared to 200MB or similar prior to patch.

I'll land tomorrow if no objections.

In D26842#605850, @bport wrote:

In D26842#605839, @fvogt wrote:

Does this mean the default fonts have a style name of "Regular" now? That will break setting bold fonts and such, see https://phabricator.kde.org/D9070.

Default is not serialized in the configuration file (because it's the default value).

I do some check with current KCM version, and when we save it, we end up with font=Noto Sans,10,-1,5,87,1,0,0,0,0,Regular
Because nearest font algorithm return the regular one. So if I well understood everything this patch will not break anything.

Does this mean the default fonts have a style name of "Regular" now? That will break setting bold fonts and such, see https://phabricator.kde.org/D9070.

In D26891#605464, @ngraham wrote:

LGTM now. @meven and @fvogt, you good with this too?

The only remaining question from my side is why we have four different gtk configuration files and whether that causes issues.
Besides that, only @meven's comment needs a resolution.

Make a copy, QObject::children returns const & for some reason, so gets modified during iteration.

D22758 got merged

Hm, totally missed the notification for this...

In D26947#601517, @ngraham wrote:

5.18 I suppose?

Tested, confirmed to work.

In D26891#600837, @gikari wrote:

@fvogt Do I understand correctly, that kconf_update script also run on Plasma update, if I add a new Id to one of .upd file (or add one with new Id)? For example from 5.17 to 5.18?

In D26891#600285, @gikari wrote:

In D26891#600210, @fvogt wrote:

It should only do the migration once, like the kconf_update script.

From where migration script is launched? Can the migration script itself be a standalone entity, that uses kded module for requesting the current theme ans setting whatever it wants in every config?

In D26891#600264, @gikari wrote:

In D26891#600210, @fvogt wrote:

If this is adjusted to include the migration code for older breeze-like GTK themes from https://cgit.kde.org/breeze-gtk.git/tree/kconf_update/main.cpp?id=b00e12ff39264fd8c2fb8af4168e998726766dfa, it should be possible to drop the kconf_update script there.
It might even cause conflicts otherwise.

If I understood correctly, this script replaces the theme setting from orion/oxygen-gtk to Breeze. But what if a user wants to actually use Oxygen for GTK theme?

If this is adjusted to include the migration code for older breeze-like GTK themes from https://cgit.kde.org/breeze-gtk.git/tree/kconf_update/main.cpp?id=b00e12ff39264fd8c2fb8af4168e998726766dfa, it should be possible to drop the kconf_update script there.
It might even cause conflicts otherwise.

Rebased

I'll just land this now...

The change itself is correct, but not in relation to the title and summary which are about https://bugreports.qt.io/browse/QTBUG-80967, which was a genuine bug in Qt, fixed in 5.14.1.
What this change fixes is double scaling in applications which enable Qt::AA_EnableHighDpiScaling.

Ping.

In D25856#594088, @meven wrote:

In D25856#575125, @fvogt wrote:

In D25856#575083, @ngraham wrote:

In D25856#575044, @fvogt wrote:

IMO this should be done in KIO, so that all users benefit.

How would you do it in KIO?

Add code to KFileDialog to allow specific protocols/slaves if the file scheme is supported.

I would guess something in the slave interface sort of like KDE-KIO-Protocols in json/.protocol files expect it would be about supported output scheme instead of input/handled.
Something like KDE-KIO-Output-Protocols
Then there would be an equivalent to KProtocolInfoFactory::findProtocol to get those, like KProtocolInfoFactory::findOutputProtocol
Basically ioslaves desktop file recentlyused trash and tags would have "file" set in there.

When I tested this, there was a very noticable delay (~10s) between starting the search and items appearing, so the busy indicator is IMO necessary.

In D8208#591931, @fazevedo wrote:

In D8208#591704, @ngraham wrote:

@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).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

Why trying to append 'copy' in the base name whith possible headaches while you could simply do something like 'Copy N#1 of /original file name/' ?

In D8208#591704, @ngraham wrote:

@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).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

IMO it should still be considered if it's the only one.

In D9875#583106, @pali wrote:

Is there anything else or something which blocks merging this change into upstream git repository?

This fixed the button label, but the menu itself is unsuable due to a black text on dark background: https://openqa.opensuse.org/tests/1110939#step/start_wayland_plasma5/21

I'm wondering whether this might not actually break the "qtchooser" variant - if binaries are in a Qt version specific dir, the path to qdbus would no longer exist after a Qt update without a rebuild of spectacle.

the actual name of the command is qdbus-qt<version> in the distro's Qt

In D25699#575278, @davidedmundson wrote:

Please don't link external sites (GitHub) in the committed message.

RE: Menu
There is nothing in QQC2::Button to add a menu

If we want that it would have to be a custom button subclass, rather than something we support in the style.

In D25856#575083, @ngraham wrote:

In D25856#575044, @fvogt wrote:

IMO this should be done in KIO, so that all users benefit.

How would you do it in KIO?

IMO this should be done in KIO, so that all users benefit.

The check for the prefix was added in bf1d1cc6b2ad37cb586f44b56fa2438ed3a5dbfc, while the control.flat one got added much earlier.

In D23384#572198, @ngraham wrote:

I just tested writing today, for files opened in 3rd-party apps that get the FUSE mount path. Results:
...

In D23384#571276, @ngraham wrote:

I'm afraid that even with that change, the issue is still present. I honestly don't think it would be the worst thing in the world if we always handed the kio-fuse paths to apps that don't use ioslaves.

In D23384#570830, @ngraham wrote:

In D23384#570735, @fvogt wrote:

Clicking a http link in my chat app now kiofuses it and then has the browser desperately try to open /run/user/1000/kio-fuse-bla/http/kde.org/ - it only gets the first character in the file, so I usually just see < for a HTML page

Ignoring the elephant in the room which is that this diff forces everything through mountUrl, that's the expected behavior with a plain HTTP URL as the size isn't known until the file is downloaded. So stat reports a size of 1 until the file is actually opened.
This is unavoidable, otherwise every ls would trigger a download of all files. If handling this better is important, HTTPProtocol::stat could use a HEAD request to get the Content-Length, but that doesn't work in all cases either.

Well, we need to fix this or else it's a very serious regression that breaks a huge part of the desktop. Opening links in a web browser is pretty basic functionality.

In D23384#570331, @ngraham wrote:

In D23384#570118, @fvogt wrote:

Please try both of the following:

Done. Here are the log files:

kio-fuse.log1 MBDownload

Clicking a http link in my chat app now kiofuses it and then has the browser desperately try to open /run/user/1000/kio-fuse-bla/http/kde.org/ - it only gets the first character in the file, so I usually just see < for a HTML page

Unfortunately the kio-fuse -d output is incomplete, probably because Qt was too smart and logged to the journal instead...
It's visible that there are multiple processes reading the file, maybe thumbnailing is in progress?
Can you try with thumbnails in dolphin disabled?

That happens because the .desktop file sets X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb:
https://code.videolan.org/videolan/vlc/blob/master/share/vlc.desktop.in#L124

I wonder whether the job duplication can just be ignored like this or whether there has to be a "virtual" unique id instead to be able to address duplicated jobs as well.
When cancelling a duplicated job with this patch, are both gone or just one of them?

Ugly...

AFAICT this breaks if LIBDIR != "lib". systemd only looks in /usr/lib AFAICT, so hardcoding to $prefix/lib/systemd might be better.

IMO this should be addressed outside of PBI instead:

• If a captive portal is detected, call CheckConnectivity with a higher frequency (I've never had any issues with this, actually)
• Instead of opening networkcheck.kde.org in the browser when clicking the "Log In" button, open a page which just closes itself

This would work, but why not just emit Seeked(m_position) in setPosition?