ping

livecd-rootfs changes now also in all branches pending ISO rebuilds and validation

Looks like that broke something... note the output at the bottom

Oh and since qml dependencies are spreading throughout the stack now it may actually be a good idea to reinvent the system and implement it as substvars ${qml:Depends}. To that end inspecting all modules installed by a package would be useful, alas, doing that technically has Qt tech but it's not available for external use! Namely qtcreator has a thing called (IIRC) qmljs which is meant to import models of all datatypes in modules, kdevelop has a fork of it as well. Unfortunately since it is not available from the outside it's probably still easier to have custom "finding" logic.

While that fixes the drkonqi bug just fine I am not sure that is the best fix for the problem. As I understand it KPasswordLineEdit doesn't set itself to StrongFocus, seeing as it is a replacement for QLineEdit that seems inconsistent and should be rectified though. IOW: I think KPasswordLineEdit should be changed to set a StrongFocus by default, same as QLineEdit.

setting server to keepalive=false? what is this? the 90's? :O

https://github.com/pangea-project/pangea-tooling/commit/68eede405590fe1de2910945368d16f6e49f2602

Heh, meanwhile I am not sure what to make of the current activity. It looks basically inactive for like a year or two now. The commits last year were more minor adjustments than anything. Plus it continues to be in playground with no apparent moves to change that. So... I am not sure this needs packaging at this time. If anything ... one should probably ask the author first if he has any plans to push it forwards towards production quality and extragear.

competing api design on commentsclient::getfrombug2

Is this blocked on something?

Huh, that is actually a bug in all KCM-related tech I'd imagine. They all handle help independently of kxmlgui and thus do not transparently fall back to resolve help via the web when khelpcenter isn't avialable.

redo diff so it maybe doesn't include nonesense

search now searches long description so only get somewhat pertinent bugs come back as results. also implement pagniation of results (ie. only 25 results at a time are queried, this is both much faster to query and to parse). boths somewhat reliant on undocumented features of the webservice api (they are however intentional features since they have explicit code in the webservice code)

I did a review. there honestly isn't much that sticks out

seems to be working. should there be problems in the next couple of days this change is probably why ;)

To add: the helper is called qmlimportscanner and generates a json blob of all modules inside a dir e.g. qmlimportscanner -rootPath . it may be compiled with qmlplugindump which introspects modules (which is more than we need unfortunately) e.g. qmlplugindump Qt.labs.folderlistmodexl 2.0.

Has overlap with T9388 see comment @ https://phabricator.kde.org/T9388#178663

You know, I feel like appstream can help us here. Certainly with the individual extragear apps. We could simply crawl all application appstream components we have packaged, then exclude all which aren't clearly KDE, then exclude all which are from a package that is in a release bundle and presto we have nice metadata to render into a website.

It's gorgeous!

ping

I'll put it on the record that I still think the "yo you wanna restart now" message should be at the top of the KCM and not inside the groupbox.

• repair dupe detection - was running on empty list
• refactor bug fetching to not include comment fetching and port all users of it
• stop holding all comments of all bugs in memory. we have no use for like 99% of them after parsing
• rebase on master

I think you lost the QML part of the diff.

XML broken.

I think it's bad practice to do blocking dbus calls.

I feel like this would be nicer a dbus interface class thingy.

Could this be a packaging problem in your distro?

I see code for this in tooling. Has this been resolved?

LGTM, but do we need the MMM there? Wouldn't one M do? Or if control.text is always a string we don't need the ""+ at all?

Following Kai's question... wouldn't KIconLoader::global make the entire static obsolete?

The sidepanel (which I guess is the mainview) gets the icon from InfoKcmModel::data from what I can tell. ::data and ::generateToolTipLine are the only places where I see ::icon get called. So what I am thinking is these changes:

I think this is the wrong TextField for SDDM/kscreenlocker actually. They use PlasmaComponents 2, which judging by my printf debugging isn't loading that particular TextField.qml.

That seems to break the category icons because KDE::icon(menuItem->kcm().icon() is only working on Kcm entries, while KcmCategory entries overload ::icon with divergent behavior.

lgtm