various fixes suggested by dfaure
Wed, Dec 11
Mon, Dec 9
Yep, still looking for primarily design input.
Sat, Dec 7
Tue, Dec 3
I haven't read everything in great detail... but...
Jonathan said our writer isn't ready for this sort of spotlight IIRC. @jriddell input?
Mon, Dec 2
Why do we need to mirror this dsoap-ws-discovery-client lib that seems to be copied from somewhere?
Fri, Nov 29
Tue, Nov 26
Mon, Nov 25
I'll see about adding some debug output for the daemon state. Hard to say why it's flakey with the info at hand.
Tue, Nov 19
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.
Mon, Nov 18
@broulik the children are handled by the other connections already (linedit, push button etc.)
Fri, Nov 15
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
Thu, Nov 14
- 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)
Wed, Nov 13
^ Plays into https://github.com/ximion/appstream/issues/240
Nov 11 2019
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).
Nov 9 2019
Nov 8 2019
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.
Nov 7 2019
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.
Nov 6 2019
D25170 for when that lands
NB: depends on https://gitlab.com/libssh/libssh-mirror/merge_requests/71 getting landed.
Nov 5 2019
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.
Oct 30 2019
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.
Oct 29 2019
switch from list to bool since we don't actually use the list anyway
Oct 28 2019
Oct 25 2019
About the list of unexpected signals in forCommand():
Oct 24 2019
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.