various fixes suggested by dfaure

Yep, still looking for primarily design input.

I haven't read everything in great detail... but...

Jonathan said our writer isn't ready for this sort of spotlight IIRC. @jriddell input?

In D25682#570845, @davidedmundson wrote:

Why do we need to mirror this dsoap-ws-discovery-client lib that seems to be copied from somewhere?

I'll see about adding some debug output for the daemon state. Hard to say why it's flakey with the info at hand.

The arm setup actually disappeared since (possibly wasn't carried into new server) so there are no up to date metrics. It does not really matter though since we do not have a way to pull this off for amd64. We'd require a persistent storage for the cache as nodes are largely ephemeral so result need "offsite" storage. This would be tricky to do since we currently have no space for this and the actual transfer overhead would like destroy any gains made by the cache. Plus there is of course the risk of false positives anyway. All in all no longer viable to implement.

@broulik the children are handled by the other connections already (linedit, push button etc.)

This is starting to look really good. All functions will need documenting in the header of that file so they show up on api.kde.org, see other modules for examples.

some style complaints. Looks great other than that 👍

• remove all color mapping tech, it's pointless since the code now uses the system palette
• remove garbage foobar class
• remove unnecessary main.moc include
• create two global SystemPalettes instead of in individual items

• bump preview size a bit
• update documentation
• resolve outstanding todos

• document why section overlays aren't modelled
• doodad qml item creation is now type based rather than duck typed
• logo doodads are now supported as a compositie of shape doodads and labels
• outline doodads now behave correctly in that they only render an outline without fill (at least I think that's how they are meant to work)
• todo--

^ Plays into https://github.com/ximion/appstream/issues/240

OEM configuration is driven by installers already e.g. calamares https://people.ubuntu.com/~apachelogger/screencasts/vokoscreen-2019-05-03_11-43-36.mkv or ubiquity https://userbase.kde.org/Neon/Installation/OEM#First_Boot
Both aforementioned use cases are addressed by the same software using the same code. The "steps" can be different though (e.g. OEM config mostly needs no partitioning so this step is not part of it).

fix tooltip scaling to show keys at 2.5 times their original size

install bin, drop ki18n as link target (not used at this time)

We have distro-independent ways to refer to software (appstream ids) so software stores understand what we mean. So, there is no technical problem here. Heck, even without it there wouldn't be. Calamares manages to be a distro-independent installer that can be used by all distros and made their own. There is no reason we couldn't have the same for a first start experience.

Oh oh oh, I forgot to actually read this.

I figure we want maximum exposure for this. So, much like we do with Plasma already I would suggest that we post the announcement on kde.org AND copy it to the dot.

D25170 for when that lands

NB: depends on https://gitlab.com/libssh/libssh-mirror/merge_requests/71 getting landed.

In D25159#559016, @asn wrote:

We moved from a manually generated libssh-config.cmake to install(EXPORTS libssh-config) and it does things completely different.

I'm currently trying to fix it. However better don't apply this as ssh_shared will vanish as a target.

I wonder how I can define LIBSSH_LIBRARIES again with EXPORTS.

I think there's a smarter way of dealing with this somewhere in our finder, not blocking though. I'll take a look when I find a minute.

D25153 for reference.

TBH, I would move away from the hardcoding in general.... try to sendfile size_of_file and if n < size use n as new count for the next cycle. The second cycle will use the maximum regardless of what the specific kernel version has as maximum.
The maximum is an implementation detail of the kernel that may change every release, so hardcoding anything seems wrong here.

typo--

switch from list to bool since we don't actually use the list anyway

About the list of unexpected signals in forCommand():

Supposedly, I was being lazy though since there is no pre existing test and I don't exactly know if there's anything to watch out for when testing widgets (as in: I've never written a widget test before).

Hm, how about separate functions though? With a single stat any given build still needs N process forks even when they only want 1 value.

Oh it's gorgeous!

Not sure if that sort of application really needs to have regular commits ;)