Re: Unified internal communications channel

[Volker Krause]

On Donnerstag, 7. Dezember 2023 18:04:24 CET Carl Schwan wrote:
> On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote:
> > What I'm proposing is some kind of place that *only* has internal
> > announcements and is very log signal-to-noise such that we can
> > fearlessly recommend that *everybody* subscribe to it. In addition,
> > ideally those who want to subscribe via mailing list could do so, but
> > its content would automatically appear in other places too, such as
> > discuss.kde.org and an invent.kde.org project. That way people can
> > subscribe by whatever means is most comfortable to them.
> > 
> > Thoughts?
> 
> I fear this will just create a new source of information instead of unifying
> the source of information. We already have the following channels for
> announcements:
> 
> - planet.kde.org: contains release announcements, gear release schedule
> announcement from Albert as well as random development updates
> - kde-code-de...@kde.org: contains mostly news about new apps and modules
> - kde-de...@kde.org: contains the gear release schedule announcements and
> other technical announcements
> - plasma-devel@kde.org: contains important for plasma developers and the
> meeting notes of the monday chat meeting.
> - kde-commun...@kde.org contains general community (non technical)
> announcements
> 
> Adding a new channel that is either a mailing list, rss feed or a forum
> category won't help and will probably only makes it worse. It's also very
> difficult to defines that is an important internal news for the whole
> community is as it will be different for every subproject in KDE. The
> plasma logo discussion would have not been very relevant for any app
> developers. Similarly discussion about the new default database backend for
> Akonadi won't be interesting for Plasma developers but might be interesting
> for KMyMoney and other non-PIM apps using Akonadi.

Technically we do have a low-traffic channel for everyone even, kde-cvs-
announce. That one is even mandatory for people with contributor accounts 
AFAIK, you get added to that by default. However that is really only for 
things relevant for everyone, such as important infrastructure changes.

A topic like the one that triggered this discussion obviously doesn't qualify 
for that, that was mostly relevant for people involved in Plasma. So we'd need 
to clarify who we mean by "everybody" here, and I suspect that will be a 
subset of people varying from topic to topic. If so, one more channel is 
unlikely to magically fix things I think.

> Something that might help is merging the kde-core-devel and kde-devel
> mailing lists as those are very similar and should hopefully not be too
> complicated to do.

And/or kde-frameworks-devel, yes, we probably don't need all three of those 
anymore. While it might help a bit in finding appropriate channels to address 
the subset of people you want/need to reach it's somewhat orthogonal to Nate's 
proposal and would not have made any difference for the Plasma logo discussion 
I think.

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

Re: Frameworks 6 Branching

[Volker Krause]

On Montag, 19. Dezember 2022 15:39:07 CET Fusion Future wrote:
> On 2022/12/19 20:17, Volker Krause wrote:
> >  From that point on, KDE Frameworks 5 is considered feature-frozen,
> >  feature
> > 
> > work should continue to happen in the master branch, primarily targeting
> > KF6 then.
> 
> If I merge a merge request now in Frameworks group now, will the change
> exist in KF5.102, or KF6?

Until branching everything that goes into Frameworks master branch will end up 
both in the next KF5 and the first KF6 release.

signature.asc
Description: This is a digitally signed message part.

Frameworks 6 Branching

[Volker Krause]

Hello everyone (and sorry for the massive cross-posting),

we are nearing an important milestone in the KDE Frameworks 6 development, 
branching and thus splitting the development of KDE Frameworks 5 and 6.

Slightly behind the plan from Akademy this is currently scheduled for the first 
week of January.

>From that point on, KDE Frameworks 5 is considered feature-frozen, feature 
work should continue to happen in the master branch, primarily targeting KF6 
then. Bugfixes of course can and should be backported for quite some time to 
come, and KF5 releases will continue with the same pattern as previously. At 
some future point we might start to increase the interval between releases 
though, as the amount of changes decreases.

If you are using kdesrc-build all this should hopefully be transparent. Make 
sure to update to the latest version though and set already existing 6 builds 
to use the now existing "kf6-qt6" branch group.

On the CI we still have some work to do to keep the existing Qt 6 Plasma and 
application builds working after branching (as those essentially rely on a 
Qt6-based KF5, not a "proper" KF6), at least for a transitional period.

Despite all the careful planning and preparation it is quite possible that 
this will cause disruptions of some form though, two major versions of 
Frameworks at the same time is uncharted territory for our tooling.

If you have input or questions about this or want to help, the bi-weekly KF6 
meeting happening tomorrow at 17:00 CET in https://meet.kde.org/b/ada-mi8-aem 
would be a good place to discuss this. If you can't make it, adding your 
topics to the agenda 
(https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/22) is 
also an option. Email (kde-frameworks-devel) or chat 
(#kde-devel) work as well of course.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.

KF6 meeting notes 2022-04-26

[Volker Krause]

(cc-ing Plasma as well, as it's actually mostly about that this time)

https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/4

Remaining QDesktopWidget uses:
* KAccess:
- this is an accessibility feature for showing the X11 bell visually, from a 
separate program
- needs figuring out if we still need that -> ask on the kde-accessibility 
mailing list
- if yes, this probably should be in KWin instead, to also work with Wayland

* Color picking in kdeplasma-addons:
- there's a D-Bus API in KWin for this, would also fix the color picker on 
Wayland

* KWin, KScreenLocker:
- needed, needs porting to corresponding XCB code

Wayland Screencast interface build issues:
- this might be just a matter of renaming the xml file to the standard 
convention

Remaining KServiceTypeTrader uses:
- use for thumbnails/previews in plasma-desktop: needs convenience API to 
filter by mimetype, the new system doesn't have that anymore
- powerdevil: remove the use of plugins entirely, but there is a conflict risk 
with a huge open KConfigXT MR, maybe easier alternative: port to new plugin 
system now, leave the larger change for later
- KRunner needs to be ported away from KPluginMetaData::fromDesktopFile for 
bumping the deprecation level to 5.92 or above

Next meeting in two weeks:
https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/5

signature.asc
Description: This is a digitally signed message part.

Re: CI Repairs

[Volker Krause]

On Dienstag, 8. März 2022 08:54:38 CET Ben Cooksley wrote:
> This evening i've repaired several issues that were causing builds to fail
> on the main Jenkins CI system. This includes a broken Windows builder
> (causing Windows builds to periodically fail) and a hung FreeBSD builder
> (which was consuming half a CPU and preventing KWin CI jobs from completing)

Thank you! Would that also explain the problems we are seeing with the FreeBSD 
seed job?

> Replacement runs have been initiated for all projects.
> 
> So far all appears well, however a number of projects appear to have CI
> regressions on one or more platforms due to:
> - Use of exceptions (KMail)

For this I'm not finding an explanation, it started after a completely 
unrelated merge commit and the exception using code is in an Akonadi header 
that is used all over the place.

> - Use of an ECM version that does not exist (print-manager)

Fixed.

> - Use of C++ functionality that is not enabled (okular on Windows)

https://invent.kde.org/graphics/okular/-/merge_requests/582

> - Something to do with qobject_cast (akonadiconsole)

We had similar issues in other modules over the past two weeks or so due to 
the include install layout changes not being propagated fully yet. That's what 
made me initially look at the FreeBSD seed job.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.

Re: KEmoticons, emoticons kcm

[Volker Krause]

On Saturday, 23 May 2020 02:49:57 CEST Aleix Pol wrote:
> I was looking through some Plasma code and I saw that we have some
> fairly old emoticons KCM using KF5Emoticons.
> 
> Now while I know why this exists, it feels like it's more of a thing
> of the past from when people wrote :) instead of . While keeping it
> around for the few apps that might still use it (ktp? kopete?) could
> make sense, I'm afraid it's probably making it confusing for the users
> who expect this to actually allow them to customise their  but
> won't.
> 
> Do you think it would make sense to deprecate the framework and remove the
> KCM?

Absolutely! 

There's some discussion on this topic in https://phabricator.kde.org/T11585 
already. While direct usage of KEmoticons in applications is rare, there is a 
"backdoor dependency" via a KCoreAddons plug-in it provides.

Regards,
Volker

D29478: [Clipboard Plasmoid] Port to Prison QML import

[Volker Krause]

vkrause added a comment.


  Technically this looks fine from the Prison POV. Whether the barcode type 
selection makes sense beyond "because we can" I'm not sure about though (in 
particular the 1D codes seem to be of questionable use here), but then again 
that's not something introduced by this patch anyway.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D29478

To: broulik, #plasma, vkrause
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29268: [WIP] Add Date/Time dialog

[Volker Krause]

vkrause added a comment.


  There might be ways around the native function registration issue from the 
QML thread, e.g. by using the alternative approach of exported (mangled) 
symbols instead: 
https://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/design.html -> 
"Loading and Linking Native Methods".

REPOSITORY
  R1047 Kirigami Addons

REVISION DETAIL
  https://phabricator.kde.org/D29268

To: nicolasfella, davidedmundson, vkrause, broulik
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27595: Watch for language change events, and forward those to the QML engine

[Volker Krause]

vkrause added subscribers: broulik, davidedmundson.
vkrause added a comment.


  In D27595#636543 , @rikmills wrote:
  
  > git bisect also shows that this crashes the virtual desktop and regional 
settings KCM in Kubuntu 20.04
  
  
  I haven't seen a backtrace for this, but from what I understood from the chat 
backlog this is triggering a QML bug (?) due to the re-evaluation of qsTr() 
with 5.12, rather than actually crashing in the code of this patch? If so, I 
see three options:
  
  - ifdef the connect() call in initializeEngine() for Qt 5.12, breaking 
translations in that version only.
  - Replace this patch by the alternative approach proposed in D25984 
 for fixing translations, and see if that 
has less side effects.
  - Revert this entirely and break translations
  
  @mart @davidedmundson @broulik?

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D27595

To: vkrause, mart
Cc: davidedmundson, broulik, rikmills, ngraham, apol, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, ahiemstra, mart

D25984: Load translations

[Volker Krause]

vkrause added a comment.


  In D25984#589426 , @mart wrote:
  
  > ping, what's the current status of this?
  
  
  There's also https://phabricator.kde.org/D27595, which might address the 
same/a similar issue.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D25984

To: broulik, #kirigami, #frameworks, kossebau, aacid
Cc: vkrause, mart, davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra

D27595: Watch for language change events, and forward those to the QML engine

[Volker Krause]

vkrause added a comment.


  I can reproduce only if I set a valid translation catalog. Even more 
surprising since the affected dialog does not seem to contain any qsTr() 
translations.
  I don't think this patch is wrong as such, the layouting glitch is a bug 
elsewhere that we trigger by the retranslation (but that could be non-trivial 
to track down). If you need a quick workaround (at the expense of working qsTr 
translations), just comment the connect() call in initializeEngine().

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D27595

To: vkrause, mart
Cc: ngraham, apol, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ahiemstra, davidedmundson, mart

D27595: Watch for language change events, and forward those to the QML engine

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:9b7cae898ed7: Watch for language change events, and 
forward those to the QML engine (authored by vkrause).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27595?vs=76211=76478

REVISION DETAIL
  https://phabricator.kde.org/D27595

AFFECTED FILES
  src/kirigamiplugin.cpp
  src/kirigamiplugin.h

To: vkrause, mart
Cc: apol, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, 
ahiemstra, davidedmundson, mart, hein

D27525: Support Qt 5.14 on Android

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:8bf5b4675186: Support Qt 5.14 on Android (authored by 
vkrause).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27525?vs=76060=76477

REVISION DETAIL
  https://phabricator.kde.org/D27525

AFFECTED FILES
  src/kirigamiplugin.cpp
  src/kirigamiplugin.h

To: vkrause, mart
Cc: apol, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, 
ahiemstra, davidedmundson, mart, hein

D27595: Watch for language change events, and forward those to the QML engine

[Volker Krause]

vkrause added a comment.


  In D27595#616544 , @apol wrote:
  
  > I'm fine with this being done here for convenience, but it feels like it's 
something that should be in QQmlEngine itself.
  
  
  Right, or at least in QQmlApplicationEngine.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D27595

To: vkrause
Cc: apol, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, 
ahiemstra, davidedmundson, mart, hein

D27606: Remove usage of KDBusConnectionPool

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R161:fa5b3bb382ac: Remove usage of KDBusConnectionPool 
(authored by vkrause).

REPOSITORY
  R161 KActivity Manager Service

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27606?vs=76237=76248

REVISION DETAIL
  https://phabricator.kde.org/D27606

AFFECTED FILES
  src/service/Activities.cpp
  src/service/Application.cpp
  src/service/Features.cpp
  src/service/Resources.cpp
  src/service/ksmserver/KSMServer.cpp
  src/service/plugins/activitytemplates/TemplatesPlugin.cpp
  src/service/plugins/slc/SlcPlugin.cpp
  src/service/plugins/sqlite/ResourceLinking.cpp
  src/service/plugins/sqlite/StatsPlugin.cpp

To: vkrause, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27606: Remove usage of KDBusConnectionPool

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  As per T12722  this is no longer needed, 
QDBusConnection now behaves
  correctly in a multi-threaded scenario.

REPOSITORY
  R161 KActivity Manager Service

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27606

AFFECTED FILES
  src/service/Activities.cpp
  src/service/Application.cpp
  src/service/Features.cpp
  src/service/Resources.cpp
  src/service/ksmserver/KSMServer.cpp
  src/service/plugins/activitytemplates/TemplatesPlugin.cpp
  src/service/plugins/slc/SlcPlugin.cpp
  src/service/plugins/sqlite/ResourceLinking.cpp
  src/service/plugins/sqlite/StatsPlugin.cpp

To: vkrause
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27595: Watch for language change events, and forward those to the QML engine

[Volker Krause]

vkrause created this revision.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This fixes a race condition on startup for the Kirigami translation
  catalog that happens as follows:
  
  - QML code triggers the loading of the Kirigami plugin
  - the ECM QM loader is triggered, but since this is running outside of the
  
  main thread, the actual QM loading is deferred to the main thread
  
  - QML code execution continues, at which point qsTr might still return
  
  unstranslated strings
  
  This is for example visible by the "Actions" header in the context drawer
  of the main application page not getting translated.

REPOSITORY
  R169 Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27595

AFFECTED FILES
  src/kirigamiplugin.cpp
  src/kirigamiplugin.h

To: vkrause
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart, hein

D27525: Support Qt 5.14 on Android

[Volker Krause]

vkrause added a comment.


  In D27525#614905 , @apol wrote:
  
  > > Assets (QML files and icons) are no longer extracted into the file system,
  > >  but now are available in the android_rcc_bundle QRC file.
  >
  > Meaning that we now need to change all applications to put the resources on 
the rcc file?
  
  
  No, androiddeployqt does that on its own. So overall the apk still has 
exactly the same content, just the way to access it changed. It is possible 
apps make assumption about this, some of the frameworks definitely do.
  
  > The change upstream seems bonkers to me. Whatever, let's get this in. We'll 
possibly need to patch quite many apps for this... :(
  > 
  > Also feels quite weird how the commit message is twice the same text but it 
never says why it's done. 
https://codereview.qt-project.org/c/qt/qtbase/+/270573/24
  > 
  > ¯\_(ツ)_/¯
  
  It's avoiding duplicating the assets again in the file system, thus needing 
less space and significantly speeding up the first start. So while technically 
going in the right direction I would certainly have preferred to have this as 
something opt-in to not break all existing non-trivial code out there...

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D27525

To: vkrause
Cc: apol, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, 
ahiemstra, davidedmundson, mart, hein

D27525: Support Qt 5.14 on Android

[Volker Krause]

vkrause created this revision.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Assets (QML files and icons) are no longer extracted into the file system,
  but now are available in the android_rcc_bundle QRC file.
  
  This is based on Francis' work mentioned in D26749 
, but slightly adjusted
  to also fix icon loading as well.

REPOSITORY
  R169 Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27525

AFFECTED FILES
  src/kirigamiplugin.cpp
  src/kirigamiplugin.h

To: vkrause
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart, hein

D26072: Port away from KIconThemes

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R128:39ce0e82856e: Port away from KIconThemes (authored by 
vkrause).

REPOSITORY
  R128 User Manager

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26072?vs=71738=71745

REVISION DETAIL
  https://phabricator.kde.org/D26072

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/accountinfo.cpp
  src/lib/accountmodel.cpp
  src/usermanager.cpp

To: vkrause, apol
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26072: Port away from KIconThemes

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This was only using the deprecated IconSize() method.

REPOSITORY
  R128 User Manager

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D26072

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/accountinfo.cpp
  src/lib/accountmodel.cpp
  src/usermanager.cpp

To: vkrause
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: KF6 Sprint

[Volker Krause]

Hi,

we have a date and venue by now: November 22 - 24 at the MBition office in 
Berlin (Dovestraße 1, 10587 Berlin), that's right after the Qt Contributor 
Summit to reduce travel overhead a bit. Thanks to Eike and Agustin for making 
this possible!

Please subscribe to https://phabricator.kde.org/T11535 and indicate there if 
you are going to attend. And please encourage people not on the list yet that 
should be there to attend.

Help in organizing this is also still very much needed (e.g. finding 
accommodation and dealing with e.V. reimbursements), despite how this may look 
like, I'm just passing messages here ;-)

I'd also again encourage everyone to put topics and ideas for KF6 into the KF6 
workboard (https://phabricator.kde.org/project/board/310/query/all/), which 
will help to make the sprint as effective as possible.

Thanks,
Volker


On Sunday, 15 September 2019 13:14:28 CET Volker Krause wrote:
> Hi,
> 
> as you might have seen in David's summary of the KF6 BoF at Akademy
> (https://
> mail.kde.org/pipermail/kde-frameworks-devel/2019-September/093298.html),
> there's the idea to have a KF6 sprint, along the lines of the KF5 sprint we
> had in Randa a few years back, to determine what we actually want to
> achieve with KF6 beyond just porting to Qt6.
> 
> If you are interested please subscribe to https://phabricator.kde.org/T11535
> and indicate your interest to participate, as well as times that would work
> for you. I'm not just looking at the current KF5 contributors for this, but
> also those of you heavily using KF5.
> 
> If you are willing to help organize the sprint, please indicate so there
> too, help with that would be greatly appreciated (I'm not organizing this,
> I'm just writing this email because Albert asked me too ;-) ).
> 
> With Qt 6 planned for Nov 2020 we are probably looking at a 18-24 month time
> frame towards KF6, so it's time to get this going.
> 
> Regards,
> Volker



signature.asc
Description: This is a digitally signed message part.

D24603: Port away from deprecated KDELibs4Support

[Volker Krause]

vkrause accepted this revision.
vkrause added a comment.


  Thanks!

REPOSITORY
  R103 KMenu Editor

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D24603

To: ahmadsamir, mlaurent, vkrause
Cc: vkrause, plasma-devel, kde-frameworks-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D23821: Clean up a few deprecated headers, and make dependencies more explicit

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:6529788d5e07: Clean up a few deprecated headers, and make 
dependencies more explicit (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D23821?vs=65727=66314#toc

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23821?vs=65727=66314

REVISION DETAIL
  https://phabricator.kde.org/D23821

AFFECTED FILES
  kcms/componentchooser/CMakeLists.txt
  kcms/componentchooser/browserconfig_ui.ui
  kcms/componentchooser/componentchooserterminal.cpp
  kcms/componentchooser/componentconfig_ui.ui
  kcms/componentchooser/emailclientconfig_ui.ui
  kcms/cursortheme/CMakeLists.txt
  kcms/cursortheme/kcmcursortheme.cpp
  kcms/emoticons/CMakeLists.txt
  kcms/lookandfeel/CMakeLists.txt
  kcms/style/kcmstyle.cpp

To: vkrause, plasma-devel, sitter
Cc: LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D5961: PoC: Generic adoption of KUserFeedback for Discover

[Volker Krause]

vkrause added a comment.


  +1

INLINE COMMENTS

> DiscoverWindow.qml:71
> +surveyInterval: 30
> +feedbackServer: "http://localhost:8083/;
> +encouragementInterval: 30

https://telemetry.kde.org/

REPOSITORY
  R134 Discover Software Store

REVISION DETAIL
  https://phabricator.kde.org/D5961

To: apol, #plasma, vkrause
Cc: mart, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D24011: Provide a telemetrics kcm module for Plasma

[Volker Krause]

vkrause added a comment.


  In D24011#533038 , @broulik wrote:
  
  > Should we make it already a "Privacy" KCM just in case?
  
  
  I'm not convinced about that. "Privacy" is not something you need to enable 
(it's on by default), and it's not something we want to suggest you have to 
disable. "Telemetry" is quite technical and has some negative connotations, 
phrasing this positive along the lines of "Feedback", "Contribute Feedback", 
etc seems better to me.

INLINE COMMENTS

> CMakeLists.txt:2
>  add_subdirectory(translations)
> +add_subdirectory(feedback)

Needs to be conditional on KUserFeedback presence I guess?

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D24011

To: apol, #plasma, vkrause
Cc: ognarb, broulik, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

KF6 Sprint

[Volker Krause]

Hi,

as you might have seen in David's summary of the KF6 BoF at Akademy (https://
mail.kde.org/pipermail/kde-frameworks-devel/2019-September/093298.html), 
there's the idea to have a KF6 sprint, along the lines of the KF5 sprint we 
had in Randa a few years back, to determine what we actually want to achieve 
with KF6 beyond just porting to Qt6.

If you are interested please subscribe to https://phabricator.kde.org/T11535 
and indicate your interest to participate, as well as times that would work 
for you. I'm not just looking at the current KF5 contributors for this, but 
also those of you heavily using KF5.

If you are willing to help organize the sprint, please indicate so there too, 
help with that would be greatly appreciated (I'm not organizing this, I'm just 
writing this email because Albert asked me too ;-) ).

With Qt 6 planned for Nov 2020 we are probably looking at a 18-24 month time 
frame towards KF6, so it's time to get this going.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.

D23818: Port away from kdemacros.h

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R101:7f6ab9fe5b96: Port away from kdemacros.h (authored by 
vkrause).

REPOSITORY
  R101 KHotKeys

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23818?vs=65723=65774

REVISION DETAIL
  https://phabricator.kde.org/D23818

AFFECTED FILES
  libkhotkeysprivate/action_data/action_data_base.h
  libkhotkeysprivate/action_data/action_data_group.h
  libkhotkeysprivate/conditions/condition.h
  libkhotkeysprivate/conditions/conditions_list_base.h
  libkhotkeysprivate/conditions/conditions_visitor.h
  libkhotkeysprivate/conditions/existing_window_condition.h
  libkhotkeysprivate/daemon/daemon.h
  libkhotkeysprivate/khotkeysglobal.h
  libkhotkeysprivate/sound.h
  libkhotkeysprivate/soundrecorder.h
  libkhotkeysprivate/triggers/triggers.h
  libkhotkeysprivate/voicesignature.h
  libkhotkeysprivate/windows_handler.h
  libkhotkeysprivate/windows_helper/window_selection_interface.h

To: vkrause, plasma-devel, mlaurent
Cc: LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D23821: Clean up a few deprecated headers, and make dependencies more explicit

[Volker Krause]

vkrause created this revision.
vkrause added a reviewer: plasma-devel.
Herald added a project: Plasma.
vkrause requested review of this revision.

REVISION SUMMARY
  Side effect from trying to figure out what needs to be done for T11568 
.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23821

AFFECTED FILES
  kcms/componentchooser/CMakeLists.txt
  kcms/componentchooser/browserconfig_ui.ui
  kcms/componentchooser/componentchooser.cpp
  kcms/componentchooser/componentchooserterminal.cpp
  kcms/componentchooser/componentconfig_ui.ui
  kcms/componentchooser/emailclientconfig_ui.ui
  kcms/cursortheme/CMakeLists.txt
  kcms/cursortheme/kcmcursortheme.cpp
  kcms/emoticons/CMakeLists.txt
  kcms/hardware/joystick/joydevice.cpp
  kcms/lookandfeel/CMakeLists.txt
  kcms/style/kcmstyle.cpp

To: vkrause, plasma-devel
Cc: LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D23799: Get rid of khtml usage (kill classic mode)

[Volker Krause]

vkrause added a comment.


  In D23799#527953 , @ognarb wrote:
  
  > +1
  >  is there a task somewhere where we can track all the KDE projects still  
using khtml?
  
  
  T11542  tracks KHTML specifically, and 
it's part of the larger KF6 workboard for tracking other such legacy 
dependencies.

REPOSITORY
  R124 System Settings

REVISION DETAIL
  https://phabricator.kde.org/D23799

To: svuorela, vkrause, plasma-devel, #plasma
Cc: ognarb, ngraham, #plasma, GB_2, sitter, LeGast00n, The-Feren-OS-Dev, 
jraleigh, fbampaloukas, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D23818: Port away from kdemacros.h

[Volker Krause]

vkrause created this revision.
vkrause added a reviewer: plasma-devel.
Herald added a project: Plasma.
vkrause requested review of this revision.

REPOSITORY
  R101 KHotKeys

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23818

AFFECTED FILES
  libkhotkeysprivate/action_data/action_data_base.h
  libkhotkeysprivate/action_data/action_data_group.h
  libkhotkeysprivate/conditions/condition.h
  libkhotkeysprivate/conditions/conditions_list_base.h
  libkhotkeysprivate/conditions/conditions_visitor.h
  libkhotkeysprivate/conditions/existing_window_condition.h
  libkhotkeysprivate/daemon/daemon.h
  libkhotkeysprivate/khotkeysglobal.h
  libkhotkeysprivate/sound.h
  libkhotkeysprivate/soundrecorder.h
  libkhotkeysprivate/triggers/triggers.h
  libkhotkeysprivate/voicesignature.h
  libkhotkeysprivate/windows_handler.h
  libkhotkeysprivate/windows_helper/window_selection_interface.h

To: vkrause, plasma-devel
Cc: LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D23799: Get rid of khtml usage (kill classic mode)

[Volker Krause]

vkrause added a comment.


  +1

REPOSITORY
  R124 System Settings

REVISION DETAIL
  https://phabricator.kde.org/D23799

To: svuorela, vkrause, plasma-devel
Cc: sitter, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D23188: Fix supported OS attributes for api.kde.org

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:c67827d4274f: Fix supported OS attributes for api.kde.org 
(authored by vkrause).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23188?vs=63822=64058

REVISION DETAIL
  https://phabricator.kde.org/D23188

AFFECTED FILES
  metainfo.yaml

To: vkrause, #frameworks, apol
Cc: apol, plasma-devel, fbampaloukas, domson, dkardarakos, davidedmundson, 
mart, hein

D23188: Fix supported OS attributes for api.kde.org

[Volker Krause]

vkrause added inline comments.

INLINE COMMENTS

> apol wrote in metainfo.yaml:12
> Isn't it called macOS nowadays? Or is it a keyword we have that we'd need to 
> change elsewhere?

See commit message, yes. We'd need to change it everywhere in order to show up 
as a single "macOS" entry on api.kde.org. Alternatively we implement some form 
of OS normalization/mapping in kapidox.

IOW, this change improves the api.kde.org OS list from the current "Android | 
FreeBSD | Linux | MacOSX | Windows | iOS (maintainer needed) | macOS 
(maintainer needed)" to "Android | FreeBSD | Linux | MacOSX | Windows | iOS". 
Getting it to the ultimately correct "Android | FreeBSD | Linux | macOS | 
Windows | iOS" is a further change.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D23188

To: vkrause, #frameworks
Cc: apol, plasma-devel, fbampaloukas, domson, dkardarakos, davidedmundson, 
mart, hein

D23188: Fix supported OS attributes for api.kde.org

[Volker Krause]

vkrause created this revision.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Move the "maintainer needed" to a note, so it's not showing up globally
  for all modules. Also, change "macOS" back to "MacOSX" (despite technically
  being the right name), as every other module still uses MacOSX and thus
  using anything else essentially adds a new OS on api.kde.org, globally.

REPOSITORY
  R169 Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23188

AFFECTED FILES
  metainfo.yaml

To: vkrause
Cc: plasma-devel, fbampaloukas, domson, dkardarakos, apol, davidedmundson, 
mart, hein

Re: KInit - Current state and benchmarks

[Volker Krause]

Thanks for the very interesting and useful research!

On Monday, 17 June 2019 11:56:15 CEST David Edmundson wrote:
> From API.kde.org:
> >Using kdeinit to launch KDE applications makes starting a typical KDE
> >applications 2.5 times faster (100ms instead of 250ms on a P-III 500)
> Certainly sounds like a good thing.
> 
> ===The current State===
> 
> ==Plasma==
> * Apps launched from the plasma menu skip klauncher and therefore
> kinit. This was done due to the API for KRun blocking somewhere
> (Though I don't remember details)
> 
> This seems like something easily fixable if we tried.
> 
> * Processes launched on bootup (with the exception of kcminit,
> ksmserver and kded5) skip kinit. This was due to a deadlock in
> klauncher and ksmserver at the time when apps autostart moved from
> frameworks.
> 
> This deadlock is since resolved in my ksmserver splitting branches.
> 
> * But Plasma apps launched from the desktop do go through klauncher
> (and therefore kinit)! So we're not even consistent.
> 
> ==Apps==
> * The number of applications linking kinit properly under KF5 is in an
> equally sorry state.
> Dolphin does, but even core applications like Okular and Kate don't.
> 
> See
> $ find -name 'CMakeLists.txt' -print0 | xargs -0 grep
> 'kf5_add_kdeinit_executable'
> for a local list.
> 
> * It's also incompatible with flatpak/snaps/appimage, which is a rising
> trend

That might be solvable with making that a build option (and having a 
corresponding CMake macro to automate that) I guess?

> ==Other==
> Kinit is still also used for spawning KIO slaves.
> 
> ===Is it still useful?===
> We're not using it properly and we need to do something. Either fix it
> or start to phase it out officially.
> 
> Since the time of writing kinit Qt has changed a lot. linking has
> changed a bit. CPUs have changed a lot and Hard Disks have changed a
> lot.
> 
> So I wrote a benchmark tool to see if the initial speed boost claim is
> relevant: kde:scratch/davidedmundson/inittimer
> 
> My test does the following:
>  - creates a dummy (headless) wayland server
>  - spawns an app using either QProcess or sending a DBus message to
> KLauncher - times how long it takes for the first window to appear, timing
> the more important real world metric and one that includes all the
> factors.
> 
> Results:
> (Showing the median out of 5 runs on a mid range SSD desktop)
> 
> Dolphin QProcess: 348
> Dolphin Kinit: 332
> 
> KCalc   QProcess:  242
> KCalc   KInit: 232
> 
> Plasmoidviewer (patched) QProces: 622
> Plasmoidviewer (patched) KInit: 591
> 
> KWrite  QProcess: 391
> KWrite  Kinit: 390
> (unsurprisingly similar as kwrite does not have a kdeinit exec, I
> included it as it shows the others aren't false positives)

Which libraries are covered by this mechanism nowadays? The impact is of 
course bigger the more of the dependencies of the applications are already 
loaded. When this was developed this was a small amount of relatively large Qt 
and kdelibs libraries. I'm wondering if the current subset is still relevant, 
both from Qt (e.g. thinking about QML/Qt Quick) and KF5?

> ===What about memory?===
> 
> Good question. It needs a similar investigation by someone who
> understands memory...

Regarding memory impact, I think a good first approximation is the sum of the 
sizes of the .data.rel.ro sections in all covered libraries. Those are 
allocated, written to once (for relocating information), and can then be 
shared. There can be more, but this covers vtables, QMetaObject data, etc, ie. 
stuff we tend to have a lot of. Order of magnitude is QtCore 40kB, QtGui 50kB, 
QtQml 100kB, QtDeclarative 140kB, QtWidgets 170kB. I vaguely recall this to be 
much larger in some (binary) graphics drivers, not sure if that's still the 
case though.

Hm, something that might also be worth looking into is if we can load kinit 
with the equivalent of RTLD_NOW in dlopen, so that all .got section entries 
are resolved already (making those sections fully shareable as well), and more 
importantly avoiding the symbol lookup to be done on-demand multiple times. 
Not sure if that's worth it on desktop, but for Plasma Mobile this could be 
relevant. That would probably be also my general conclusion for the entire 
topic.

Regards,
Volker

> ===Conclusion===
> 
> My test implies there /is/ a genuine saving with kinit !
> However it's far from the claimed 2.5 times faster, it is less than
> 1.1 times faster. Saving up to 30ms.



signature.asc
Description: This is a digitally signed message part.

D21399: Compress color changes without a QTimer

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:e5a6ac33f787: Compress color changes without a QTimer 
(authored by vkrause).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21399?vs=58644=58679

REVISION DETAIL
  https://phabricator.kde.org/D21399

AFFECTED FILES
  src/libkirigami/platformtheme.cpp

To: vkrause, apol
Cc: apol, plasma-devel, domson, dkardarakos, davidedmundson, mart, hein

D21399: Compress color changes without a QTimer

[Volker Krause]

vkrause created this revision.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This class exists in large quantities, so this avoids creating hundreds of
  QTimer instances just for the signal compression.

REPOSITORY
  R169 Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D21399

AFFECTED FILES
  src/libkirigami/platformtheme.cpp

To: vkrause
Cc: plasma-devel, domson, dkardarakos, apol, davidedmundson, mart, hein

D20132: Actually make the network list view show up

[Volker Krause]

vkrause added a comment.


  Maybe that's the relevant difference already, I have only been testing within 
plasma-settings, need to retest with kcmshell directly.

REPOSITORY
  R116 Plasma Network Management Applet

REVISION DETAIL
  https://phabricator.kde.org/D20132

To: vkrause, jgrulich
Cc: mart, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

D20132: Actually make the network list view show up

[Volker Krause]

vkrause added a comment.


  With that the network list had 0 width and was thus invisible for me, both on 
desktop and on yocto/rpi, using Qt 5.11 and latest Kirigami.

REPOSITORY
  R116 Plasma Network Management Applet

REVISION DETAIL
  https://phabricator.kde.org/D20132

To: vkrause, jgrulich
Cc: mart, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

Re: CI system maintainability

[Volker Krause]

On Friday, 29 March 2019 20:54:54 CET Ben Cooksley wrote:
> On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl
> > I fear that a mandatory reviews would add too juch strain on smaller
> > teams. If there's just one person with an intimate knowledge of the
> > code-base, plus two co-developers, then who should do the reviews?
> > 
> > How about a distinction based on importance of a project instead? I.e.
> > mandatory reviews for frameworks and any app that wants to be included in
> > KDE apps releases. Non-mandatory reviews can then also come with a
> > "price" to pay: if CI errors are not dealt with in a timely manner, you
> > should be free to disable the CI for administrative reasons...
> While this does seem like a nice solution, unfortunately for many
> repositories it isn't a case of disabling CI coverage for it, but also
> CI coverage for everything that depends on it. In the case of
> KContacts, this would also impact on parts of Extragear and Calligra
> (who depending on their exact requirements would either lose a
> dependency being available, or lose all of their CI coverage).
> 
> This is why i've not pursued this as an option in the past, because
> it's not fair on other projects that don't have anything to do with
> another project aside from being a user of it's interfaces to lose
> their coverage, simply because the project they depend on is broken.

I agree that anything on the CI level would be merely a workaround for this at 
best. I'd rather suggest we address this at the source by turning the 
externally used modules into frameworks. We did that last year already for 
KHolidays and Syndication who were used by Plasma among others. KContacts, 
KCalCore and KMime should follow that next IMHO.

The next time window to do that relatively painlessly is coming up after the 
19.04 applications release I think, and all of those have been part of the 
KDE4-era kdepimlibs module that complied with KF5-like ABI guarantees, so the 
necessary work should be limited hopefully. Extra review of the public 
interfaces would certainly help with making this happen I think.

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

Re: CI system maintainability

[Volker Krause]

On Friday, 29 March 2019 08:59:59 CET Kevin Ottens wrote:
> On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote:
> > Having mandatory reviews for a central and complex component like akonadi
> > looks like a very good and obvious idea.
> 
> Yep.

Looking at the 18.12 -> 19.04 timeframe the majority of changes to Akonadi 
went through pre-commit review, even more so if you discard commits doing 
release work (version bumps etc) or similar maintenance not touching the 
actual logic.

And specifically the changes that caused us the most headaches due to 
introducing a nasty regression went through review.

Sure, nothing is perfect, but I don't think code review in Akonadi is the most 
pressing issue here.
 
> > OTOH if there is only one developer who is really expert for akonadi, this
> > makes it kind of unfeasible.
> 
> That's the chicken and egg problem we're in concerning KDEPIM. The developer
> story is frankly really harder than most software out there which makes it
> unlikely for people to pick it over something else for contributions.
> That's in part tied to your next point below and partly tied to
> documentation, on- boarding etc. The unwillingness to be slowed down is
> getting in the way of fixing that situation: to be a desirable project to
> contribute to you need to spend time advocating, documenting and taking
> newbies by the hand until they become regular contributors.
> 
> Yes it's tough, and TBH I'm guilty of not doing this more on my own
> projects. But on such a strategic piece of software like KDEPIM there's
> some responsibility in carrying those duties for the well being of the
> project.

How to address the issue of bus factor ~1 components in PIM is the real 
question here, I completely agree. But this is getting way off topic from 
Ben's original issue, and for the wide range of recipients. 

Also, I don't think overly generic statements on that help us much, so maybe 
let's discuss concrete steps for this at the sprint next week?

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

Re: CI system maintainability

[Volker Krause]

On Thursday, 28 March 2019 16:11:12 CET Friedrich W. H. Kossebau wrote:
> Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> > For example I works all days on kde (pim or other) when I wake up, or at
> > noon after my lunch or the evening, I will not wait several days for a
> > review because nobody has time to do it.
> > 
> > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't
> > want to wait several days/weeks until someone wants to review my patchs)
> 
> Something might be lost in translation here, do you think, because you work
> daily on code of KDE projects, and other people (so potential reviewers) do
> not, this is an argument to do instant pushes of unreviewed commits?
> 
> While I understand one can get impatient if not getting instant review of
> changes one would like to depend on with further changes (I know this well
> :) ), still this seems a flawed argument at least for
> part-time-contributors based KDE projects, where the people one co-operates
> with only have time now and then, like once per week. It could be seen
> unfair & ignorant to them if one simply ignores their opinion, because one
> has more time reserved/ available.

I don't think any of that was meant here. The scenario that Laurent has in 
mind I think, and that I'm facing too, is that putting up a few dozen patches 
a week in a single repository for review and then having to wait for the 
review timeout because there's nobody else working on it is not even remotely 
practical, let alone with the current toolset of arc/phab.

> Not sure where this is from, but often I have seen an unwritten policy
> applied where people for a patch uploaded for review after one week of no
> response add a ping and then wait another week, before finally pushing the
> change. To me this seems a fair and reasonable policy, only ignores people
> who are on vacation for some more weeks or otherwise inactive, but I have
> not seen that ever been a real issue.

This works fine if you have less than a handful of patches in a single repo, 
and people actually review things. And we make plenty of use of that:
https://phabricator.kde.org/people/revisions/196/
https://phabricator.kde.org/people/revisions/208/

In fact I was just criticized last weekend at the privacy sprint for sending 
too many reviews ;-)

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.

Re: CI system maintainability

[Volker Krause]

On Thursday, 28 March 2019 16:32:34 CET Luca Beltrame wrote:
> In data giovedì 28 marzo 2019 15:15:23 CET, Nate Graham ha scritto:
> > In this case, it seems like the problem is that there are certain
> > individuals or teams that are pushing risky, breaking changes without code
> > review, and then ignoring failures in the CI. I think we might do well to
> > try to answer the question of why that's happening before we create a new
> > rule aimed at stopping it.

That "risky breaking change" was a 5 line fix for a Qt 5.13 build issue that 
had been successfully deployed to multiple repos before. The failure was also 
not ignored but noticed and fixed within about an hour, just not in all 
affected branches.

> Well put. Review or not review, clearly something in the process has failed,
> and I suspect "friction" rather than actual bad-faith ignorance of the CI
> results.
> 
> So, perhaps to force myself out of the bikeshedding (mea culpa) on reviews,
> I'll steal Friedrich's points from another mail and put them here
> synthetically:
> 
> - Why are the CI mails ignored / filtered? Too many, hard to parse,
> difficult to interpret?
> - What can be done to have people look at them and make sure they don't
> overlook breakage?
> 
> At least for the second point, as I mentioned earlier in the thread,
> probably having the committer being mailed in case of failure (GitLab does
> this IIRC) might be better than just on the mailing list. The second
> approach is what we use in openSUSE, where I usually don't subscribe to
> failure notifications (almost 300 packages is overkill) but a bot starts
> pestering me with mails the moment build failures go unfixed (granted, the
> time scale is different).
> 
> For the first, I'd like people more involved in the development to say their
> word.

See my earlier mail in this thread on how this slipped through for me.

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

Re: CI system maintainability

[Volker Krause]

On Thursday, 28 March 2019 09:50:47 CET Kevin Ottens wrote:
> Hello,
> 
> On Thursday, 28 March 2019 09:41:29 CET Luca Beltrame wrote:
> > In data giovedì 28 marzo 2019 09:29:22 CET, Kevin Ottens ha scritto:
> > > at your screen or pair with you" in the past. Clearly this compromise
> > > gets
> > > somewhat exploited and that's especially bad in the case of a fragile
> > > and
> > > central component like KDE PIM.
> > 
> > I'm not sure I agree. I can't speak for seasoned developers, but I've
> > found
> > myself in a situation (more than once) where the fix is trivial (compile
> > error, missing ";", etc) and being forced to go through review would (IMO)
> > unnecessarily raise friction.
> 
> I don't fully disagree with this (although I'd have stories on nefarious
> typos even for what was supposed to be a "trivial fix"). But it becomes a
> question of trade-off, IOW "how hurtful to the project mandatory reviews?"
> vs "how hurtful to the project a central component being very regularly
> broken?".
> 
> I'd argue we're loosing more with the current state of PIM than we'd loose
> with mandatory reviews.

Review all relevant changes is nice in theory, but for this to work you need 
at least two people spending comparable amount of time on this. I wish we had 
that luxury in KDE PIM.

It works to some extend for Akonadi between Dan and David, I don't see it 
working for Laurent on KMail or for me on KItinerary, there's simply not 
enough review bandwidth there.

Also, when looking at such drastic changes we should keep in mind the amount 
of changes that go in without trouble. There's always the risk of breakage 
when we change stuff with the best intentions of improving things, we need to 
deal with that no matter how many people review a change (see the nasty 
transaction lock regression in 18.12.x Akonadi).

What failed in this specific case is not the lack of review IMHO, I'm not sure 
I would have spotted the issue from the diff. It's also not that nobody cared, 
or that people ignored the issue. The underlying problem was fixed within 62 
minutes of its occurrence according to the Git log, it was however forgotten 
to push this to the 19.04 branch.

This resulted in a single build failure in the stable build for kcontacts, 
which I (and I guess others too) did not immediately act on. That does not 
mean it's being ignored, but for a change I did not do myself the overwhelming 
majority of failures is transient (as either the author fixes it upon being 
notified, or it's a dependency issue that will resolve itself with the next 
build).

That single build failure resulted in the dependent builds failing, which 
again I did not immediately act on as the error message made me believe it's 
the a dependency issue that will resolve itself. Combined with the fact that 
this is in the stable branch, which is less active than master, I had indeed 
not realized we have a persistent issue here that nobody else felt responsible 
for until I saw this email. At that point Laurent had already fixed it btw, 
which was a matter of a simple cherry-pick from master. If I missed other 
earlier communication about this somehow, I apologize of course.

So, yes, things went wrong and it's a valid question how to improve this going 
forward. But rather than questioning the usefulness of the CI or the entire 
development workflow, how about just simply pinging the people who feel 
responsible for the affected repos? It's not like we miss every single build 
issue after all. I simply might not always manage to keep the state of 120+ 
repos in various configurations in my head, and which of those needs most 
urgent attention (I for example broke half of binary factory's Android builds 
with a kpackage change recently, despite review, and yet have to find the time 
for a proper fix for that).

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

D20014: Update URLs to use https

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R134:428f4171c494: Update URLs to use https (authored by 
vkrause).

REPOSITORY
  R134 Discover Software Store

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20014?vs=54654=54795

REVISION DETAIL
  https://phabricator.kde.org/D20014

AFFECTED FILES
  CMakeLists.txt
  COPYING
  libdiscover/backends/CMakeLists.txt
  libdiscover/backends/DummyBackend/DummyResource.cpp
  
libdiscover/backends/KNSBackend/custom/discover_ktexteditor_codesnippets_core.knsrc

To: vkrause, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D20014: Update URLs to use https

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Also update one URL that no longer works.

REPOSITORY
  R134 Discover Software Store

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D20014

AFFECTED FILES
  CMakeLists.txt
  COPYING
  libdiscover/backends/CMakeLists.txt
  libdiscover/backends/DummyBackend/DummyResource.cpp
  
libdiscover/backends/KNSBackend/custom/discover_ktexteditor_codesnippets_core.knsrc

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19995: Change URLs to https where possible

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:fc6cdb161516: Change URLs to https where possible 
(authored by vkrause).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19995?vs=54610=54624

REVISION DETAIL
  https://phabricator.kde.org/D19995

AFFECTED FILES
  CMakeLists.txt
  HACKING
  applets/icontasks/metadata.desktop
  applets/kickoff/package/metadata.desktop
  applets/taskmanager/package/metadata.desktop
  attica-kde/kdeplugin/kdeplatformdependent.cpp
  doc/kcontrol/keyboard/index.docbook
  doc/kcontrol/spellchecking/index.docbook
  doc/kcontrol/splashscreen/index.docbook
  imports/activitymanager/CMakeLists.txt
  kcms/CMakeLists.txt
  kcms/emoticons/emoticonslist.ui
  kcms/kfontinst/CMakeLists.txt
  kcms/kfontinst/viewpart/download-unicode-files.sh
  knetattach/main.cpp

To: vkrause, yurchor
Cc: yurchor, plasma-devel, kde-doc-english, jraleigh, gennad, GB_2, ragreen, 
Pitel, ZrenBot, skadinna, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19997: Change http URLs to https

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R845:a73e803a39f3: Change http URLs to https (authored by 
vkrause).

REPOSITORY
  R845 Plasma Vault

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19997?vs=54616=54623

REVISION DETAIL
  https://phabricator.kde.org/D19997

AFFECTED FILES
  kded/ui/vaultcreationwizard.cpp
  plasma/package/metadata.desktop

To: vkrause, ivan
Cc: ivan, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19997: Change http URLs to https

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R845 Plasma Vault

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19997

AFFECTED FILES
  kded/ui/vaultcreationwizard.cpp
  plasma/package/metadata.desktop

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19995: Change URLs to https where possible

[Volker Krause]

vkrause created this revision.
Herald added projects: Plasma, Documentation.
Herald added subscribers: kde-doc-english, plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Also, update a few outdated or redirecting URLs.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19995

AFFECTED FILES
  CMakeLists.txt
  HACKING
  applets/icontasks/metadata.desktop
  applets/kickoff/package/metadata.desktop
  applets/taskmanager/package/metadata.desktop
  attica-kde/kdeplugin/kdeplatformdependent.cpp
  doc/kcontrol/keyboard/index.docbook
  doc/kcontrol/spellchecking/index.docbook
  doc/kcontrol/splashscreen/index.docbook
  imports/activitymanager/CMakeLists.txt
  kcms/CMakeLists.txt
  kcms/emoticons/emoticonslist.ui
  kcms/kfontinst/CMakeLists.txt
  kcms/kfontinst/viewpart/download-unicode-files.sh
  knetattach/main.cpp

To: vkrause
Cc: plasma-devel, kde-doc-english, jraleigh, gennad, GB_2, ragreen, Pitel, 
ZrenBot, skadinna, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D19894: Use https for links in the UI

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R871:f6eb9ba3dd92: Use https for links in the UI (authored by 
vkrause).

REPOSITORY
  R871 DrKonqi

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19894?vs=54355=54432

REVISION DETAIL
  https://phabricator.kde.org/D19894

AFFECTED FILES
  src/aboutbugreportingdialog.cpp
  src/bugzillaintegration/reportassistantpages_base.cpp

To: vkrause, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19894: Use https for links in the UI

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R871 DrKonqi

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19894

AFFECTED FILES
  src/aboutbugreportingdialog.cpp
  src/bugzillaintegration/reportassistantpages_base.cpp

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19465: Port to ECM's component/imported target based FindXCB

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:8c28ac839ad5: Port to ECMs component/imported 
target based FindXCB (authored by vkrause).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19465?vs=52948=53158

REVISION DETAIL
  https://phabricator.kde.org/D19465

AFFECTED FILES
  kcms/touchpad/cmake/modules/COPYING-CMAKE-SCRIPTS
  kcms/touchpad/cmake/modules/FindXCB.cmake
  kcms/touchpad/src/backends/x11.cmake

To: vkrause, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19463: Use FindGLIB2 from ECM

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R115:0b1559c47c3a: Use FindGLIB2 from ECM (authored by 
vkrause).

REPOSITORY
  R115 Plasma Audio Volume Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19463?vs=52944=53157

REVISION DETAIL
  https://phabricator.kde.org/D19463

AFFECTED FILES
  cmake/FindGLIB2.cmake

To: vkrause, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19465: Port to ECM's component/imported target based FindXCB

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19465

AFFECTED FILES
  kcms/touchpad/cmake/modules/COPYING-CMAKE-SCRIPTS
  kcms/touchpad/cmake/modules/FindXCB.cmake
  kcms/touchpad/src/backends/x11.cmake

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19463: Use FindGLIB2 from ECM

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R115 Plasma Audio Volume Applet

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19463

AFFECTED FILES
  cmake/FindGLIB2.cmake

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19247: Replace outdated FindX11_XCB copy with ECM and imported targets

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:45d35e88b3cd: Replace outdated FindX11_XCB copy with ECM 
and imported targets (authored by vkrause).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19247?vs=52368=52429

REVISION DETAIL
  https://phabricator.kde.org/D19247

AFFECTED FILES
  kcms/touchpad/cmake/modules/FindX11_XCB.cmake
  kcms/touchpad/src/backends/x11.cmake

To: vkrause, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19244: Remove outdated FindGLIB2 copy

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:f88abed5581f: Remove outdated FindGLIB2 copy (authored by 
vkrause).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19244?vs=52365=52428

REVISION DETAIL
  https://phabricator.kde.org/D19244

AFFECTED FILES
  applets/kimpanel/backend/ibus/CMakeLists.txt
  applets/kimpanel/cmake/FindGLIB2.cmake

To: vkrause, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19247: Replace outdated FindX11_XCB copy with ECM and imported targets

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19247

AFFECTED FILES
  kcms/touchpad/cmake/modules/FindX11_XCB.cmake
  kcms/touchpad/src/backends/x11.cmake

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19244: Remove outdated FindGLIB2 copy

[Volker Krause]

vkrause created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This is provided by ECM nowadays, with proper imported targets.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19244

AFFECTED FILES
  applets/kimpanel/backend/ibus/CMakeLists.txt
  applets/kimpanel/cmake/FindGLIB2.cmake

To: vkrause
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D17079: Provide a qqc2/kirigami-based about page

[Volker Krause]

vkrause added a comment.


  In D17079#364308 , @mart wrote:
  
  > In D17079#364263 , @apol wrote:
  >
  > > In D17079#364163 , @ltoscano 
wrote:
  > >
  > > > kcoreaddons is tier1 just like kirigami. Why not create a new 
Frameworks, kirigami-addons (or another appropriate name), which would collect 
all the common UI items which depends on other frameworks? Basically the 
kxmlgui of Kirigami.
  > >
  > >
  > > I think an external framework is a big overkill. In this case, it's only 
runtime dependencies so both either kcoreaddons or kirigami could offer it. I 
would favor putting it in kirigami because there's the duck-typing opportunity 
there too, but it may be a stretch.
  > >  That said, we'll need someone to register the KAbout* types somewhere 
too, but we can also rely on applications doing that as a first iteration.
  >
  >
  > one thing i'm a bit concerned is kirigami becomeing too much of a QML 
kdelibs monolith :p
  
  
  This came up when discussing date/time input widgets at Akademy as well. The 
idea there was also to have tier2 framework ("kirigami-addons") for this kind 
of stuff. Ie. higher-level controls that depend on Kirigami and possibly other 
tier1 frameworks, but unlike kdeclarative doesn't pull in QtWidgets as a 
dependency. So this wouldn't be just for the about page, but seems of much 
broader use.

REPOSITORY
  R134 Discover Software Store

REVISION DETAIL
  https://phabricator.kde.org/D17079

To: apol, #plasma, #frameworks
Cc: vkrause, mart, leinir, ngraham, ltoscano, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D14976: Less aggessive monochroming of icons

[Volker Krause]

vkrause added a comment.


  Thanks! This looks like it should fix my problem with the breeze weather 
icons on Android :)

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D14976

To: mart, #kirigami, vkrause
Cc: plasma-devel, apol, davidedmundson, mart, hein

D13874: textplugin: Fix missing QTextStream include

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R112:6b2036cb8a1d: textplugin: Fix missing QTextStream include 
(authored by alistairf, committed by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13874?vs=37123=37982#toc

REPOSITORY
  R112 Milou

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13874?vs=37123=37982

REVISION DETAIL
  https://phabricator.kde.org/D13874

AFFECTED FILES
  lib/previews/textplugin.cpp

To: alistairf, kossebau
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D14129: Port away from string-based connects

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R858:e1ccdc1d7698: Port away from string-based connects 
(authored by vkrause).

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14129?vs=37793=37891

REVISION DETAIL
  https://phabricator.kde.org/D14129

AFFECTED FILES
  plugin/kquickstyleitem.cpp

To: vkrause, apol
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D14129: Port away from string-based connects

[Volker Krause]

vkrause created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Due to the large amount of connections here, multiplied by the not exactly
  small amount of instances even in simple applications, the allocations of
  the string operations actually become relevant. Function pointer connects
  also allocate, but only about 1/3 of the string-based ones.

TEST PLAN
  One scroll through the KDE Itinerary timeline with a large test data set 
loaded,
  measured in heaptrack. Removed 60k/2.5% (temporary) string allocations.

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D14129

AFFECTED FILES
  plugin/kquickstyleitem.cpp

To: vkrause
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13932: Show icons for actions that have an icon source rather than an icon name

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:1454366a2e33: Show icons for actions that have an icon 
source rather than an icon name (authored by vkrause).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13932?vs=37289=37511

REVISION DETAIL
  https://phabricator.kde.org/D13932

AFFECTED FILES
  src/controls/BasicListItem.qml

To: vkrause, mart
Cc: plasma-devel, apol, davidedmundson, mart, hein

D13932: Show icons for actions that have an icon source rather than an icon name

[Volker Krause]

vkrause created this revision.
Restricted Application added a project: Kirigami.
Restricted Application added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R169 Kirigami

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13932

AFFECTED FILES
  src/controls/BasicListItem.qml

To: vkrause
Cc: plasma-devel, apol, davidedmundson, mart, hein

D13811: Add license files

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R97:c9e283a7f14f: Add license files (authored by vkrause).

REPOSITORY
  R97 Bluedevil

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13811?vs=36942=36957

REVISION DETAIL
  https://phabricator.kde.org/D13811

AFFECTED FILES
  COPYING
  COPYING.LIB

To: vkrause, #plasma, apol
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13811: Add license files

[Volker Krause]

vkrause created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Yocto's license check complains if those are missing.

REPOSITORY
  R97 Bluedevil

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13811

AFFECTED FILES
  COPYING
  COPYING.LIB

To: vkrause
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D10560: [Clipboard plasmoid] Support Aztec barcode

[Volker Krause]

vkrause added a comment.


  looks good to me

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D10560

To: broulik, #plasma, graesslin, vkrause
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9991: Remove unnecessary dependency on QtScript

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R112:684a95a6ef0b: Remove unnecessary dependency on QtScript 
(authored by vkrause).

REPOSITORY
  R112 Milou

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9991?vs=25682=25683

REVISION DETAIL
  https://phabricator.kde.org/D9991

AFFECTED FILES
  CMakeLists.txt

To: vkrause, #plasma, bshah
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D9991: Remove unnecessary dependency on QtScript

[Volker Krause]

vkrause created this revision.
vkrause added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
vkrause requested review of this revision.

REPOSITORY
  R112 Milou

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9991

AFFECTED FILES
  CMakeLists.txt

To: vkrause, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

Re: qqc2-desktop-style as framework

[Volker Krause]

On Thursday, 31 August 2017 17:06:46 CEST Marco Martin wrote:
> Hi all,
> we have a qtquickcontrols style that is right now in workspace (unrelased,
> to be released with Plasma 5.11)
> it makes controls paint with qstyle to give it a reasonable desktop
> appearance, plus some fixes/workarounds to make qml a bit more desktop
> friendly (for instance fixes scrollwheel issues with Flickable)
> sice it's pretty much untenable to make a desktop application with
> QtQuickControls2 without it and make it look anything near "native", so
> releasing it together plasma is probably not enough.
> Applications using kirigami should be able to explicitly depend from it if
> they want, to require a native-looking look and feel on linux desktops (even
> on gnome would look already marginally better than with the stock
> "universal" or "material" styles)
> 
> it's a thing with no api, no libraries (not even an import, qqc2 styles work
> a bit differently), so as with kirigami only source compatibility on the
> qml- side will matter
> 
> any objection into pulling it into a framework? anything particular for the
> procedure?

