In D15240#319850, @ngraham wrote:

This strikes me as likely to cause intense frustration. Consider the following dramatized dialogue between a user and the computer:

User: "Neat, I just set up this KDE plasma thing. Let's start seeing what cool stuff it can do!"
Computer: "Hey hey hey first what kind of KWallet do you want to create? Technical jargon thingy 1, or technical jargon thingy 2? Huh? Huh? What'll it be O noble user!?"
User: "Okay, I have no idea, let me cancel out of this stupid thing..."
Computer: "Don't worry I created a thing anyway and chose technical jargon thingy 1 for you!"

Speaking personally, this sort of experience would make me want to put my fist through the screen.

It might be worth stepping back and asking more higher-level questions like:
"Why are users cancelling the wizard? Is it too technically intimidating?"
"Should we even have a wizard at all? Maybe should we create a wallet automatically by default and let advanced users change its settings or delete it if they don't like it?"

Used KIO::FileSystemFreeSpaceJob

In D14895#310633, @broulik wrote:

Might not be an issue as you call setData anyway but just something I want you to keep in mind for testing.

In D14895#310633, @broulik wrote:

Also beware that bool SolidDeviceEngine::updateSourceEvent is currently supposed to return true

In D14895#310535, @davidedmundson wrote:

Thanks for looking into this.

Whilst this looks fine, we have a more standard abstraction layer for async IO via KIO.
There's a FileSystemFreeSpaceJob which should work here.

Removed useless debug string

ping?

In D14208#294601, @mlaurent wrote:

Do you have commit access ?

In D14064#291125, @broulik wrote:

I would rather see a thorough investigation on what this does and why it is or is not needed. There's a couple of slow runners that suffer issues because of premature resetting but I don't understand why it has this code in the first place.

This commit looks good and it works just as planned

UPD:
I found monitor combination that makes KScreen works: AOC(hdmi)-iiyama(D-SUB)
If I swap monitors, KSCeen doesn't work (noticed it past friday evening)

In D9506#193271, @sebas wrote:

Okay, patch as-is now definitely breaks unplugging outputs, it eats these events. I'll mark it as such, if you fix it in another way, either update this or create a new review.

Fix autotests build

I noticed that "shutdown" sequence is not the same as "standby" one.
Shutdown for secondary:
disconnect -> remove crtc -> connect -> assign crtc

In D9294#190033, @graesslin wrote:

I already did and my accepted still holds

@graesslin thanks for review.
Can you look at new version of KDecoration part requested by @cfeck ?

const QString &

const QString &
cleanup

In D9506#188239, @anthonyfieroni wrote:

@McPain can you provide some debug info from qCDebug(KSCREEN_XRANDR), i don't have multi screen setup but we can make better fix.

fix build

In D9506#188118, @sebas wrote:

And I'm not sure they should. There's a difference between a monitor going to sleep and a configuration change of a multi screen setup.

Can you please merge this quickly? I'd like to give it some real-world exposure, we can always revisit this patch if it turns out to cause more problems than it solves.

UPD:
As the secondary monitor switches off, windows on it doesn't move to the primary

Pass QString as "const QString &"
(noticed that after sending previous patch)

Removed "bool trap"

Removed "bool trap"

Remove accidently attached russian translation patch

Moved QToolTip::showText to KWin

One more question:

In D7246#171923, @graesslin wrote:

But long story short: for KWin the best is a request from KDecoration "showTooltip(const QString &)" and KWin creates the tooltip window, positions it and ensures it works correctly.

In D7246#158488, @ngraham wrote:

@McPain, any update?

In D7625#145828, @rahn wrote:

And backported to 17.08 branch. Does this patch require any more action?

Nothing but indentation (see 223-226 in patched source).
This wrong indentation is side effect for minimizing patch.

In D7625#145329, @rahn wrote:

Is it intentional that the feature pointers held in the tileList are used as a key multiple times (and therefore require an insertMulti())? Or should they be unique in the first place (and therefore the multiple usage of the key is only the symptom of a bug in a different place)?

AFAIK, One polygon on the map = one key.
Countries like Russia or Canada have more than one polygon. If keys are unique, you will see a little piece of country, not the whole one.
Same thing with highlighted countries.

Anybody?

In D7625#141862, @rahn wrote:

Being curious: Why is the insertMulti needed here? (maybe there should be a comment there - which would be nice in general given the common usage of auto here (which is fine) ).

You are using QHash.
insert() will replace items if any with specified key exists.
insertMulti() will simply add the new one without replacing recently added.

In D7451#140542, @davidedmundson wrote:

Do you have commit access?

In D7016#130691, @mlaurent wrote:

Thanks.
Could you commit it in 17.08 and using git merge for merging in master ?
thanks

Added autotests

How I can run autotests?