Remove unnecessary parentheses.

In T11627#218943, @meven wrote:

In T11627#206210, @broulik wrote:

I'm pretty sure there's a tonne of blocking DBus calls being done all over the place during file copy (checking for slaves on hold, updating kuiserver job tracking info, etc) which can cause apps to hang or slow down if whatever they're trying to call into is busy. Best example: SIGSTOP plasmashell, try copying a file in Dolphin, won't work until plasmashell SIGCONTs.

That's interesting, we need to fix that.

About https://bugs.kde.org/show_bug.cgi?id=281270 Inconsistent notifications during/after file operations (copying, moving, deleting, compressing, extracting) depending on amount of data/items involved :

A possible way to fix this would probably use sendfile with O_NONBLOCK + select.
After a non-blocking sendfile we call select/pselect on the dest file descriptor. Then when it returns something other than EWOULDBLOCK, we can deduce the processed bytes from the size sent to copy to dest (i.e sendfile count parameter) or use pselect and its sigset_t parameter. We then can call sendfile again to write next bytes.
On the plus side it would make the code async which would make progress reporting more reactive.

^ I can't reproduce that, the patch works as intended for me. (we should investigate this though)

LGTM, better wait for @dfaure opinion though

Maybe look at KConfigCompilerSignallingItem? But I don't see another way of doing it than a wrapper approach like KConfigCompilerSignallingItem does... but then that's why ManagedConfigModule assumes GenerateProperties=true in the kcfgc, otherwise we'd have hacked the compiler to do the same thing anyway just inconditionnally...

Not sure if we want it in this patch or later on, but wouldn't it be better to have Param::type and CfgEntry::type be of KConfigTypeInformation type? We would then convert early and avoid all those ctor calls to KConfigTypeInformation spread in the code. I suspect it'd improve readability.

And more while at it: for latin1 strings used in concatenation it is recommended to use QLatin1String and for single chars QLatin1Char. QStringLiteral is more expensive here, and QStringBuilder & QString has proper overloads for the concatenations. So you want to keep the QLatin1Strings and rather turn those for single chars to QLatin1Char.

In T12594#219121, @ngraham wrote:

Do you wanna submit a patch to breeze-icons?

In D26739#601921, @ngraham wrote:

In D26739#601762, @trmdi wrote:

Not yet looked at the code carefully, but I feel the top margin and the bottom one of the thumbnail are not identical.

With the latest iteration of the patch, they should be. Feel free to try it out for yourself!

Fixed wording

I updated the black versions so they don't have the possible blue edge artifact:
Source:

In T11835#219104, @adridg wrote:

The Krita showcase is a "maybe", since Boud isn't coming and Wolthera is a "maybe". The xrdesktop folks were asking if they could use a corner (well, enough space for their demo)

I'm not sure I like whitespace() returning the stream and then being used. In effect it leads to hiding the stream object making the code more terse indeed but less obvious I think.
Maybe it's a question of personal taste, @dfaure any opinion?

Network manager doesn't really fit visually with the other applets. How about slim it down too?

Thanks, I pushed it: https://invent.kde.org/websites/kate-editor-org/commit/de6b04a1b7d5c8432655c768eec57e545cfbb2b3

In T11835#219107, @jriddell wrote:

In T11835#219099, @paulb wrote:

Didn't @jriddell have the tablecloth we ordered for Edinburgh?

Yes I do

Do you wanna submit a patch to breeze-icons?

Magnificent!!!!!!!!

I've prepared a Breeze styled new Kate icon, and a high-contrast black new Kate icon. I hope they work:
https://www.dropbox.com/sh/kuxesqk27ml20x4/AABGAfpQdLQN8NuqAFx1Dx_Ga?dl=0

vk.com/@kde_ru-nedelya-19-01

VDG folks approved in the chatroom; landing it!

In T11835#219099, @paulb wrote:

Didn't @jriddell have the tablecloth we ordered for Edinburgh?

In D26968#602035, @ndavis wrote:

In D26968#602034, @niccolove wrote:

Okay! I'm installing Inkscape 1, for future patches. May I ask you to land this, as I don't have access rights?

Sure. Do you not have a KDE developer account?

In D26968#602034, @niccolove wrote:

Okay! I'm installing Inkscape 1, for future patches. May I ask you to land this, as I don't have access rights?

Okay! I'm installing Inkscape 1, for future patches. May I ask you to land this, as I don't have access rights?

Yes, GHNS now works for panon (in my PR). Thanks again!

Anyway, it works as it is, so don't worry about it.

In D26968#602031, @niccolove wrote:

In D26968#601998, @ndavis wrote:

You should remove the color field instead of using color:currentColor and fill:currentColor

I tried to do that, but for some reason the "color:#effeff" automatically appears again (in inkscape) :-/

In D26968#601998, @ndavis wrote:

You should remove the color field instead of using color:currentColor and fill:currentColor

+1, much nicer.

What I care about is that the margins are consistent and things are properly left-aligned by default. That is to say, nothing should have to override the default margins to have everything perfectly aligned.

The Krita showcase is a "maybe", since Boud isn't coming and Wolthera is a "maybe". The xrdesktop folks were asking if they could use a corner (well, enough space for their demo)

All fixed now?