- User Since
- Sep 15 2015, 12:04 PM (226 w, 6 d)
Fri, Jan 17
Thanks for context though.
committing the latest working tree helps a lot -.-
Thu, Jan 16
remove extra file
split into one class per file
redesign finish system
Wed, Jan 15
+1 form me. not sure if @mpyne wants to have a look as well.
Revisit for 20.04 I guess. Not much worth putting effort into this now.
forgot to actually write cleanup after having wanted to twice :'D
Tue, Jan 14
not sure if it's worth splitting into multiple files. personally I prefer many tiny files over one long one though *shrug*.
Mh, I actually was lying it's documented on the setter https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html#a0167de5a0565e61e57e8f6ee7dcce71b :)
Mon, Jan 13
since there's not been much design input let's move to actual review
Sat, Jan 11
This should be added to the scm metadata and then picked up from there, not as an option on releaseme specifically as this isn't releaseme specific information.
That said I suppose it'd be best to actually extract this out of the source, but I am not sure there's an easy way to get that going without moving kaboutdata to cmake so metadata is likely the most reasonable thing to do :/
Tue, Jan 7
KF5's Qt support strategy is sound and so phonon should follow that. We've moved away from keeping phonon backwards compatible to the big bang, it's not sustainable.
I'd rather just bump the required version to 5.12.
I do wonder if maybe more granular return value handling of the smb truncate would be in order, but then I suppose the most relevant error is EACCES and that'd be handled at opening ¯\_(ツ)_/¯
Sat, Dec 21
Dec 15 2019
Dec 14 2019
Seems a bit meh to have a verbatim copy of the auto generated functions. Perhaps it'd be better to add an option to the ECM generator to export a loader function for use in plugins?
Then we could just call that from the plugin init instead of having to copy it.
Dec 11 2019
Dec 9 2019
various fixes suggested by dfaure
Yep, still looking for primarily design input.
Dec 7 2019
Dec 3 2019
I haven't read everything in great detail... but...
Jonathan said our writer isn't ready for this sort of spotlight IIRC. @jriddell input?
Dec 2 2019
Nov 29 2019
Nov 26 2019
Nov 25 2019
I'll see about adding some debug output for the daemon state. Hard to say why it's flakey with the info at hand.
Nov 19 2019
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.
Nov 18 2019
@broulik the children are handled by the other connections already (linedit, push button etc.)
Nov 15 2019
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
Nov 14 2019
- 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)
Nov 13 2019
^ 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).