Observations while trying to add this to the KF5 Yocto recipes:
- it shows up as Tier 1 on https://api.kde.org/frameworks/index.html but seems 
to have a hard dependency on Kirigami
- it seems to be licensed LGPLv3 + GPLv2, which doesn't match what https://
community.kde.org/Policies/Licensing_Policy says about KF5 code (see item 4).

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.

D5961: PoC: Generic adoption of KUserFeedback for Discover

[Volker Krause]

vkrause added inline comments.

INLINE COMMENTS

> CMakeLists.txt:30
>  
> +find_package(UserFeedback)
> +

Hm, looks like I forgot to rename this to KUserFeedback... Should probably done 
to be consistent with naming elsewhere. I'll look into it, and sorry for yet 
another SC change.

> DiscoverWindow.qml:114
> +
> +UserFeedback.Provider {
> +id: provider

You probably want to set submissionInterval to a fixed positive value for it to 
actually send data automatically. For best results, pick one that matches the 
time aggregation modes in UserFeedbackConsole (1, 7 or 30).

> DiscoverWindow.qml:119
> +feedbackServer: "http://localhost:8083/;
> +telemetryMode: UserFeedback.Provider.BasicUsageStatistics
> +

Note that this means you have basic telemetry enabled by default. If you want 
to let the user control this entirely, just drop the line. Same for 
surveyInterval above.

> DiscoverWindow.qml:133
> +
> +onShowEncouragementMessage: {
> +showPassiveNotification(i18n("You can help us improving this 
> application by sharing statistics and participate in surveys."), 5000, 
> i18n("Contribute..."), encouraged)

For this to trigger you will need to set some of the encouragement related 
properties on Provider, by default it's off.

REPOSITORY
  R134 Discover Software Store

REVISION DETAIL
  https://phabricator.kde.org/D5961

To: apol, #plasma, vkrause
Cc: mart, plasma-devel, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, lukas

Re: Review Request 125195: Update the GTK icon cache when installing.

[Volker Krause]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125195/
---

(Updated Sept. 14, 2015, 4:10 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Olivier Goffart.


Changes
---

Submitted with commit 92cd2b667c04e18fd66986e8a42a53c052f5b5a0 by Volker Krause 
to branch master.


Repository: breeze


Description
---

Despite the name this is also used by Qt, and considerably speeds up
icon lookup.


Diffs
-

  CMakeLists.txt d7ef4044880deb0b753238bc7d7ee0138a216bce 
  cmake/GtkUpdateIconCache.cmake PRE-CREATION 
  icons-dark/CMakeLists.txt 9793950db02826c9f31818e30ac91ec9ad93d43f 
  icons/CMakeLists.txt 814b5ade4e5d185120a47fb72f2d5f531a7e8d41 

Diff: https://git.reviewboard.kde.org/r/125195/diff/


Testing
---

Installed with and without existing cache, cache is correctly updated and ends 
up in the expected place.


Thanks,

Volker Krause

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 125195: Update the GTK icon cache when installing.

[Volker Krause]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125195/
---

Review request for Plasma and Olivier Goffart.


Repository: breeze


Description
---

Despite the name this is also used by Qt, and considerably speeds up
icon lookup.


Diffs
-

  CMakeLists.txt d7ef4044880deb0b753238bc7d7ee0138a216bce 
  cmake/GtkUpdateIconCache.cmake PRE-CREATION 
  icons-dark/CMakeLists.txt 9793950db02826c9f31818e30ac91ec9ad93d43f 
  icons/CMakeLists.txt 814b5ade4e5d185120a47fb72f2d5f531a7e8d41 

Diff: https://git.reviewboard.kde.org/r/125195/diff/


Testing
---

Installed with and without existing cache, cache is correctly updated and ends 
up in the expected place.


Thanks,

Volker Krause

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120181: Remove usage of the obsolete Akonadi MicroBlog stuff.

[Volker Krause]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120181/
---

(Updated Sept. 14, 2014, 7:31 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

Remove usage of the obsolete Akonadi MicroBlog stuff.


Diffs
-

  dataengines/akonadi/CMakeLists.txt ccf5dcaf870a644a73f91b6d43fb6baf23702ade 
  dataengines/akonadi/akonadiengine.h 780deaae92f4732a1f1b8372a2c4f55cf21751c7 
  dataengines/akonadi/akonadiengine.cpp 
89fee441e579f15722b89427939ab40facd49fc8 

Diff: https://git.reviewboard.kde.org/r/120181/diff/


Testing
---


Thanks,

Volker Krause

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 120181: Remove usage of the obsolete Akonadi MicroBlog stuff.

[Volker Krause]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120181/
---

Review request for Plasma.


Repository: plasma-workspace


Description
---

Remove usage of the obsolete Akonadi MicroBlog stuff.


Diffs
-

  dataengines/akonadi/CMakeLists.txt ccf5dcaf870a644a73f91b6d43fb6baf23702ade 
  dataengines/akonadi/akonadiengine.h 780deaae92f4732a1f1b8372a2c4f55cf21751c7 
  dataengines/akonadi/akonadiengine.cpp 
89fee441e579f15722b89427939ab40facd49fc8 

Diff: https://git.reviewboard.kde.org/r/120181/diff/


Testing
---


Thanks,

Volker Krause

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Moving KWallet Password dialog into Plasma

[Volker Krause]

On Friday 20 July 2012 17:58:04 Martin Gräßlin wrote:
 Hi all,

 the problems around review request #105628 and getting KWallet's Password
 dialog properly raised above the window it is asking the password for just
 triggered a thought process.

 The main problem here is that $service ask for a password through
 $otherservice. This utterly fails because the $service is not linked
 directly to a window which the window manager would need to properly stack
 the window.

 Now if we think about it in most cases $service is actually a system
 service which can be considered belonging to the workspace. E.g. checking
 for mail, logging into your telepathy account and so on.

 Providing a password safe and asking for the master password is also a
 system service and should belong into the workspace.

 So here my idea: let's move the password dialog into the desktop shell. Have
 it as a so-called persistent notification popping out of the panel and be
 shown on top of all other windows till the user either dismisses it or
 enters the password.

 I think this would solve most of our current issues. There would be one
 place where the dialog is shown to ask for the password, it is visually
 clear that it's a system service which asks for the password and not some
 random malware and if several applications want to open the wallet this
 problem is also nicely solved by e.g. saying Mail Dispatcher Agent and
 Telepathy need to unlock the wallet.

 So what do you think?

I very much like your idea :)

It fixes exactly the problem we have with Akonadi (KRunner/Plasma Clock
starting Akonadi, which in turn syncs with some remote service needing a
password), and for which we haven't been able to find a real solution so far.

I also agree with your security assessment of this, once I can execute code as
your user, KWallet doesn't really protect much anymore, no matter where the
password dialog is running. But that's also not what it was designed to
protect, that's rather someone getting access to your files (different user on
the same system, stolen hard disk, etc). And that's not compromised by moving
the password dialog into a different process.

Integration with system passwords would of course be nice, but is IMHO
completely orthogonal to this.

When looking at KWallet security and usability, there's another aspect that
came up in discussions during Akademy: The Do you want to allow application
foo access your wallet? dialog. It might give the impression that only
certain trusted applications can access the wallet, which is totally
misleading. The application name can trivially be faked, and the allow/deny
always decision is simply stored in a plain text config file.

I assume the intention of this was rather to give users the choice to not
store data of well-known/well-behaving applications in the wallet (maybe due
to security concerns). Kinda makes sense, but might be better solvable by a
corresponding option on the application level (like web browsers do for
example, and I think most Akonadi agents as well), instead of bothering me
with yet another dialog when first using KWallet. This also avoids the false
sense of security.

Regards,
Volker



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Kde-pim] Akademy2012 BoF for WebAccounts

[Volker Krause]

On Saturday 23 June 2012 18:09:34 Alex Fiestas wrote:
 On Saturday, June 23, 2012 10:32:05 AM Volker Krause wrote:
  Monday might be tricky for me though, I'll be involved in running the Qt
  Quick 2 workshop there, but attending at least parts of this should be
  doable.
 
 Which time works best for you Volker? ideally we should have a member of
 each team for making the BoF a success, so you not being there is a blocker
 :p

Wednesday and Thursday seem still mostly free for me, but there also should be 
others from the PIM team around to attend on Monday, Kevin Krammer for 
example.

Volker

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Kde-pim] Akademy2012 BoF for WebAccounts

[Volker Krause]

On Friday 22 June 2012 16:08:25 Martin Klapetek wrote:
 On Thu, Jun 21, 2012 at 5:01 PM, Alex Fiestas afies...@kde.org wrote:
  Hi there!
  
  Sorry for the cross-posting, but this is a topic actually affecting all
  three
  mailist.
  
  Would be awesome to have a BoF at Akademy2012 about WebAccounts so I can
  share
  current plans and we can design together its future.
  
  This is a list of topics I would love to discuss:
  -Present to all my short-term plans.
  -We need to design how Applications will integrate with it.
  -What about Akonadi ?
  -What about Telepathy ?
  -Should we have more than one way of configuring things ?
  
  Taking a look at the schedule, it seems that the best slot is Monday from
  09:30 to 14:00, we will have a break for lunch between 12:30 and 13:00 (uh
  too
  small maybe?).
 
 I'm definitely in! Monday is good, but 9:30 is a bit early - how about
 10:30-12:30, lunch to 13:00/:30 and then 2 more hours. I think we'll need a
 bit more time for lunch to get away from all of that and then start fresh
 with clear head.

I'm definitely interested in this as well :)

Monday might be tricky for me though, I'll be involved in running the Qt Quick 
2 workshop there, but attending at least parts of this should be doable.

regards,
Volker


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: KDE-ify QML all across KDE

[Volker Krause]

On Thursday 27 January 2011 13:39:40 Shantanu Tushar Jha wrote:
 Hi Marco,
 
 I'm am working on Calligra Mobile as an Intern at Nokia. Just remembered
 that you had sent this mail. I understand that libkdeclarative is planned to
 be *the* way to access essential kdelibs functionality. If so, I was
 thinking about adding functionality to libkdeclarative as per needs arise
 for calligra mobile.
 
 e.g. right now I need a way to access Image loading in QML similar to
 KIcon(kwords.png), so we can add something to libkdeclarative, right?

IIRC we have code for icon finding and loading (KStdDirs, KIcon, etc) already 
in the QML/KDE integration of KDE PIM, sort of a very early predecessor of 
libkdeclarative, see kdepim-runtime/qml/kde/kdeintegration.cpp, maybe some of 
this can be reused and merged into libkdeclarative.

regards
Volker

 
 Cheers,
 
  Hi all,
  during last couple of days I've been working on
  g...@git.kde.org:scratch/mart/libkdeclarative
  
  This is a thing we agreed upon (and that I promised to do ;) at the
  mobile sprint.
  It's a little ~60KB library that's meant to be used inside KDE apps that
  are
  using QML, what do they do? but before, a bit of history:
  
  Since 4.6, Plasma has bindings to write plasmoids using just
  QML/Javascript,
  and especially in the light of our previous pure JS bindings, we
  immediately
  had some issues, that made KDE integration really poor, namely:
  * no way to use our own i18n
  * not possible to use Icons, pixmap and images (only pathnames of
  on-disk
  images)
  * no kconfig, kjobs
  * all urls manipulation hidden deeply into default qml elements only
  accepting
  strings
  
  This mostly because 2 severe design limitations of QML:
  * no access to the QScriptEngine
  * read only QScriptEngine main object
  
  that made impossible among other things to register any non-qobject
  class
  or
  global functions. Both are possible to be reverted in a quite hacky
  way, but
  so needed that made the hack acceptable to us, so now the QML based
  plasmoids
  can do all of the above without problems.
  
  Talking with the PIM people we discovered they had all of the same
  problems,
  so we agreed with them to have a KDE-wide solution that would make easy
  to anybody to use in a nice way what of kdelibs makes it so uhm,
  kdelibs ;)
  
  This library is basically a class, that after setting a
  QDeclarativeEngine with initialize() pulls the qscriptengine out of it,
  then replaces the main object with a writable copy.
  
  the setupBindings() function (unsure if keeping this step optional or
  just pput it into initialize()) binds in the main object goodies like
  i18n, kjob,
  kconfig, kicon and kurl.
  
  at the moment it links to qtdeclarative, kdecore and kdeui (just for
  kicon, if
  QIcon::fromTheme works good enough perhaps we can keep kdeui out)
  
  This would go in a (probably separate library) in kdelibs, making it
  possible
  to use from qml plasmoids as before or also in c++plasmoids or non
  plasmoid ui
  components of plasma (where we still don't have the same nice bindings)
  but also from completely independent applications like Kontact
  touch/calligra
  mobile/whatever.
  
  Cheers,
  Marco Martin
  ___
  Plasma-devel mailing list
  Plasma-devel@kde.org
  https://mail.kde.org/mailman/listinfo/plasma-devel

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel