Kirigami 6.2.1 release

[Nicolas Fella]

On 10.05.24 16:57, Nate Graham wrote:

[dropping kde-announce]

Hello folks,

Can we get a new release of Kirigami that includes
https://invent.kde.org/frameworks/kirigami/-/commit/722dc268ccc8921552c027d67d5b11d1d5307ec9?
This fixes a significant issue that snuck into the release which
breaks a bunch of dialogs in System Settings, making them appear
invisibly.

Nate


Hi,

Kirigami 6.2.1 is now available with an important fix.

Cheers

Nico

KDE Frameworks 6.2

[Nicolas Fella]

Hi,

KDE Frameworks 6.2 is released.

Please see https://kde.org/announcements/frameworks/6/6.2.0/ for a
changelog.

Cheers

Nico

Re: Frameworks 6.0.0 is out!

[Nicolas Fella]

On 2/28/24 14:26, Luigi Toscano wrote:

Jonathan Riddell ha scritto:

Frameworks 6.0.0 is out!  Congrats everyone.

At the meeting yesterday we decided to keep with the 1 monthly schedule.  I'll
try to nudge people into creating a release team so it's not all dependent on
1 person.

David Faure: we talked about having KF5 releases on a less frequent release,
maybe every 2 or 3 months.  Do you have an opinion here?

We spoke about making a bugfix release of 6.0 in two or three weeks time which
would mean making Git Frameworks/6.0 branches so bugfixes can go there.  I've
not done this yet but do let me know if I should.

Is this going to be a stable thing going forward?


That's not planned, no.


  I'd really hate to create a
translation branch just for a one time need, and just for one week more (if
it's 3 weeks, 4 weeks is 6.1). Let's please try to avoid that.

Why don't just cherry-pick the fixes to the tag, as it was done before, and
create other tags on top of that?

Or just anticipate the release of 6.1.


The idea here is that the public release of 6.0 might result in an
unusually high influx of bugreports/fixes so we might want to deliver
those sooner than a month. But that's a bit of speculation and might not
be necessary.


Ciao

Re: KDE Frameworks with failing CI (master) (24 December 2023)

[Nicolas Fella]

On 12/24/23 12:22, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI
jobs on their 4th failing week, it is very important that CI is passing for
multiple reasons.

Bad news: 1 repository is still failing

= FAILING TESTS ON WINDOWS =

kwallet: (2nd week)
  -https://invent.kde.org/frameworks/kwallet/-/pipelines/566351
- fdo_secrets_test fails


Failure message is

|FAIL! : FdoSecretsTest::items() 'errorStr.isEmpty()' returned FALSE.
(createDLGroup failed, maybe libqca-ossl is missing)|

which suggests it's related to qca. qca on the CI is provided by the
Craft build, and I don't see recent relevant changes there.

The failure seems to have started with the switch from Qt 6.5 to 6.6

|
|

Re: plasma-framework

[Nicolas Fella]

On 11/7/23 12:22, Jonathan Esk-Riddell wrote:

On Sun, Nov 05, 2023 at 12:59:28PM +0100, Friedrich W. H. Kossebau wrote:

kactivities and kactivities-stats: please consider proper de-KF-ication now

Hi,

with plasma-framework, kactivities and kactivities entering the Plasma product
bundle, I assume they also will adapt to Plasma versioning.

We've done the reversioning now (thanks to those who tidied up after
me yesterday).  We plan to rename plasma-framework to libplasma
although I'm not sure who has the energy to do it.  I suppose we'll
also remove the KF terms from the other ones too.

kwayland is the 4th one being moved, it has been re-versioned but not yet moved 
in invent.


Let's not do anything to plasma-framework until after the alpha to avoid
stiring things up yet again.

We have plenty of time to do it before the beta/rc

New(ish) Framework review: kstatusnotifieritem

[Nicolas Fella]

Hi,

at the last meeting we decided to extract KStatusNotifierItem from
KNotifications into a separate Framework.

Reasons are:

- They are rather distinct in scope/concept

- They negatively affect each other's dependencies

I've now created https://invent.kde.org/frameworks/kstatusnotifieritem
and started porting users of KStatusNotifierItem to it.

Given that this is 100% pre-existing Frameworks code I don't think an
in-depth "new framework review" is really appropriate, but if you have
important and/or actionable points then we can of course discuss them.

Cheers

Nico

KF6/Plasma 6 packaging notes

[Nicolas Fella]

Hi,

I'm happy that more and more distros are looking into packaging an
experimental KF6/Plasma 6 session. Since there are some non-obvious
things to keep in mind while doing that I started collecting some
packaging notes/information in
https://community.kde.org/Plasma/Plasma_6#Packaging_notes.

If there is anything unclear or you have ore useful information to add
feel free to ask here or edit the wiki directly.

Cheers

Nico

Porting aid place for Plasma stuff?

[Nicolas Fella]

Hi,

on several occasions we found API in Frameworks that we would like to
remove, but is still used in more than one place in Plasma and it may
not be feasible to port all of these usages in time for (Frameworks) 6.0.

There's a few things that fall in this category that come to my mind:

- KWayland: https://phabricator.kde.org/T11903#295217

- The drag and drop stuff in kdeclarative:
https://phabricator.kde.org/T12041#295298

- Plasma::Dialog:
https://invent.kde.org/frameworks/plasma-framework/-/issues/16

I would like to avoid a situation where we have to carry these all
throughout KF6 just because we miss to remove them before 6.0. An idea
that came up was to move them to somewhere in Plasma. There would be no
stability guarantee and we'd drop them as soon as they are no longer needed.

Assuming that's something we want to do I'm wondering what a good place
for those could be. plasma-workspace? plasma5support?
plasma-portingAidDumpingGround?

Thought?

Cheers

Nico

Re: These frameworks need new maintainers

[Nicolas Fella]

Am 01.08.23 um 15:48 schrieb David Faure:

In order to reflect reality, I have removed my name as maintainer
for the following frameworks (in master).
Don't hesitate to step up and write yours instead.

kapidox
karchive
kcrash
kdbusaddons
kded
kinit - but that's dead I think
kio
kitemmodels
kparts
kservice
kxmlgui


Hi,

I'd say most if not all of the maintainer information we have for
Frameworks is wrong and/or not useful and "The KDE Community" is the
only one that matches reality.

With that in mind I suggest we remove this information for all Frameworks.

Cheers

Nico

Re: Remaining plasma-framework KF6 tasks

[Nicolas Fella]

Am 09.07.23 um 12:56 schrieb Nicolas Fella:

Hi,

on the KF6 workboard there's a number of plasma-framework related tasks
that are still open. Some of them are actionable, others probably not or
need discussion.

I would appreciate if someone could go over the open tasks and triage
them, i.e. determine whether we consider them done, whether they are
still relevant, whether we need more discussion on it.

This helps us get a clear picture of what still needs to be done before
a potential 6.0 release of Frameworks/Plasma and thus helps with
planning our release timeline.

In particular I'd like input on these tasks:

- Split plasma-framework: https://phabricator.kde.org/T11642

- What to do with splitted frameworks: https://phabricator.kde.org/T12118

- qml imports plasma Core: https://phabricator.kde.org/T12117

- Discuss: QML scriptapplet plugin: https://phabricator.kde.org/T12111

- Deprecate Plasma::Theme https://phabricator.kde.org/T12108

- plasma-framework improvements / breaking changes:
https://phabricator.kde.org/T14954

The Plasma 6 board could use a similar cleanup.

If we need discussion on any of this we can organize a BBB meeting like
we have in the past.

Furthermore there's a number of "TODO KF6" comments in p-f code. Those
should be looked into as well

Remaining plasma-framework KF6 tasks

[Nicolas Fella]

Hi,

on the KF6 workboard there's a number of plasma-framework related tasks
that are still open. Some of them are actionable, others probably not or
need discussion.

I would appreciate if someone could go over the open tasks and triage
them, i.e. determine whether we consider them done, whether they are
still relevant, whether we need more discussion on it.

This helps us get a clear picture of what still needs to be done before
a potential 6.0 release of Frameworks/Plasma and thus helps with
planning our release timeline.

In particular I'd like input on these tasks:

- Split plasma-framework: https://phabricator.kde.org/T11642

- What to do with splitted frameworks: https://phabricator.kde.org/T12118

- qml imports plasma Core: https://phabricator.kde.org/T12117

- Discuss: QML scriptapplet plugin: https://phabricator.kde.org/T12111

- Deprecate Plasma::Theme https://phabricator.kde.org/T12108

- plasma-framework improvements / breaking changes:
https://phabricator.kde.org/T14954

The Plasma 6 board could use a similar cleanup.

If we need discussion on any of this we can organize a BBB meeting like
we have in the past.

Cheers

Nico

Re: kio-extras and the KF5/KF6 period

[Nicolas Fella]

Hi,

Am 17.05.23 um 00:02 schrieb Albert Astals Cid:

kio-extras provides plugins for kio.

So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6 kio-
extras.

This is also the case in more places, e.g. Breeze/Oxygen and
plasma-integration, so having a unified approach would make sense.

If we're going to support a period on which we ship both Kf5 and KF6 based
applications we need to:

Make sure kf5 and kf6 are coinstallable.

a) release two tarballs, one for each KF


In some cases, where there is a large enough divergence between the 5
and 6 code we might want to have separate branches to maintain those
(e.g. master is Qt6 and we have a qt5-compat branch).

Having separate branches would imply separate tarballs.

How would this work with version numbers and tags? We'd have something
like v23.08.0-qt5 and v23.08.0-qt6?


b) release one tarball that compiles both for kf5 and kf6

This would be my preferred approach for things with little divergence
between 5 and 6, i.e. not enough divergence to justify a separate branch.

c) just release the kf6 tarball, stop releasing the kf5 tarball but ask
distributions to still install it


You mean installing the last KF5-based release? How well this works
would depend on the amount of non-bugfix work we want to put into the
Qt5 variant.

For Breeze in particular this could mean that the appearance of Qt5 and
Qt6 apps could get out of sync.


What's everyone's preference?

Cheers,
   Albert


Cheers

Nico

Re: kf6 vs. kf5 conflict report

[Nicolas Fella]

On 3/8/23 14:02, Harald Sitter wrote:

with kf6 progressing nicely here's a first conflict report of files
that appear in both kf6 and kf5 under the same name. this largely
affects translations and docs it seems. this list may not be entirely
comprehensive, I've only thrown together a script in a couple minutes.


Thanks Harald!


one question is whether ECM should be co-installable, not sure if that
has been discussed


It has come up, and the answer seems to be "No, it will not be
coinstallable". This implies that ECM master will continue to support
Qt5/KF5, but that should not be a huge burden.


report for /usr:
https://collaborate.kde.org/s/3gz2KfoGLsS4TF5

furthermore the following files outside /usr clash between kf6 and 5:
'/etc/xdg/accept-languages.codes'
'/etc/xdg/kshorturifilterrc'
'/etc/xdg/autostart/baloo_file.desktop'
'/lib/udev/rules.d/61-kde-bluetooth-rfkill.rules'

HS

Re: Preparation for KF6, temporary stop of scripty on trunk/l10n-kf5

[Nicolas Fella]

Am 05.03.23 um 14:23 schrieb Luigi Toscano:

Karl Ove Hufthammer ha scritto:

Luigi Toscano skreiv 02.03.2023 14:24:

it seems that after a bunch of fixes, the master branch of scripty was able to
deal with both trunk/l10n-kf5 and trunk/l10n-kf6. As announced, now
trunk/l10n-kf6 tracks the master branch of Frameworks and the master branch of
Plasma (most of the modules shipped with 5.26, the ones that have switched to
Qt6).
Everything now looks fine to me but please take a look should anything looks
odd.

Why is kdelibs4support (with its > 3000 messages) included in the l10n-kf6
branch?

(And shouldn’t we have gotten rid of it a long time ago, when porting all the
applications to Frameworks 5?)


Good question: it seems it got a kf5 branch, but the master branch is still
around. But its i18n settings under sysadmin/repo-metadata are using the
default Frameworks value, so it looks like it's master branch should be
tracked by trunk_kf6.

The question then (cc-ing kde-frameworks-devel) is: should we fix the metadata
for the porting aids? Should we clean the master branch for those?


It makes no sense to translate the master branch for:

- kdelibs4support

- kemoticons

- kinit

- kdesignerplugin

- kdewebkit

- khtml

- kjs

- kjsembed

- kmediaplayer

- kross

- kxmlrpcclient

as they won't be released any more with KF6.

> Should we clean the master branch for those?

This has been suggested in the past, and the answer seems to be
"probably yes".

Cheers

Nico

Splitting KGlobalAccel interface and runtime

[Nicolas Fella]

Hi,

the kglobalaccel framework currently contains two pieces: kglobalacceld,
the runtime component that manages global shortcuts, and an
application-side library to interact with it.

The two communicate with each other via DBus. On X11 there is a
standalone kglobalacceld5 process providing the interface, on Wayland
the runtime is linked into KWin and thus the kwin_wayland process
provides the interface.

The current architecture has a number of downsides:

- Any call to the KGlobalAccel library may DBus-activate the
kglobalacceld5 process, which may be undesired on Desktop other than
Plasma since it competes with their native shortcut system. We tried
fixing that by making such calls no-op on !Plasma, but that broke things
for people that did want it to run, for example people using KWin with
LXQt, because KWin relies on KGlobalAccel for shortcuts

- We want to keep the dependencies of the interface library minimal,
which is inconvenient for the development of the runtime part. For
example we really want to use KIO::ApplicationLauncherJob in the
runtime, but currently can't, because that would introduce a dependency
cycle in Frameworks (KIO depends on KXmlGui, which depends on
KGlobalAccel, which would depend on KIO)

- Coinstallability of KF5 and KF6. Conceptually there can only be one
kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install a
kglobalacceld this is going to be problematic. This also means that a
KF6-based kglobalacceld must work with a KF5 interface library

- Other shortcut daemon implementations. Since somewhat recently there
is an XDG Portal for global shortcuts. Platforms like Windows and macOS
also have ways for applications to register global shortcuts. While we
are currently not using any of these it's very well possible that we
would eventually want to use the KGlobalAccel interface library to
interact with those. Having the kglobalacceld runtime in the same
frameworks therefore doesn't feel right.

To address these issues I suggest we split out the runtime part of
kglobalaccel into its own project, under the Plasma release group,
because that's primarily where it's used/supported. The interface
library would remain in frameworks. We have a similar situation with
activities, where the manager (kactivitymanagerd) is in Plasma and the
interface is in Frameworks. When doing this we'd also change the way how
kglobalacceld is started away from DBus activation towards explicitly
starting it as part of the Plasma startup. This avoids accidentally
launching it when it shouldn't be but still allows to explicitly start
outside of Plasma if really wanted. It would also allow for greater
flexibility in the development of the runtime, especially around
dependency constraints.

It wouldn't automatically solve the coinstallability problem of KF5 and
KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still
conflict with a Plasma-provided kglobalacceld, but it's at least
conceptually less messy since it's clear that the Plasma-provided one
would be the preferred one to use.

Thoughts about this?

Cheers

Nico

Re: Frameworks master is Qt6 now

[Nicolas Fella]

Am 23.01.23 um 17:23 schrieb Nicolas Fella:

Am 19.01.23 um 13:44 schrieb Nicolas Fella:

Am 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds
working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.


Assuming no major issues with our tooling crop up soon we will proceed
with the following changes:

- Bump the KF_VERSION in master to 5.240.0. At some point we will
release one or more beta versions, which will have 5.250.0 etc as
version number. This is to follow the practice of .80/.90 version
numbers, but slightly adjusted to account for 255 being the technical
upper limit.

- Drop build system code to build with Qt5

- Rename library/target names to KF6

- Drop deprecated API. To ensure compatibility with existing Qt6 builds
this will initially be done only for API that was deprecated before
5.100 since that is what the current Qt6 CI enforces. Eventually we of
course want to drop everything deprecated, but that requires porting
consumers of it first.

I expect this to happen over the next few days. I will announce once
this is done and master is open for more invasive changes.


Hi,

as an update to this:

We are currently progressing nicely with this, but are not done yet.

Some amount of instability/breakage is expected, so *I do not recommend*
to try and use frameworks master until things have settled down a bit.

Doing so prematurely would only cause extra work for everyone involved.

I will announce once things have settled enough to start working on more
things.


Hi,

the items mentioned are now done. We are now mostly in the process of
ironing out some edges and wrapping up some loose ends.

There's a list of "TODO after branching" tasks in
https://phabricator.kde.org/tag/kf6/ as well as a lot of "TODO KF6"
comments all across our codebase. Help with going through them and
addressing them is appreciated.

master is open for regular development as well as breaking changes.

Cheers

Nico

Re: portings aids in kf6?

[Nicolas Fella]

On 1/25/23 16:56, Jonathan Riddell wrote:

Can the team say which, if any, porting aids will continue in kf6?

KDELibs4Support
KDesignerPlugin
KDEWebKit
KHtml
KJS
KJsEmbed
KMediaPlayer
Kross
KXmlRpcClient

None of those will exist in KF6

Re: Frameworks master is Qt6 now

[Nicolas Fella]

Am 19.01.23 um 13:44 schrieb Nicolas Fella:

Am 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.


Assuming no major issues with our tooling crop up soon we will proceed
with the following changes:

- Bump the KF_VERSION in master to 5.240.0. At some point we will
release one or more beta versions, which will have 5.250.0 etc as
version number. This is to follow the practice of .80/.90 version
numbers, but slightly adjusted to account for 255 being the technical
upper limit.

- Drop build system code to build with Qt5

- Rename library/target names to KF6

- Drop deprecated API. To ensure compatibility with existing Qt6 builds
this will initially be done only for API that was deprecated before
5.100 since that is what the current Qt6 CI enforces. Eventually we of
course want to drop everything deprecated, but that requires porting
consumers of it first.

I expect this to happen over the next few days. I will announce once
this is done and master is open for more invasive changes.


Hi,

as an update to this:

We are currently progressing nicely with this, but are not done yet.

Some amount of instability/breakage is expected, so *I do not recommend*
to try and use frameworks master until things have settled down a bit.

Doing so prematurely would only cause extra work for everyone involved.

I will announce once things have settled enough to start working on more
things.

Cheers

Nicolas

Re: kquickcharts

[Nicolas Fella]

I'd recommend you don't try to build frameworks master for the moment.
Things are still in flux and some breakage is expected.

I'll announce once things have settled down a bit

Am 23.01.23 um 17:06 schrieb Jonathan Riddell:

*What might need doing for me to compile kquickcharts master branch? *
*https://build.neon.kde.org/job/jammy_unstable_kf6_kquickcharts_bin_amd64/25/console
15:51:32* [ 29%] Building CXX object 
src/CMakeFiles/QuickChartsStatic.dir/datasource/ModelHistorySource.cpp.o
*15:51:35* In file included from /usr/include/c++/11/bits/stl_algobase.h:71,
*15:51:35*   from /usr/include/c++/11/array:40,
*15:51:35*   from /usr/include/c++/11/tuple:39,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qtypeinfo.h:9,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qglobal.h:1397,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qcontainertools_impl.h:14,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qhash.h:8,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/qabstractitemmodel.h:8,
*15:51:35*   from 
/usr/include/x86_64-linux-gnu/qt6/QtCore/QAbstractItemModel:1,
*15:51:35*   from 
/workspace/build/src/datasource/ModelSource.h:11,
*15:51:35*   from 
/workspace/build/src/datasource/ModelHistorySource.h:11,
*15:51:35*   from 
/workspace/build/src/datasource/ModelHistorySource.cpp:8:
*15:51:35* /usr/include/c++/11/bits/predefined_ops.h: In instantiation of ‘constexpr bool 
__gnu_cxx::__ops::_Iter_less_iter::operator()(_Iterator1, _Iterator2) const [with 
_Iterator1 = QList::const_iterator; _Iterator2 = 
QList::const_iterator]’:
*15:51:35* /usr/include/c++/11/bits/stl_algo.h:5624:12:   required from ‘constexpr 
_ForwardIterator std::__min_element(_ForwardIterator, _ForwardIterator, _Compare) 
[with _ForwardIterator = QList::const_iterator; _Compare = 
__gnu_cxx::__ops::_Iter_less_iter]’
*15:51:35* /usr/include/c++/11/bits/stl_algo.h:5648:43:   required from ‘constexpr 
_FIter std::min_element(_FIter, _FIter) [with _FIter = 
QList::const_iterator]’
*15:51:35* /workspace/build/src/datasource/ModelHistorySource.cpp:53:29:   
required from here
*15:51:35* /usr/include/c++/11/bits/predefined_ops.h:45:23: error: no match for 
‘operator<’ (operand types are ‘const QVariant’ and ‘const QVariant’)
*15:51:35* 45 |   { return *__it1 < *__it2; }
*15:51:35*|~~~^~~~

Re: Frameworks master is Qt6 now

[Nicolas Fella]

Am 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.


Assuming no major issues with our tooling crop up soon we will proceed
with the following changes:

- Bump the KF_VERSION in master to 5.240.0. At some point we will
release one or more beta versions, which will have 5.250.0 etc as
version number. This is to follow the practice of .80/.90 version
numbers, but slightly adjusted to account for 255 being the technical
upper limit.

- Drop build system code to build with Qt5

- Rename library/target names to KF6

- Drop deprecated API. To ensure compatibility with existing Qt6 builds
this will initially be done only for API that was deprecated before
5.100 since that is what the current Qt6 CI enforces. Eventually we of
course want to drop everything deprecated, but that requires porting
consumers of it first.

I expect this to happen over the next few days. I will announce once
this is done and master is open for more invasive changes.

Cheers

Nicolas

Frameworks master is Qt6 now

[Nicolas Fella]

Hi,

the master branch of frameworks repositories now required Qt6 to build.
Maintenance of KF5 continues in the "kf5" branch.

Those using kdesrc-build make sure your kdesrc-builrc contains
"branch-group kf5-qt5", then it will switch to the correct branch
automatically.

Those building manually please adjust your workflow accordingly.

Any merge requests for frameworks should target Qt6/master (unless they
are not applicable there). If the change should be backported to KF5
cherry-pick it to the kf5 branch after merging.

Note that for the time being the kf5 branch has to stay compatible with
Qt6. This is required to keep the currently existing Qt6 builds working.

This does *not* mean that master is now open for any kind of breaking
change. We will announce more on this soon.

Cheers

Nicolas

D26424: [kdiroperator] Add method for accessing actions without KActionCollection

[Nicolas Fella]

nicolasfella abandoned this revision.
nicolasfella added a comment.


  Continuing in https://invent.kde.org/frameworks/kio/-/merge_requests/997

REPOSITORY
  R241 KIO

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

To: nicolasfella, #frameworks, dfaure
Cc: meven, dhaumann, aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ahmadsamir, ngraham, bruns, vkrause

Re: KF 5.95-rc1 delayed

[Nicolas Fella]

On 6/5/22 20:53, David Faure wrote:

Hi everyone,

I'm delaying the tagging of KF 5.95 rc1 until:

- the regression in kirigami is fixed
https://invent.kde.org/frameworks/kirigami/-/merge_requests/548#note_462793

- the regression in kio (trash) is fixed
https://invent.kde.org/frameworks/kio/-/merge_requests/854

Please let me know if there are other blocker issues.


Hi,

while we're at it we might also add
https://bugs.kde.org/show_bug.cgi?id=454635 to the list of blockers.

The relevant change that caused it is from plasma-framework:
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/500

Cheers

Nico

Re: smart pointers

[Nicolas Fella]

On 17/05/2022 14:34, Xaver Hugl wrote:

Hello,

I noticed that in KWin we use a lot of smart pointers and we mix Qt
and C++ standard library ones quite a lot. Judging by a few searches
in frameworks repositories, it's a similar mix there.
I'd like to propose that going forwards we use C++ standard library
smart pointers in new code and also port old code (where possible)
away from Qt smart pointers, for the following reasons:
- it increases consistency, making code a little bit easier to read
- in the general  C++ community, smart pointers from the standard
librariy are much more well known, which should make it a little bit
easier for new contributors to settle in
- std::unique_ptr allows to properly express ownership transfers with
move semantics, which QScopedPointer does not support
- std::shared_ptr is more efficient than QSharedPointer, it has half
the overhead on reference changes

What do you all think?

Greetings,
Xaver


Hi,

we recently had a similar discussion of Qt vs STL in the context of
containers. The key takeaways were:

- By default use Qt containers, especially in interfaces, for
interoperability with existing code that tends to use Qt containers

- Using STL containers is okay if there's a tangible benefit, e.g.
performance

With smart pointers the situation is a bit different, though. Almost no
Qt API takes or returns a smart pointer, so interoperability is not a
concern here. For KF5 this is not much different, with some exceptions
(KService::Ptr is a QExplicitlySharedDataPointer, some classes in
NetworkManagerQt/ModemManangerQt use QSharedPointer in their interfaces etc)

In general I'm leaning towards favoring STL smart pointers, not the
least given that even the Qt maintainers often advocate for the STL ones.

Cheers

Nico

Re: KStars on Windows

[Nicolas Fella]

On 09/03/2022 13:26, Nicolas Fella wrote:

On 09/03/2022 08:30, Ben Cooksley wrote:

Hi Jasem,

Recently some changes were introduced to Frameworks which means that
they now enforce more rigorously the platforms on which they build.

This means that KAuth is no longer available on Windows -
unfortunately though it looks like KStars has a mandatory dependency
on KAuth.

Are you able to make this optional or should we disable Windows CI
builds for KStars?

Cheers,
Ben


Hi Ben,

it looks like KStars doesn't use KAuth directly at all (ever since
https://invent.kde.org/education/kstars/-/commit/b17a8a3d4453e60d7f34023b8d633a80ebc37638).

I suspect that the find_package you are seeing comes from the public
interface of some dependency (KConfigWidgets comes to my mind, but I
need to look closer).

Cheers

Nico


Scratch that, the find_package is right there. The rest is true, it
seems to be unused/leftover.

https://invent.kde.org/education/kstars/-/merge_requests/570

Re: KStars on Windows

[Nicolas Fella]

On 09/03/2022 08:30, Ben Cooksley wrote:

Hi Jasem,

Recently some changes were introduced to Frameworks which means that
they now enforce more rigorously the platforms on which they build.

This means that KAuth is no longer available on Windows -
unfortunately though it looks like KStars has a mandatory dependency
on KAuth.

Are you able to make this optional or should we disable Windows CI
builds for KStars?

Cheers,
Ben


Hi Ben,

it looks like KStars doesn't use KAuth directly at all (ever since
https://invent.kde.org/education/kstars/-/commit/b17a8a3d4453e60d7f34023b8d633a80ebc37638).
I suspect that the find_package you are seeing comes from the public
interface of some dependency (KConfigWidgets comes to my mind, but I
need to look closer).

Cheers

Nico

D7700: Show list of tags in PlacesView

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> kossebau wrote in kfileplacesitem.cpp:351
> @nicolasfella Hi. this is passing the tag string both as translation context 
> as well as the string to translate as well. Is this on purpose? Even more as 
> the context parameter is ignored anyway and just there to force a context for 
> the other cases being used with I18NC_NOOP values, to make sure a context is 
> set at all.
> 
> So where are those tag names coming from, are they expected to be translated 
> at all?

Tags are user-defined string and not supposed to be translated at all.

So yeah, passing the tag as a context makes no sense here. Most likely I didn't 
even understand the concept of a translation context at the time of writing

REPOSITORY
  R241 KIO

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

To: nicolasfella, #dolphin, #kde_applications, alexeymin, ngraham, broulik
Cc: kossebau, chehrlic, broulik, kde-frameworks-devel, bruns, rkflx, mmustac, 
spoorun, michaelh, renatoo, anthonyfieroni, cfeck, elvisangelaccio, emmanuelp, 
ngraham, alexeymin, #dolphin, sdorishlab, badbunny, waitquietly, azyx, 
nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, koehn, cblack, 
fbampaloukas, alexde, Codezela, feverfew, meven, ahmadsamir, navarromorales, 
firef, andrebarros, rdieter, mikesomov, vkrause

Re: Gitlab CI - Inbound

[Nicolas Fella]

On 05.09.21 08:13, Ben Cooksley wrote:

Hi all,

This morning after much work i'm happy to announce that the new
generation CI scripts intended for use with Gitlab CI successfully
completed their first build (of ECM, and then subsequently of
KCoreAddons).

This begins our first steps towards transferring CI over from Jenkins
to Gitlab.

These scripts are 'Gitlab native' and are designed to work in an
environment where they will be running on merge requests, tags as well
as all branches of our repositories - something the existing scripts
were completely incompatible with. While there are still some
infrastructural elements to put in place (such as 'seed jobs' to mass
rebuild all projects after substantial changes and 'cleanup jobs' to
remove old builds from the Package Registry) the core elements needed
for initial testing of these scripts are now ready.

For those curious, the results of those initials runs can be found at
https://invent.kde.org/groups/teams/ci-artifacts/-/packages


Due to the challenges associated with having to handle all of the
different forms of build and the versioning of this information, these
scripts also represent a radical change in how CI builds will be
conducted - with a large part of the configuration of the jobs
themselves, including information on project dependencies now shifting
to files located within the repository themselves. Those who monitor
commits to Frameworks repositories will have noticed the appearance of
these '.kde-ci.yml' files in some repositories.

To assist in the future rollout of the CI system it would be
appreciated if projects could please begin setting up these files
within their respective repositories.
You can find a template detailing the available options at
https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml


Where possible please avoid overriding the system defaults except
where needed by your project (ie. don't just copy the template in full)
The defaults mirror the template and can be found at
https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml


In terms of the format of the 'Dependencies' section, please bear in
mind the following:
- For the 'on' section, the special value '@all' can be used to mean
"All platforms" to avoid needing to update the file in the event
additional platforms are added in the future
- For the 'require' section:
  1) Please only include the projects you *explicitly* depend on.
Dependencies of your dependencies will be included automatically
  2) When specifying a project, you must use the repository path on
Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop)
are no longer in use and will not work.
  3) There are three special values for the branch name - '@same',
'@latest' and '@stable' which can be used to refer to the branch/tag
of a dependency.
  '@same' means the branch name should be the same as that of the
project being built and should be used when declaring dependencies
among projects in a release group.
  '@latest' and '@stable' refer to the corresponding branches
defined in the branch-rules.yml file, which can be found in
sysadmin/repo-metadata

As a general rule, unless you require the absolute latest version of
another project in another release unit, it is recommended that you
use @stable.
Please avoid using explicit branch names unless absolutely necessary.

At this time it is expected that the first set of Gitlab CI builds
using the new scripts may be conducted for Frameworks within the next
week or so, assuming the build of the seed jobs goes according to plan.

Once the scripts have been proven successfully for Frameworks, we will
look at extending them to projects that depend only on Frameworks and
repositories within their release unit and finally will extend them to
projects with more complex dependency requirements. It is expected
that the switch will be flipped on the Frameworks builds sometime in
the next week or two.

Please let me know if you have any questions on the above.

Thanks,
Ben Cooksley
KDE Sysadmin


Hi Ben,

thanks for your work on this!

How would I best encode a dependency like "On Linux and FreeBSD depend
on kwayland, but not on Windows and macOS"?

Cheers

Nico

Re: KService as a platform abstraction framework?

[Nicolas Fella]

On 03.07.21 10:25, Volker Krause wrote:

Hi,

while looking at implementing a pretty straightforward KApplicationTrader/
KIO::ApplicationLauncherJob use ([1]) for Android, I found myself wondering
whether we should have an Android backend for KService.

KService conceptually matches android.content.pm.PackageManager/PackageInfo
[2, 3], ie. the platform API to list installed applications and their
respective features (essentially what's in the Android manifest XML files). In
detail it however is full of .desktop file specifics, and leaks platform
implementation details (e.g. KService inheriting from sycoca types).

KIO::ApplicationLauncherJob is also something that makes sense conceptually on
Android, implemented on top of Intents there.

Has anyone thought about/looked into using KService as platform abstraction
rather than as an functional/platform implementation framework already? I
could imagine this to also be relevant on Windows.

Is anyone aware of a current use on Android relying on the .desktop based
implementation of KService? That might be theoretically possible, unlike for
ApplicationLauncherJob.

And while retrofitting platform abstraction support into KService wont be
pretty, the alternative approaches (a new abstraction framework on top, or let
applications deal with that with platform-specific code paths) aren't exactly
convincing either.

Thoughts?

Thanks,
Volker

[1] https://invent.kde.org/plasma-mobile/qrca/-/merge_requests/35
[2] https://developer.android.com/reference/android/content/pm/PackageManager
[3] https://developer.android.com/reference/android/content/pm/PackageInfo


Hi,

I think overall it makes sense.

In our ongoing KF6 work we tend to move away from using KService for
non-application cases (plugins and kparts). Assuming we fully execute
that quite a bit of stuff then can be dropped from KService. That should
make it easier to adapt/make it less awkward to retrofit Android support
then. I think it's worth going over the KService class and investigate
how much of it will be relevant on a post-KF6 world.

Some XDG-isms are going to remain, but as long as it's just a bunch of
properties this should not be a big issue.

Cheers

Nico

T14621: [RFC] Consider deprecating PlasmaExtras.PlasmoidHeading in favor of PC3.ToolBar

[Nicolas Fella]

nicolasfella removed a project: KF6.

TASK DETAIL
  https://phabricator.kde.org/T14621

To: nicolasfella
Cc: nicolasfella, niccolove, mart, kde-frameworks-devel, mikeljohnson, Orage, 
LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, 
ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, hannahk, davidre, GB_2, ahmadsamir, kpiwowarski, usta, 
asturmlechner, jucato, cfeck, cgiboudeaux, cullmann, vkrause, cordlandwehr, 
knauss, dfaure

T14621: [RFC] Consider deprecating PlasmaExtras.PlasmoidHeading in favor of PC3.ToolBar

[Nicolas Fella]

nicolasfella added a comment.


  I'm not sure this makes sense on a semantic level. The current 
PlasmoidHeading happens to be very similar to a toolbar, but is that always 
going to be the case? I don't want us to be locked into a situation where we 
can't change things later on because they would break other users of ToolBar or 
because the ToolBar API is not suitable any more

TASK DETAIL
  https://phabricator.kde.org/T14621

To: nicolasfella
Cc: nicolasfella, niccolove, mart, kde-frameworks-devel, mikeljohnson, Orage, 
LeGast00n, The-Feren-OS-Dev, cblack, hannahk, jraleigh, zachus, davidre, 
fbampaloukas, GB_2, ragreen, ahmadsamir, ZrenBot, ngraham, kpiwowarski, 
himcesjf, usta, lesliezhai, ali-mohamed, jensreuterberg, asturmlechner, jucato, 
cfeck, abetts, cgiboudeaux, cullmann, vkrause, sebas, cordlandwehr, apol, 
ahiemstra, knauss, dfaure

Re: dark theme on windows in KF 5.83

[Nicolas Fella]

On 17.06.21 10:18, Alexander Semke wrote:

Hi,

with the last nighly build for LabPlot we observed a big regression on
Windows. Attached are two files. The first one is based on KF 5.82, the second
one on 5.83. In both cases the default color scheme is used in LabPlot which
is Window's dark theme as can be seen in the Explorer that I put besides
LabPlot.

It looks like in 5.83 we're trying to really be "dark" if this windows theme
is active but this is only partially successful. Is somebody aware of any
changes in 5.83 that can explain this behavior? Any other applications
observing this behavior on windows after the switch to 5.83?


Regards,
Alexander


That's a feature ;)

What you are seeing is
https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/50,
which is not merged yet, but Craft applies it downstream.

Cheers

Nico

Re: Notice of withdrawal of CI services: KDevelop and KDE Connect

[Nicolas Fella]

Hi Ben,

On 16.06.21 20:28, Ben Cooksley wrote:

Hi all,

The following is notice that I intend to withdraw CI services from the
following two KDE projects due to faults in their code or build system
which are having a significant adverse impact on the CI system and
negatively impacting on other projects:

- KDevelop
- KDE Connect

This withdrawal will be applied to all platforms.

In the case of KDevelop, it has a series of unit tests which on
FreeBSD cause gdb to hang and consume an entire CPU core indefinitely.
This slows down builds for all other projects using that CI server,
and also prevents KWin tests from proceeding - completely blocking
it's jobs. This fault is in the debuggee_slow family of tests.

As this issue has persisted for some time now despite being mentioned,
I require that the family of tests in question be disabled across all
platforms.

In the case of KDE Connect, as part of it's configure process it runs
an external command that results in dbus-daemon being launched. This
process persists following the build and would only be cleaned up by
our tooling that runs tests. Should the compilation fail (as it does
currently) it will result in the CI builder being broken - which is
why we have had so many Windows builds fail lately.

As this is an issue that has occurred previously, I require that the
configure time check which is launching dbus-daemon to be expunged
from KDE Connect.

As a reminder to all projects, running commands that interact with
dbus-daemon or kdeinit is not permitted during configure or build time.

Regards,
Ben Cooksley
KDE Sysadmin


I think I know what causes the KDE Connect behavior. The CMake code
calls 'ecm_find_qmlmodule(org.kde.people 1.0)', which results a call to
'qmlplugindump org.kde.kpeople 1.0' which causes parts of the KPeople
code to be executed (PersonsModel in particular) which does some DBus
things that then trigger dbus-daemon.

As a stopgap solution to make the CI operational we can remove that
ecm_find_qmlmodule call.

In terms of a proper solution there was a recent effort to remove the
mandatory DBus dependency from KPeople on Windows
(https://invent.kde.org/frameworks/kpeople/-/merge_requests/7). Perhaps
we should instead fully disable all DBus code in KPeople on Windows
instead, given that the usefulness is questionable.


Cheers

Nico

Respin request for qqc2-desktop-style

[Nicolas Fella]

Hi David,

can we please get a respin for the qqc2-desktop-style tarball with
https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/73
inside?

Cheers

Nico

T14471: Make Qt 5.15.0 to 5.15.2 for frameworks

[Nicolas Fella]

nicolasfella added a comment.


  Do we actually *want* to use the API that has been introduced in production?
  
  From QStringView:: toInt:
  
Note: This method has been added in 5.15.2 to simplify writing code that is 
portable between Qt 5.15 and Qt 6. The implementation is not tuned for 
performance in Qt 5.

TASK DETAIL
  https://phabricator.kde.org/T14471

To: nicolasfella
Cc: nicolasfella, kde-frameworks-devel, usta, LeGast00n, cblack, michaelh, 
ngraham, bruns

Re: KDE CI: Frameworks » ki18n » kf5-qt5 SUSEQt5.15 - Build # 58 - Still Unstable!

[Nicolas Fella]

Hi David,

this should be fixed with 
https://invent.kde.org/frameworks/ki18n/-/merge_requests/15

Cheers

Nico

On 1 May 2021 11:20:31 CEST, David Faure  wrote:
>Hi Nicolas,
>
>It looks like the ki18n commit
>
>Backport FindIntl.cmake from CMake 3.20
>
>might have broken the lookup of translations on CI?
>
>https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/job/ki18n/job/kf5-qt5%20SUSEQt5.15/57/testReport/junit/projectroot/autotests/ki18n_klocalizedstringtest/
>
>The test still passes for me locally, so I'm quite confused.
>Maybe it would be worth the experiment of reverting the commit, seeing what CI 
>says, to find out if it's related?
>
>The unittest uses a .po file from the autotests src dir, so this doesn't 
>depend on actual installed translations.
>
>Thanks for taking a look,
>David.
>
>On vendredi 30 avril 2021 23:41:45 CEST CI System wrote:
>>  BUILD UNSTABLE
>> Build
>> URL  https://build.kde.org/job/Frameworks/job/ki18n/job/kf5-qt5%20SUSEQt5.15
>> /58/ Project:kf5-qt5 SUSEQt5.15
>> Date of build:   Fri, 30 Apr 2021 21:38:47 +
>> Build duration:  2 min 57 sec and counting
>> 
>> 
>> 
>> BUILD ARTIFACTS
>> 
>> abi-compatibility-results.yaml
>> acc/KF5I18n-5.82.0.xml
>> compat_reports/KF5I18n_compat_report.html
>> logs/KF5I18n/5.82.0/log.txt
>> 
>> 
>> 
>> JUnit Tests
>> Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s),
>> Total: 1 test(s) Name: projectroot Failed: 1 test(s), Passed: 4 test(s),
>> Skipped: 0 test(s), Total: 5 test(s)
>> 
>> Failed: projectroot.autotests.ki18n_klocalizedstringtest
>> 
>> 
>> 
>> Cobertura Report
>> Project Coverage Summary
>> Name PackagesFiles   Classes Lines   Conditionals
>> Cobertura Coverage Report100% (2/2)  100% (17/17)100% (17/17)
>> 68%
>> (1962/2871)  48% (960/1985) Coverage Breakdown by Package
>> Name Files   Classes Lines   Conditionals
>> autotests100% (5/5)  100% (5/5)  89% (382/427)   55% (243/438)
>> src  100% (12/12)100% (12/12)65% (1580/2444) 46% (717/1547)
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: KGlobalAccel on non-Plasma systems

[Nicolas Fella]

That will continue to work. The window manager doesn't really matter
here, at least on X11.

On 06.04.21 20:31, Konstantin Kharlamov wrote:

Just to clarify a bit: by "only running on Plasma system" do you mean running
when $XDG_CURRENT_DESKTOP = KDE? Or something else?

The reason I'm asking is because I'm a user of Plasma + i3wm, and having various
shortcuts automatically set up by Plasma (specifically: screen brightness,
various multimedia keys) is certainly one of the reasons I love this
combination. I wouldn't want to see it break. This combination has
$XDG_CURRENT_DESKTOP set to KDE, so it is safe in that regard.

On Tue, 2021-04-06 at 17:29 +0200, Nicolas Fella wrote:

Hi,

we received a few reports [1] [2] from people using non-Plasma systems
that the kglobalaccel5 process was started, leading to clashes with the
native global shortcut system.

This seems to happen when apps call some API of KGlobalAccel which
results in the kglobalaccel5 process to be DBus-activated.

This brings me to the question of whether there is a use case for using
KGlobalAccel on non-Plasma systems at all. While technically
KGlobalAccel should work on all X11 systems most (all?) desktop
environments have their own way of global shortcut handling that we
should not interfere with. On Wayland it is only working in combination
with KWin. On systems that do not use X11 (Windows, macOS, Android) it
is most likely not useful at all. api.kde.org lists only Linux and
FreeBSD as supported, but the code contains special casing for non-Unix
platforms and for macOS.

At the recent Frameworks sprint we talked about better communicating
whether a given Framework is truly a cross-platform/cross-desktop
library or an implementation detail of Plasma/used for integrating with
Plasma [3]. It seems to me that KGlobalAccel falls into the latter
category.

If we agree that KGlobalAccel is only relevant when running Plasma we
should take the necessary steps to ensure it does not get activated in a
non-Plasma environment to avoid nasty side effects. Clearly defining the
scope would also help frameworks and app developers make technical
decisions and would allow to clean up some unneeded code.

Thoughts?

Cheers

Nico

[1] https://bugs.kde.org/show_bug.cgi?id=435420

[2] https://bugs.kde.org/show_bug.cgi?id=430691

[3] https://phabricator.kde.org/T14294

KGlobalAccel on non-Plasma systems

[Nicolas Fella]

Hi,

we received a few reports [1] [2] from people using non-Plasma systems
that the kglobalaccel5 process was started, leading to clashes with the
native global shortcut system.

This seems to happen when apps call some API of KGlobalAccel which
results in the kglobalaccel5 process to be DBus-activated.

This brings me to the question of whether there is a use case for using
KGlobalAccel on non-Plasma systems at all. While technically
KGlobalAccel should work on all X11 systems most (all?) desktop
environments have their own way of global shortcut handling that we
should not interfere with. On Wayland it is only working in combination
with KWin. On systems that do not use X11 (Windows, macOS, Android) it
is most likely not useful at all. api.kde.org lists only Linux and
FreeBSD as supported, but the code contains special casing for non-Unix
platforms and for macOS.

At the recent Frameworks sprint we talked about better communicating
whether a given Framework is truly a cross-platform/cross-desktop
library or an implementation detail of Plasma/used for integrating with
Plasma [3]. It seems to me that KGlobalAccel falls into the latter
category.

If we agree that KGlobalAccel is only relevant when running Plasma we
should take the necessary steps to ensure it does not get activated in a
non-Plasma environment to avoid nasty side effects. Clearly defining the
scope would also help frameworks and app developers make technical
decisions and would allow to clean up some unneeded code.

Thoughts?

Cheers

Nico

[1] https://bugs.kde.org/show_bug.cgi?id=435420

[2] https://bugs.kde.org/show_bug.cgi?id=430691

[3] https://phabricator.kde.org/T14294

D26449: [PoC] Port to KRecentFileMenu

[Nicolas Fella]

nicolasfella abandoned this revision.
nicolasfella added a comment.


  https://invent.kde.org/utilities/ark/-/merge_requests/39

REPOSITORY
  R36 Ark

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

To: nicolasfella, #ark, #frameworks
Cc: meven, mlaurent, kde-utils-devel, fbampaloukas, tctara

Re: KDE review for KWeatherCore

[Nicolas Fella]

On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote:

Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:

KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
querying weather forecast data. During the development of KWeather, we
found the need to have a weather library. KWeatherCore is the result of
extracting weather data fetching code from KWeather. I think having a
dedicated weather library can serve the following propose: - simplify the
KWeather code
- easier to develop a weather daemon
- potentially less code duplication across KDE

Many of you may have already seen my previous email to kde-devel mailing
list.
Thank you for your constructive suggestions. Here are something I want to

clarify:

I would also propose to consider doing a demon instead, so different
programs/processes all interested in weather forecast data could share the
data

   The end goal is a daemon indeed, but we want to build the daemon upon the
library. This would give us flexibility in the future if we don't want a
daemon. At least KWeather and other projects can still benefit from the
code.

My idea/proposal there is that the library internally makes use of that demon.
So code which uses KWeatherCore does not need to know that implementation-wise
there is a demon (which might also need to be a build-time option, think app
bundles who do not like separate demon processes).
So the demon would not use KWeatherCore, but be a(n optional) backend part of
it.


Please keep in mind that having such a daemon would be challenging to
impossible to implement on Android and possibly other platforms as well.

Let's not overengineer the wheel without having to and focus on use
cases relevant for our current apps and less on hypothetical use cases.

Cheers

Nico

D22544: [RFC] Deprecate KPassivePopup

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: ngraham, davidedmundson, aspotashev, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, bruns

D22093: Don't show progress window for jobs that don't report progress

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R495 Purpose Library

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

To: nicolasfella, apol, ngraham
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D23835: Add TabKCM

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R296 KDeclarative

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

To: nicolasfella, mart
Cc: broulik, onvitaik, zzag, ngraham, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, bruns

Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

[Nicolas Fella]

Hi,

with my KDE Android hat on this would be fine, we use Qt 5.15. For KDE's
own Windows/Mac builds I'd expect it to be similar.

What most/all not-traditional-Linux-distro users have in common is that
they are not bound to the specific Qt version decided and shipped by a
vendor and instead either build themselves or download official binaries.

The two major "distributions" that are potential frameworks users but
can't because of Qt versions (SailfishOS and Ubuntu Touch) don't ship
5.13 either, so it doesn't make the problem worse.

Cheers

Nico


On 12/1/20 1:29 PM, Jonathan Riddell wrote:

Not from KDE neon of course, we're on 5.15.  And not from the KDE
snaps build either.  But I suppose there's more than just Linux
distros to consider as we ship apps using KDE frameworks on Flatpak,
Android, Windows, even Mac to ponder too.

Jonathan


On Tue, 1 Dec 2020 at 12:14, Friedrich W. H. Kossebau
mailto:kosse...@kde.org>> wrote:

Hi,

last week KDE Frameworks master saw a bump in the
required/expected minimal Qt
version to Qt 5.13, following rules once agreed and noted here:
https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements


I would like to challenge that former decision though and propose
to instead
go straight to Qt 5.14 as minimum requirement now.


QUESTION:
Would any of the distributions have an issue with requiring Qt
5.14 instead of
Qt 5.13?


From some quick checks using https://repology.org/
 it seems that any
distribution versions which currently use Qt 5.13 have also
settled on some
older KF version, so will not update to just KF 5.77 and thus be
screwed.

Motivation:
* KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no
unit tests)
* Qt 5.14 added some new API, chance to miss out when using that
in new code
* C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14,
0) variants
* QML: no need to do hard-to-read generation tricks to support <
Qt 5.14
* Qt 5.13 went out-of-support in June
* App bundle builders would rather use some recent Qt 5.14/5.15

So by restraining to Qt 5.13 as minimum version IMHO we would
make/keep life
complicated for KF contributors without adding any value for anyone.

With most of KDE Frameworks in my local checkout:
    grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r
2>/dev/null | \
        grep "QT_VERSION " | wc -l
gives me "92", so there are quite some code variants which need
support in
current code.

From the emails at least in
https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html

I could not see a discussion whether Qt 5.13 makes
sense at all now, seems mainly the algorithm was applied. I
propose to match
the result to known real world needs now. Or teach me what I have
missed here
:)

Cheers
Friedrich

PSA: Frameworks depends on Qt 5.13 now

[Nicolas Fella]

Hi,

per our Qt dependency policy [0] Frameworks depends on Qt 5.13 6 months
after the release of Qt 5.15, which is now.

Have fun with the new stuff.

Nico

[0] https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements

D24443: Add a plugin system

[Nicolas Fella]

nicolasfella abandoned this revision.
nicolasfella added a comment.


  Moving to invent: 
https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/20

REPOSITORY
  R172 KCalendar Core

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

To: nicolasfella, #frameworks, #plasma, #kde_pim
Cc: z3ntu, ognarb, kde-pim, dkardarakos, vkrause, dvratil, davidedmundson, 
dhaumann, fbampaloukas, dvasin, rodsevich, winterz, cgiboudeaux, mlaurent, 
knauss

D28834: Add metadata properties to calendar

[Nicolas Fella]

nicolasfella abandoned this revision.
nicolasfella added a comment.


  moving to invent: 
https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/19

REPOSITORY
  R172 KCalendar Core

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

To: nicolasfella, #frameworks, #kde_pim, vkrause, winterz
Cc: winterz, kde-pim, fbampaloukas, dvasin, rodsevich, cgiboudeaux, vkrause, 
mlaurent, knauss, dvratil

D29020: Add example/test application

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29391: Introduce setWindow and CloseWhenWindowActivated

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: anthonyfieroni, kossebau, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

Re: Stepping down as KRunner maintainer

[Nicolas Fella]

Thanks for all your work Kai and congratulations Alexander, this is well
deserved!

Cheers

Nico

On 08.10.20 19:17, Kai Uwe Broulik wrote:

Hi everyone,

you might not even have known this but officially I have been KRunner's 
maintainer for several years at this point :-)

However, I have decided to step down as its maintainer as I believe won't be 
able to really move KRunner forward for KF6 despite a grand vision [1] for a 
lack of time and, frankly, motivation.

Therefore, I'd like to pass the torch to Alexander Lohnau. He's bringing many 
fresh ideas to the table and is very enthusiastic about making KRunner shine 
again. He's also surely done more in the past months than I did in the past 
years and so it's only fair to not have his ambitions hindered by my 
unresponsiveness on code reviews.

Alexander, thank you again for hosting that KRunner BoF at your first ever 
Akademy - the stage is yours ;-)

Cheers
Kai Uwe

[1] https://phabricator.kde.org/T12031

D25705: Deprecate KIO::pixmapForUrl

[Nicolas Fella]

nicolasfella abandoned this revision.
nicolasfella added a comment.


  Moved to https://invent.kde.org/frameworks/kio/-/merge_requests/144

REPOSITORY
  R241 KIO

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

To: nicolasfella, #frameworks, dfaure
Cc: kossebau, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

T12173: KService: provide solution to migrate away from KServiceTypeTrader/KMimeTypeTrader for loading plugins and parts

[Nicolas Fella]

nicolasfella added a subtask: T13555: Create replacement for 
KPluginInfo::kcmServices.

TASK DETAIL
  https://phabricator.kde.org/T12173

To: nicolasfella
Cc: #frameworks, nicolasfella, dfaure, mart, davidre, GB_2, ekasprzak, 
ahmadsamir, ngraham, kpiwowarski, usta, asturmlechner, jucato, cfeck, 
cgiboudeaux, cullmann, vkrause, cordlandwehr, knauss

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella closed this revision.

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella updated this revision to Diff 83348.
nicolasfella added a comment.


  - Use menus font metric

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26448?vs=83346=83348

BRANCH
  recentfilemenu

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

AFFECTED FILES
  src/CMakeLists.txt
  src/krecentfilesmenu.cpp
  src/krecentfilesmenu.h

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella updated this revision to Diff 83346.
nicolasfella added a comment.


  - Use widgets font metrics

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26448?vs=83338=83346

BRANCH
  recentfilemenu

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

AFFECTED FILES
  src/CMakeLists.txt
  src/krecentfilesmenu.cpp
  src/krecentfilesmenu.h

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella marked an inline comment as done.
nicolasfella added inline comments.

INLINE COMMENTS

> dfaure wrote in krecentfilesmenu.cpp:150
> Depending on QtConcurrent is just fine. However QtConcurrent::filtered is for 
> CPU-intensive operations, not for I/O operations. 1) you don't want to put 
> blocking runnables in the global thread pool [can be solved by assigning to a 
> different threadpool], 2) I don't think you really want to parallelize 16 
> calls to QFile::exists, for the case of a local physical harddisk? Not sure 
> it would really harm (we're not reading 16 files, at least), but for sure the 
> overhead of dispatching runnables to 16 threads would make it slower... One 
> solution here might be just a dedicated thread iterating over the list.
> 
> However: note that the usual KIO way to do file operations async isn't 
> multithreading, it's rather KIO jobs.
> This would move the "5 minutes waiting for an NFS server" horror case into a 
> kioslave rather than a thread, both achieve the desired outcome which is to 
> not block the GUI thread.
> 
> Keeping the order of the entries is going to be interesting. I guess we need 
> a temporary data structure which stores "exists | does not exist" for each 
> entry, and once all jobs are done, we go through that and fill the menu. Note 
> that remote URLs should just be assumed to exist, we don't want to actually 
> check (slow; might prompt for password; might error on different networks; 
> etc.).
> 
> Unlike Kai-Uwe, I think this should be a separate merge request though, it's 
> all quite orthogonal to your work. As long as you confirm that filling the 
> menu "later" has no negative impact on the API (i.e. the user of the class 
> cannot assume that the menu is filled in immediately).

> As long as you confirm that filling the menu "later" has no negative impact 
> on the API (i.e. the user of the class cannot assume that the menu is filled 
> in immediately).

Should be fine

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella updated this revision to Diff 83338.
nicolasfella marked an inline comment as done.
nicolasfella added a comment.


  - Fix @since
  - Add underscore to filename
  - Reserve vector

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26448?vs=83337=83338

BRANCH
  recentfilemenu

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

AFFECTED FILES
  src/CMakeLists.txt
  src/krecentfilesmenu.cpp
  src/krecentfilesmenu.h

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella marked 6 inline comments as done.

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella updated this revision to Diff 83337.
nicolasfella marked an inline comment as done.
nicolasfella added a comment.


  - Make findEntry return non-const iterator
  - Use std::vector
  - Truncate entries when setting maximum

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26448?vs=73172=83337

BRANCH
  recentfilemenu

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

AFFECTED FILES
  src/CMakeLists.txt
  src/krecentfilesmenu.cpp
  src/krecentfilesmenu.h

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D26448: Add KRecentFilesMenu to replace KRecentFileAction

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> broulik wrote in krecentfilesmenu.cpp:150
> If we're rewriting this thing anyway, can we please make sure it does not 
> block application startup checking if those files exist, as can happen if you 
> had opened files on an NFS mount before.
> 
> Either do it only when the menu is opened (aboutToShow) and/or asynchronously.

I'm wondering how to best make this async without selling my soul to the 
mulitthreading devil. QtConcurrent::filtered looks interesting, but depending 
on QtConcurrent wouldn't be feasible, would it?

REPOSITORY
  R236 KWidgetsAddons

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

Frameworks support for Qt 5.12

[Nicolas Fella]

Hi,

I received a question on how long KF5 will continue to support Qt 5.12.

Given that 5.12 is an LTS release according to our policy it would be
supported "until the next Qt release after the next Qt release", which
would be 5.16, which will never exist.

Our policy states "With Qt6 this changes a little bit again. To avoid
supporting 5.12 LTS and 5.15 LTS for ever, 5.15 LTS will be the minimum
required version 18 months after its release.". This however does not
answer what will happen with 5.12.

If I remember correctly our intention when formalizing this was to
extrapolate the hypothetical releases and apply the existing rules to
it. This would mean that by the time Qt 5.16 would be released (6 months
after Qt 5.15) KF5 would drop support for Qt 5.12 and require 5.13.

Is my interpretation of this correct? If so the wiki page should be
updated with this information.

Cheers

Nico

D29020: Add example/test application

[Nicolas Fella]

nicolasfella added a comment.


  Ping?

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D26918: Improve KNotification API docs

[Nicolas Fella]

nicolasfella updated this revision to Diff 83322.
nicolasfella marked 8 inline comments as done.
nicolasfella added a comment.


  - Address comments

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26918?vs=78423=83322

BRANCH
  arcpatch-D26918

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

AFFECTED FILES
  Mainpage.dox
  docs/Doxyfile.local
  src/knotification.h

To: nicolasfella, #frameworks, broulik, jucato, cblack
Cc: cblack, class, apol, kde-frameworks-devel, LeGast00n, michaelh, ngraham, 
bruns

D29390: Respect QIcon::fallbackSearchpaths()

[Nicolas Fella]

nicolasfella closed this revision.

REPOSITORY
  R302 KIconThemes

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

To: nicolasfella, #plasma, #frameworks, mart
Cc: mart, kossebau, aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29358: Implement lock-screen visibility control on Android

[Nicolas Fella]

nicolasfella accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  pending

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

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D25551: Mark KXmlRpcClient as porting aid

[Nicolas Fella]

nicolasfella closed this revision.

REPOSITORY
  R312 KXmlRpcClient

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

To: nicolasfella, #frameworks, dvratil
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29358: Implement lock-screen visibility control on Android

[Nicolas Fella]

nicolasfella requested changes to this revision.
nicolasfella added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> notifybyandroid.cpp:110
>  n.setField("urgency", (jint)(notification->urgency() == 
> KNotification::DefaultUrgency ? KNotification::HighUrgency : 
> notification->urgency()));
> +n.setField("visibility", 
> QAndroidJniObject::fromString(notification->hints().value(QLatin1String("visibility")).toString().toLower()).object());
>  

The hint name should be something like x-kde-visibility

REPOSITORY
  R289 KNotifications

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

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29358: Implement lock-screen visibility control on Android

[Nicolas Fella]

nicolasfella accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  pending

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

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29420: Generate DBus interface

[Nicolas Fella]

nicolasfella closed this revision.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29391: Introduce setWindow and CloseWhenWindowActivated

[Nicolas Fella]

nicolasfella edited the test plan for this revision.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29391: Introduce setWindow and CloseWhenWindowActivated

[Nicolas Fella]

nicolasfella updated this revision to Diff 83051.
nicolasfella added a comment.


  - Address APIdocs issues
  - Remove timer

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29391?vs=81822=83051

BRANCH
  closewin

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

AFFECTED FILES
  src/knotification.cpp
  src/knotification.h

To: nicolasfella, #frameworks, broulik
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D24025: Don't use KCrash on Android

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R241 KIO

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

To: nicolasfella, dfaure
Cc: vkrause, apol, broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D22868: Revamp Kirigami.AboutPage

[Nicolas Fella]

nicolasfella added a comment.


  can this be closed?

REPOSITORY
  R169 Kirigami

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

To: hein, #frameworks, #vdg, mart, apol, ngraham, leinir, nicolasfella
Cc: nicolasfella, ngraham, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, apol, ahiemstra, davidedmundson, mart

D25551: Mark KXmlRpcClient as porting aid

[Nicolas Fella]

nicolasfella added a comment.


  ping?
  
  Only kblog is using it, but according to T12157 
 that is supposed to go away too

REPOSITORY
  R312 KXmlRpcClient

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

To: nicolasfella, #frameworks, dvratil
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D23968: Use app specific location for DB on Android

[Nicolas Fella]

nicolasfella abandoned this revision.

REPOSITORY
  R307 KPeople

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

To: nicolasfella, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28312: Implement urls using hints

[Nicolas Fella]

nicolasfella closed this revision.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29802: Require out-of-source builds

[Nicolas Fella]

nicolasfella accepted this revision.

REPOSITORY
  R266 Breeze Icons

BRANCH
  require-in-source-build (branched from master)

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

To: ngraham, #frameworks, #vdg, ognarb, davidre, apol, nicolasfella
Cc: ltoscano, davidre, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29390: Respect QIcon::fallbackSearchpaths()

[Nicolas Fella]

nicolasfella updated this revision to Diff 82600.
nicolasfella added a comment.


  - Use array

REPOSITORY
  R302 KIconThemes

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29390?vs=81821=82600

BRANCH
  fallback

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

AFFECTED FILES
  src/kiconloader.cpp

To: nicolasfella, #plasma, #frameworks
Cc: kossebau, aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29390: Respect QIcon::fallbackSearchpaths()

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> aacid wrote in kiconloader.cpp:1142
> I just realized that function is private, not really easy to use :/
> 
> anyhow do you think we should remove svgz?
> 
> Also i think using
> 
> const QStringList extensions = { QStringLiteral(".png"), 
> QStringLiteral(".svg"), QStringLiteral(".svgz"), QStringLiteral(".xpm") };
> 
> should be a bit faster

I copied that list from somewhere else in KIconLoader. It would seem weird to 
me to support a different set of formats in the fallback than in the regular 
path

REPOSITORY
  R302 KIconThemes

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

To: nicolasfella, #plasma, #frameworks
Cc: kossebau, aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29631: [android] Allow specifying APK install location

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:a70e9a0162f7: [android] Allow specifying APK install 
location (authored by nicolasfella).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29631?vs=82531=82569

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

AFFECTED FILES
  toolchain/Android.cmake
  toolchain/ECMAndroidDeployQt.cmake

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns

D29631: [android] Allow specifying APK install location

[Nicolas Fella]

nicolasfella updated this revision to Diff 82531.
nicolasfella added a comment.


  - Rename variable

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29631?vs=82527=82531

BRANCH
  androinstall

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

AFFECTED FILES
  toolchain/Android.cmake
  toolchain/ECMAndroidDeployQt.cmake

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns

D29631: [android] Allow specifying APK install location

[Nicolas Fella]

nicolasfella marked 2 inline comments as done.

REPOSITORY
  R240 Extra CMake Modules

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

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns

D29631: [android] Allow specifying APK install location

[Nicolas Fella]

nicolasfella added a comment.


  This is used in https://invent.kde.org/sysadmin/ci-tooling/-/merge_requests/68

REPOSITORY
  R240 Extra CMake Modules

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

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns

D29631: [android] Allow specifying APK install location

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Frameworks, Android, apol, vkrause.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  This allows `make create-apk` to directly write the APK to /output instead of 
the cp-with-prefix step in /opt/helpers/create-apk. It's also useful for manual 
development builds where one would need to copy it to some output location 
manually or for CI setups that expect the output in a certain location.
  
  If ANDROID_APK_INSTALL_DIR is not set the current behaviour is kept.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  androinstall

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

AFFECTED FILES
  toolchain/Android.cmake
  toolchain/ECMAndroidDeployQt.cmake

To: nicolasfella, #frameworks, #android, apol, vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns

D29420: Generate DBus interface

[Nicolas Fella]

nicolasfella updated this revision to Diff 82237.
nicolasfella added a comment.


  - Use q as parent
  - Change reply type
  - Use ranged-for

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29420?vs=81920=82237

BRANCH
  geninterface

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

AFFECTED FILES
  src/notifybypopup.cpp
  src/notifybypopup.h

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29420: Generate DBus interface

[Nicolas Fella]

nicolasfella marked 3 inline comments as done.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29420: Generate DBus interface

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> broulik wrote in notifybypopup.cpp:115
> Previously it would accept the signal from any service which I find odd, 
> though. Could you maybe check git logs to see if there was a reason for this?
> It should survive restarts anyway and the service name is defined, so I 
> really don't see why it used to be a blind connect.

git history until the frameworks split isn't really telling, I didn't bother 
looking further back

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29420: Generate DBus interface

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Frameworks, broulik.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  We already use a generated interface in kstatusnotifieritem, but not in 
notifybypopup.
  
  Compile-time checks++
  code--

TEST PLAN
  Spawned, updated, closed notifications, triggered actions

REPOSITORY
  R289 KNotifications

BRANCH
  geninterface

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

AFFECTED FILES
  src/notifybypopup.cpp
  src/notifybypopup.h

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29336: Remove galago from method/variable naming

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:2012f675aed2: Remove galago from method/variable naming 
(authored by nicolasfella).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29336?vs=81680=81892

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

AFFECTED FILES
  src/imageconverter.h
  src/notifybypopup.cpp
  src/notifybypopup.h
  src/notifybyportal.cpp

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29405: [PoC] Make notifications work without a notifyrc file

[Nicolas Fella]

nicolasfella added a comment.


  In D29405#662963 , @apol wrote:
  
  > Won't this make it harder to put together the notifications kcm?
  
  
  Good point, we use the notifyrc file to know which apps send notifications 
ahead of time. Maybe we need something similar to 
`X-GNOME-UsesNotifications=true`

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik, vkrause
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29405: [PoC] Make notifications work without a notifyrc file

[Nicolas Fella]

nicolasfella added a comment.


  We want to phase out notifyrc files for several reasons:
  
  - They are an overkill for many simple use cases
  - A common pitfall when using KNotifications are missing or incorrect 
notifyrc files
  - Most of the information in there is duplicate/overridden at runtime anyway
  - We want to reduce the level of detail of the configurability anyway since 
it currently is quite an overkill
  
  See T11875  for some discussion

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik, vkrause
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29405: [PoC] Make notifications work without a notifyrc file

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Frameworks, broulik, vkrause.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  In KNotificationManager when reading the actions default to Popup when no 
actions are found. In notifybypopup default to 
QGuiApplication::applicationDisplayName() when reading the app name. The logic 
for the icon is not changed, worst case we get empty which may get overridden 
by the user.
  
  Other backends are still todo

TEST PLAN
  Deleted notifyrc file from KDE Connect. Still get notifications. As a side 
effect the pairing notification now shows "KDE Connect Daemon" instead of "KDE 
Connect". This could be changed with a new setter or x-kde-display-appname

REPOSITORY
  R289 KNotifications

BRANCH
  nonotifyrc

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

AFFECTED FILES
  src/knotificationmanager.cpp
  src/notifybypopup.cpp

To: nicolasfella, #frameworks, broulik, vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29391: Introduce setWindow and CloseWhenWindowActivated

[Nicolas Fella]

nicolasfella added a comment.


  In D29391#662471 , @broulik wrote:
  
  > The `QWidget` one has some additional features, like closing the 
notification when the window is destroyed (cf. its docs), which would be useful?
  
  
  lol, turns out that doesn't even work when using setWidget instead of the 
ctor with a widget because of 30b10492 


REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29391: Introduce setWindow and CloseWhenWindowActivated

[Nicolas Fella]

nicolasfella added a comment.


  In D29391#662471 , @broulik wrote:
  
  > Generally +1
  >  The `QWidget` one has some additional features, like closing the 
notification when the window is destroyed (cf. its docs), which would be useful?
  
  
  I'll take a look
  
  > Not a fan of the timer.
  
  Me neither, but the widgets code has this too, so I kept it. I can remove it 
though if we decide we don't want it
  
  > Also, we might want to deprecate the `QWidget` one now?
  
  That's my plan, but I still need to port some things

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29021: Remove checks for notification service and fallback to KPassivePopup

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:a5f0b1f7c812: Remove checks for notification service and 
fallback to KPassivePopup (authored by nicolasfella).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29021?vs=80687=81823

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

AFFECTED FILES
  src/notifybypopup.cpp
  src/notifybypopup.h

To: nicolasfella, #frameworks, #plasma, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29391: Introduce setWindow and CloseWhenWindowActivated

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Frameworks, broulik.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  This is a replacement for CloseOnWidgetActivated that operates on a QWindow 
instead of QWidget.

TEST PLAN
  PoC port of Yakuake:

REPOSITORY
  R289 KNotifications

BRANCH
  closewin

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

AFFECTED FILES
  src/knotification.cpp
  src/knotification.h

To: nicolasfella, #frameworks, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29390: Respect QIcon::fallbackSearchpaths()

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Plasma, Frameworks.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  When an icon isn't found within a theme we are supposed to look for it in 
QIcon::fallbackSearchpaths() (https://doc.qt.io/qt-5/qicon.html#fromTheme).
  
  BUG: 405522

TEST PLAN
  Create /home/nico/foo.svg
  Add QIcon::setFallbackSearchPaths(QIcon::fallbackSearchPaths() << 
QStringLiteral("/home/nico/myicons")); to my app
  Use foo icon somewhere

REPOSITORY
  R302 KIconThemes

BRANCH
  fallback

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

AFFECTED FILES
  src/kiconloader.cpp

To: nicolasfella, #plasma, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29339: Implement updating of notifications on Android

[Nicolas Fella]

nicolasfella accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29342: Implement support for notification urgency on Android

[Nicolas Fella]

nicolasfella accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29335: Implement notification grouping on Android

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> vkrause wrote in NotifyByAndroid.java:171
> That seems counter-productive to me, as the Android API documentation always 
> speaks about API level numbers, so you'd need to do an additional translation 
> to/from the letters in your head. So for that I find "26" more useful here 
> than "O". It's also consistent with the rest of the code in this file.

You have a point

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns