Re: VDG application design sprint?

[Nicolas Fella]

On 1/24/23 00:43, Nicolas Fella wrote:

Hi,

I think it would make sense for us to have a VDG sprint of sorts in the
near-ish future. This would allow to discuss some larger design topics
and set a vision for the longer-term future. I believe this is important
for us to be able to work together effectively.

I'd suggest to focus on application design topics, like layout,
structure, and arrangement of apps, and less on things like Plasma and
styles/themes. I'd also suggest to approach this more from a design/UX
PoV and don't let us be driven by implementation details. But these are
just my suggestions that are subject to debate.

Time/place/modality is all to be discussed, I'm mainly writing this to
gauge interest, so if you are interested let me know.


Hi,

I'd like to pick up this topic again since it's as relevant as ever.

I have a possible venue in central Germany where I live (in an old
castle, so in good KDE tradition). We could accomodate up to 10 people
there, and more people nearby if needed.

For those interested, what would be a good timeframe in terms of dates
and duration?

Cheers

Nico

Re: KleverNotes: request for review

[Nicolas Fella]

On 4/11/24 11:58, Louis Schul wrote:

Hello everyone,

I've been working on KleverNotes for about a year and I think it's now
mature enough to request a review.

KleverNotes is a note-taking and management application that uses
markdown. It allows you to organize your notes by category and groups,
create tasks, etc.
It supports the entire CommonMark specification and has a small
collection of "plugins" that extend basic markdown functionality (eg:
linking notes together, highlighting code, ...)

The end goal is to provide an easy-to-use Kirigami alternative to things
like Obsidian or QOwnNotes.

I have already created a "KDE review request" on the project repository.
See: https://invent.kde.org/office/klevernotes/-/issues/11

If needed, you can reach me on Matrix at @louis.schul:matrix.org or
directly in the KleverNotes room #klevernotes:kde.org


I went over the checklist and had some minor comments and a few
suggestions for the future. Overall looks very good though, nice work!

Cheers

Nico

Re: signon-kwallet-extension

[Nicolas Fella]

On 3/28/24 13:04, Ben Cooksley wrote:

Hi all,

Due to recent updates in SUSE around signond, i've just had to remove
signond-libs-devel from our SUSE Qt 5.15 images.

This is due to signond now being built with Qt 6 - and therefore being
incompatible with Qt 5.

Looking in signon-kwallet-extension though I see it is still Qt 5 code
that is unported.

It will therefore lose CI coverage support on LInux from today onward
until it is ported to Qt 6.

Cheers,
Ben


Hi,

signon-kwallet-extension is ported to Qt6. It's a bit special in the
sense that it must be built against the same Qt version signond is built
against, and since that can be either Qt5 or Qt6
signon-kwallet-extension still supports both. For practical intents and
purposes it's only the Qt6 build that matters though.

At the moment signon-kwallet-extension doesn't have Qt6 CI. This was due
to signon and friends not being available in Qt6 CI, but it seem to be
time to revisit that now.

Cheers

Nico

Re: Post-MegaRelease projects

[Nicolas Fella]

On 2/22/24 22:57, Nate Graham wrote:

Hello everyone,

Congrats to the entire KDE community on the impending launch of the
KDE 6 MegaRelease! I'm so impressed with how folks came together to
make it amazing. It's a very impressive release and I think people are
gonna love it.

I've started pondering post-megarelease projects. We've spent so long
on porting and bugfixing that I think it might be useful to shift
gears to feature work, and I'd like to brainstorm potential
large-scale projects and gauge the level of interest in putting
resources into them soon.

Here are some ideas of mine to get the creative juices started:

* David's input method playground stuff [1] is amazing and needs to be
developed and productized
* GNOME's Libadwaita app platform has been a runaway success for them;
evaluate our offerings in comparison and see what we can do better
* Unified theming infrastructure for KDE apps, GTK apps, and Plasma.
** Relatedly: QML/JS in themes is dangerous; move away from it
* Start adding release notes to our apps' AppStream metadata [2]
* Finish up and ship the new Breeze icons
* HIG is outdated and mostly ignored, and needs an overhaul to make it
useful
* Telemetry system has not proved to be very useful and needs an overhaul
* store.kde.org is full of low-quality or broken content; make a push
for KDE people to take ownership of content moderation, QA, etc. Also
any relevant and needed tech improvements
* Our virtual keyboard situation is not great and needs focused work
* KWallet needs an overhaul
* Have KWin (optionally) remember window positions on Wayland
* Build a "System misconfiguration detection hub" app [3]

Feel free to discuss, and propose your own!

Nate

[1]
https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/
[2] https://github.com/ximion/appstream/issues/354
[3] https://invent.kde.org/plasma/plasma-workspace/-/issues/64


Hi,

some ideas for strategically useful things:

- finalize the move away from Qt5/KF5 by porting remaining projects

- Update our QML code to make use of modern practices/tools (qmllint,
qmlformat, qmlcachegen, qmltc, qmlls etc)

- Invest in making it possible to write KDE-aligned apps in other
languages (IMO the most relevant contenders would be Python and Rust
since these are popular and there's prior art for using them with Qt)

- Work towards bringing features from our widgets-based frameworks
(configurable toolbars/shortcuts, KHamburgerMenu, KCommandBar etc) to
QML apps

Don't take this as a "I am going to work on this" list, but I'd be happy
to assist with any of the listed topics.

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 Gear projects with failing CI (master) (23 January 2024)

[Nicolas Fella]

On 1/23/24 22:46, Ingo Klöcker wrote:

On Dienstag, 23. Januar 2024 22:11:23 CET Ben Cooksley wrote:

On Wed, Jan 24, 2024 at 9:36 AM 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.

Good news: 5 repositories got fixed

Bad news: 2 repo still failing (1 with a different failure) and *10* new
this week


krecorder - 2nd week

  * https://invent.kde.org/utilities/krecorder/-/pipelines/589469

   * All the craft_android builds are broken

Looks like kirigami-addons is doing something the CMake in the Android
image doesn't like.

Interesting - perhaps the CMake (which is built from source I think)
version in the Android image needs updating?

It looks like the Android Qt 6 Craft builds fail since master was switched to
Qt 6. My guess is that this project lacks some changes that are needed for
building Qt 6 APKs with Craft. Maybe adding a suitable .craft.ini to tell
Craft that a newer version of kirigami-addons (and other packages) has to be
used for master is sufficient. See neochat for a minimal example. I'll have a
look tomorrow.

Regards,
Ingo


See https://mail.kde.org/pipermail/kde-devel/2024-January/002323.html

kirigami-addons master has a fix that the craft-supplied version lacks

Re: KParts and the Qt5->Qt6 transition

[Nicolas Fella]

Hi,

as an update for where we are right now:

On 12/6/23 21:51, Nicolas Fella wrote:

Hi,

the transition of many apps to Qt6 provides some challenges for apps
producing and consuming KParts.

KParts are implemented as Qt plugins and as such are specific to the Qt
version they are built against. In other words, a KPart built against
Qt5 cannot be loaded by an app using Qt6 and vice versa.

Since some parts are used by a variety of apps this is causing problems.
When we last discussed this problem the consensus was "Port as many
things as possible and see where we are at then". Now we are approaching
a point where we need to take stock and decide what to do.

 There's several cases to consider:

1) Applications using their own parts without external users. This
happens in PIM where e.g. kmailpart is only used by KMail and Kontact.
No problem here

2) Applications loading specific parts from other applications. These
are easy enough to search for. We have the following cases:

konsolepart (Konsole master is Qt6 only) is used by:

- kdevelop (no Qt6 port)


Qt6 port is in progress, but not finished:
https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/522



- konversation (MR with Qt6 port available)


Meanwhile ported to Qt6



- kile (no Qt6 port)


There is a MR to port:
https://invent.kde.org/office/kile/-/merge_requests/60



- Dolphin (already using Qt6)

- Kate (already using Qt6)

- Okteta (Q6 port available)


Unchanged as far as I can tell



- Yakuake (already using Qt6)

- Krusader (no Qt6 port)


Small steps towards a port, but still a lot of work



- Hotspot (extenal, Qt6 port available)

okularpart (Okular is in the process of getting ported):

Okular is meanwhile ported

- kile (no Qt6 port)


See above



- kbibtex (no Qt6 port)


Builds with Qt6 meanwhile



dolphinpart (Dolphin is using Qt6):

- konqueror (already using Qt6)

katepart (available for both Qt5 and Qt6):

- kompare (Qt6 branch available)

kgraphviewerpart (not using Qt6):


No change



- hotspot (external, Qt6 port available)

We do have two options for how to deal with these:

a) Port and release all relevant consumers of a given part at the same
time

b) Make sure the part is available for both Qt versions

3) There's a number of "general-purpose file type" parts that aren't
loaded explicitly but based on their mime type. Examples include
gwenviewpart, svgpart, markdownpart, okularpart. There's a number of
applications consuming those:

- Ark for file preview (Qt6 port available but not default yet)

Meanwhile using Qt6


- Kate for file preview (Qt6-only)

- Konqueror

- Krusader

- KBibTex

Here we would ideally have as many as possible available for both Qt
version (as long as we have Qt5-based KParts-consuming software).
However in cases like Ark the loss of functionality by not having
specific parts available would not be catastrophic.

Cheers

Nico

Re: Can my application, which contains dirty code, become an official kde application?

[Nicolas Fella]

On 1/17/24 03:12, Danilo Agostini wrote:

Hi, I developed an application and was thinking about doing the
incubation process but I'm not sure if my application will be accepted
due to some defects.

What my application does:

It allows the user, through the use of a keyboard shortcut or a
dolphin servicemenu, to have a quick preview of the files that are
shown in the folder without having to open the default application.

Similar applications are Gnome Sushi and Quick Look (Mac os).


Hi,

this looks like a cool project, congrats!

From a KDE perspective code quality concerns are mostly secondary,
because we can always fix/improve things there. The most important
question is what UX do we want to provide. Any implementation has to
follow that, and not the other way around.


Technical Limitations/Defects:

1) The way it integrates with dolphin is not clean due to dolphin's
limitations: I currently use dbus to copy the path of the selected
file into the clipboard and read it from my program. This, in addition
to not being a clean way, also causes corruption of the content that
was previously copied to the clipboard. I was able to get the
previously copied text to be restored, but there is no way to restore
the contents if what was copied to the clipboard before opening my
application was a file.


It seems like what you would need is a way to obtain the currently
selected file from Dolphin via DBus (without detouring through the
clipboard). I don't think that exists right now, but it should be easy
enough to add.


2) The preview of some files (odt,doc,docx,xlsx,etc) is obtained by
converting the documents to pdf using the "libreoffice --headless
--nolockcheck --norestore --convert-to pdf" command. This obviously
requires libreoffice installed on the system and the conversion may
fail/be slow in some cases.


I'd recommend you look at
https://api.kde.org/frameworks/kio/html/classKIO_1_1PreviewJob.html.
That's what Dolphin uses to create thumbnails and it has support for a
huge variety of file types. While Dolphin typically generates rather
small thumbnails it should be able to give you thumbnails of any
requested size.


https://github.com/Nyre221/Kiview
https://github.com/Nyre221/Kiview/blob/master/src/dolphinbridge.cpp
https://github.com/Nyre221/Kiview/blob/master/src/documentviewer.cpp

I'm writing this here because it's what was suggested to me.

Is there any chance that something like this could be accepted, or is
it better if I continue to develop it myself?

Thank you.

Re: KDE Gear projects with failing CI (master) (9 January 2024)

[Nicolas Fella]

On 1/9/24 23:45, 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.

Good news: 3 repositories got fixed

Bad news: 3 repo still failing (1 with a different failure) and 3 new this week


krdc - 2nd week
  *https://invent.kde.org/network/krdc/-/pipelines/577433
   * Dependency seems missing in flatpak


mimetreeparser - 2nd week
  *https://invent.kde.org/pim/mimetreeparser/-/pipelines/577439
* MessageViewerDialogTest doesn't pass


kdenlive - NEW reason
  *https://invent.kde.org/multimedia/kdenlive/-/pipelines/577432
   * craft_windows_qt6_mingw64 fails because of qtmultimedia


kimagemapeditor - NEW
  *https://invent.kde.org/graphics/kimagemapeditor/-/pipelines/577437
   * Qt6 build missing includes?

Fixed with
https://invent.kde.org/graphics/kimagemapeditor/-/commit/be68e9794ab390b072f2bb33cf30d70dde8c358

krecorder - NEW
  *https://invent.kde.org/utilities/krecorder/-/pipelines/577438
   * All the craft_android builds are broken

This needs
https://invent.kde.org/libraries/kirigami-addons/-/commit/3de0aae116276a1cd4ca7adb81d273225f546d80,
which isn't in the version craft has

filelight - NEW
  *https://invent.kde.org/utilities/filelight/-/pipelines/577430
   * flatpak build fails, seems 
thathttps://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/210  should 
have fixed it but it didn't. There's more steps involved and Ingo will take 
care of them

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

|
|

KIO workers and the Qt5->Qt6 transition

[Nicolas Fella]

Hi,

this is a variant of the plugin problem outlined in
https://mail.kde.org/pipermail/kde-devel/2023-December/002234.html

TL;DR Qt6 can't load Qt5-based plugins and vice versa

This also affects KIO workers.

We have a number of sources of KIO worker plugins:

- KIO itself provides file, http, help, ftp, remote, and trash. Since
KIO is available from KF5 and KF6 we get builds of those for both Qt
versions. No problem here.

- kio-extras provides additional workers: sftp, mtp, smb, ... kio-extras
is available for KF5 and KF6, so no problem here.

- various kio-* modules, like kio-gdrive, kio-stash, kio-gopher. These
should be built for both Qts, which should generally be possible, modulo
some common files to be deconflicted

- "Applications" that ship a KIO worker as part of their offering.
Examples that come to my mind are KDE Connect that ships a kdeconnect
worker and bluedevil that ships the bluetooth and obexftp workers. These
project are generally not designed to be coinstallable. i.e. if I have
Qt6-based KDE Connect I can't use the kdeconnect worker from a KF5 app

The last case is the one giving me headaches. Possible options would be

- Ignore the problem and hope nobody misses some workers in some
applications

- Make sure all (relevant) workers are available for both Qts, adding
some complexity to the build, release, and packaging process

- Since KIO workers run out of process it should be technically feasible
to come up with a way to run KF5-based worker plugins from a KF6-based
app and vice versa. I have not tried to implement that though, and it
would require some non-trivial surgery on KIO internals

Re: Kandalf: request for review

[Nicolas Fella]

On 12/8/23 00:49, Albert Astals Cid wrote:

El divendres, 8 de desembre de 2023, a les 0:44:11 (CET), Carl Schwan va
escriure:

On Fri, Dec 8, 2023, at 12:10 AM, Albert Astals Cid wrote:

El dijous, 7 de desembre de 2023, a les 16:28:48 (CET), Loren Burkholder
va

escriure:

Hi all!

I've been working towards getting Kandalf ready for integration into KDE
(and I'd like to thank everyone who has pitched in to help me, mainly
Laurent and redstrate). At this point, while the app is not necessarily
feature-complete or fully polished, it's getting close to that point.
Therefore, I'd like to officially request a review of Kandalf for
inclusion
in the KDE apps.

Where is the thing we're supposed to review?

In the wrong place:https://invent.kde.org/lorendb/kandalf/-/issues/1

And again we have people self-checking the checkboxes or their own review
:sad_dance:

To be fair, nowhere in
https://community.kde.org/Policies/Application_Lifecycle#kdereview does
it say who is supposed to check what box, so people checking "obvious"
boxes like "It has a passing CI build" themselves isn't that far off.

I asked Loren to create a sysadmin ticket to get it moved to an offical
namespace.

That seems premature? What if the review never succeeds?

Re: Kandalf: request for review

[Nicolas Fella]

On 12/8/23 00:49, Albert Astals Cid wrote:

El divendres, 8 de desembre de 2023, a les 0:44:11 (CET), Carl Schwan va
escriure:

On Fri, Dec 8, 2023, at 12:10 AM, Albert Astals Cid wrote:

El dijous, 7 de desembre de 2023, a les 16:28:48 (CET), Loren Burkholder
va

escriure:

Hi all!

I've been working towards getting Kandalf ready for integration into KDE
(and I'd like to thank everyone who has pitched in to help me, mainly
Laurent and redstrate). At this point, while the app is not necessarily
feature-complete or fully polished, it's getting close to that point.
Therefore, I'd like to officially request a review of Kandalf for
inclusion
in the KDE apps.

Where is the thing we're supposed to review?

In the wrong place: https://invent.kde.org/lorendb/kandalf/-/issues/1

And again we have people self-checking the checkboxes or their own review
:sad_dance:


I asked Loren to create a sysadmin ticket to get it moved to an offical
namespace.

That seems premature? What if the review never succeeds?


You don't need a passing kdereview to be able to get a repository.
kdereview typically happens (much) later than that.

KParts and the Qt5->Qt6 transition

[Nicolas Fella]

Hi,

the transition of many apps to Qt6 provides some challenges for apps
producing and consuming KParts.

KParts are implemented as Qt plugins and as such are specific to the Qt
version they are built against. In other words, a KPart built against
Qt5 cannot be loaded by an app using Qt6 and vice versa.

Since some parts are used by a variety of apps this is causing problems.
When we last discussed this problem the consensus was "Port as many
things as possible and see where we are at then". Now we are approaching
a point where we need to take stock and decide what to do.

 There's several cases to consider:

1) Applications using their own parts without external users. This
happens in PIM where e.g. kmailpart is only used by KMail and Kontact.
No problem here

2) Applications loading specific parts from other applications. These
are easy enough to search for. We have the following cases:

konsolepart (Konsole master is Qt6 only) is used by:

- kdevelop (no Qt6 port)

- konversation (MR with Qt6 port available)

- kile (no Qt6 port)

- Dolphin (already using Qt6)

- Kate (already using Qt6)

- Okteta (Q6 port available)

- Yakuake (already using Qt6)

- Krusader (no Qt6 port)

- Hotspot (extenal, Qt6 port available)

okularpart (Okular is in the process of getting ported):

- kile (no Qt6 port)

- kbibtex (no Qt6 port)

dolphinpart (Dolphin is using Qt6):

- konqueror (already using Qt6)

katepart (available for both Qt5 and Qt6):

- kompare (Qt6 branch available)

kgraphviewerpart (not using Qt6):

- hotspot (external, Qt6 port available)

We do have two options for how to deal with these:

a) Port and release all relevant consumers of a given part at the same time

b) Make sure the part is available for both Qt versions

3) There's a number of "general-purpose file type" parts that aren't
loaded explicitly but based on their mime type. Examples include
gwenviewpart, svgpart, markdownpart, okularpart. There's a number of
applications consuming those:

- Ark for file preview (Qt6 port available but not default yet)

- Kate for file preview (Qt6-only)

- Konqueror

- Krusader

- KBibTex

Here we would ideally have as many as possible available for both Qt
version (as long as we have Qt5-based KParts-consuming software).
However in cases like Ark the loss of functionality by not having
specific parts available would not be catastrophic.

Cheers

Nico

Re: KDE Gear projects with failing CI (master) (22 November 2023)

[Nicolas Fella]

On 11/23/23 00:09, 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.

Good news: 1 repository was fixed

Bad news: We have 4 new repositories failing


== kuserfeedback woes ==

kate
  *https://invent.kde.org/utilities/kate/-/pipelines/538985

dolphin
  *https://invent.kde.org/system/dolphin/-/pipelines/538986

kuserfeedback isn't available for Windows in the registry. Looking at it, it
hasn't compiled for days, what's going on there?


== Missing dependencies on CI ==

kalk
  *https://invent.kde.org/utilities/kalk/-/pipelines/538991
* Fails to find libqalculate>4.7.0 for Android


== Broken appstream/reuse ==

kclock
  *https://invent.kde.org/utilities/kclock/-/pipelines/538992

kclock is fixed now

Re: QML: a packagers nightmare. Assistance please.

[Nicolas Fella]

On 11/8/23 17:11, Scarlett Moore wrote:

While I have everyone's attention. The part that is getting me ( and
our linters ) is qml installation paths seem all over the place
For example plasma-framework we have

org.kde.plasma.plasmoids

which I read in the docs is "identified" qml which states it must be
installed into the QML import path which is normally ( and our linter
is set to ) /usr/lib/{arch_triplet}/qt{version}/qml
https://doc.qt.io/qt-6/qtqml-modules-identifiedmodules.html

However, these are getting installed to /usr/share/plasma/plasmoids

This doesn't follow the folder path ( eg. org/kde/plasma/plasmoids )
nor the normal qml import path. Or am I missing something?
If it is our mistake to not have this in our import path and our
linter is confused somehow, how would I add it? /usr/share or
/usr/share/plasma but then wouldn't it still be looking for the
org/kde/plasma/plasmoids?
Thanks for any help, I am really trying to figure this stuff out, but
I am lost in a sea of docs.
Scarlett


You are talking about two very different things here.

QML modules (i.e. QML "libraries") are installed to
/usr/lib/{arch_triplet}/qt{version}/qml. They contain a qmldir file,
(optionally) a .so file, (optionally) some .qml files, (optionally) a
.qmltypes file etc.

The content of /usr/share/plasma/plasmoids are not QML modules. They are
plasmoid packages (in the KPackage format). They contain a metadata.json
file and a number of qml/js/xml files in contents/. For all intents and
purposes those are data files like any other in /usr/share and should be
treated as such.

As such what you are seeing is entirely expected.

Cheers

Nico

Re: QML: a packagers nightmare. Assistance please.

[Nicolas Fella]

On 11/8/23 12:22, Scarlett Moore wrote:

Hi everyone,
As we progress through the Qt6 transition I have been trying to keep
up on our QML dependencies and I keep tripping over circular
dependency nightmare. We switched to a mega package format which
includes qml modules. So we have big issues when frameworks like kwin
depends on plasma-workspace. Introduced here:

https://invent.kde.org/plasma/kwin/-/commit/028dd552cfb9d826b40b9620d869c98d2aa3dca3?page=2

Is it intended that qml modules in plasma-workspace are allowed to be
used by frameworks? Are we wrong to bundle QML inside a mega package
or is the framework wrong for depending on QML further up the stack?
Any help or insight would be much appreciated.


Hi,

first of all, I don't think starting off an email with "QML: a packagers
nightmare" is a good-faith way to start a discussion about something,
especially given the issue presented has little to do with QML as a
technology and is rather specific to the projects involved.

Furthermore, kwin is not a framework, it's part of Plasma, and
dependencies between Plasma components are generally fine. That there is
a circular dependency between plasma-workspace and kwin is not good and
should probably be addressed somehow, but the severity is somewhat lower
given the cycle doesn't exist at built time.

Cheers

Nico

Re: KDE Gear projects with failing CI (release/23.08) (7 November 2023)

[Nicolas Fella]

On 11/7/23 22:55, 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: We have two new repositories failing


== Failing tests ==

cantor
  * https://invent.kde.org/education/cantor/-/pipelines/519203


== Broken CI setup ?¿ ==

print-manager
  * https://invent.kde.org/plasma/print-manager/-/pipelines/519206
   * plasma-frameworks can't be found

Fixed with https://invent.kde.org/plasma/print-manager/-/merge_requests/87

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

Re: Problems when adding a combo box to a toolbar and KActionCollection in KF6

[Nicolas Fella]

On 10/29/23 18:38, Stefano Crocco wrote:

Hello to everyone,
while porting Konqueror to KF6, I've hit a problem I don't know how to solve.
The issue is that it's impossible to give focus to the location bar by
clicking on it with the mouse as you can do in KF5.

After spending some hours trying to find out the cause of this, I reached the
conclusion that it has something to do with the main window's
actionCollection. A shortened version of the code which creates the location
bar is the following:

KonqMainWindow::KonqMainWindow() : KParts::MainWindow()
{
   //...
   m_combo = new KonqCombo(nullptr) //KonqCombo derives from KHistoryComboBox
   //...
   QWidgetAction *comboAction = new QWidgetAction(this);
   actionCollection()->addAction(QStringLiteral("toolbar_url_combo"),
comboAction);
  comboAction->setDefaultWidget(m_combo);
   //...
   setXMLFile(QStringLiteral("konqueror.rc"));
   createGUI(nullptr);

//"locationToolBar" is the name of the toolbar where the widget should be
//inserted
   m_combo->setParent(toolBar(QStringLiteral("locationToolBar")));
   m_combo->show();
  //...
}

If I remove the addAction method, the location bar is, of course, displayed
floating above the toolbar and it can be given focus clicking on it with the
mouse. The same happens if I remove the setDefaultWidget line. I tried adding
the action to the toolbar using

QAction *a = toolBar(QStringLiteral("locationToolBar"))->addWidget(m_combo);
actionCollection()->addAction(QStringLiteral("toolbar_url_combo"), a);

This gives the same problem as the previous code; however, if I remove the
second line, the focus works correctly again. This is what made me suppose the
problem is related to KActionCollection.

Initially, I thought that the problem was caused by some event filter or event
handler, so I tried creating a different action with new QComboBox, new action
name and so on, but the results were the same. Also, using a QLineEdit instead
of a QComboBox changed nothing.

I tried looking at the source code of KActionCollection, but I couldn't find
any significant difference between the KF5 and the KF6 version. The same can be
said for Konqueror source code, however.

Can someone give me some hints about what's happening?

Thanks in advance

Stefano


Hi,

focus and toolbar brings
https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/188 to my
mind. Can  you check whether it works as you expect before that change?

Re: KDE Gear projects with failing CI (master) (10 October 2023)

[Nicolas Fella]

On 10/11/23 11:52, Ben Cooksley wrote:

On Wed, Oct 11, 2023 at 4:37 PM 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: We have 3 new repositories failing

= FAILING UNIT TESTS =

kate:
 * https://invent.kde.org/utilities/kate/-/pipelines/497698
  * tests are failing


This looks to be a regression within KConfig no?
Likely won't show up on a developer system as the tests are bailing
out on asserts (the CI system builds a full Debug build on all
platforms except Windows, with all the consequences of that - this
being one of them)


See https://invent.kde.org/frameworks/kconfig/-/merge_requests/232



cantor:
 * https://invent.kde.org/education/cantor/-/pipelines/497702
  * flatpak is failing
   * Probably needs to be disbled until we have a KF6 capable flatpak?


Flatpak should be removed from applications that have gone Qt 6 only yes.


kamoso:
 * https://invent.kde.org/multimedia/kamoso/-/pipelines/497706
  * suse is failing to find packages
   * some gstreamer packages need to be added to the CI image?


Will be fixed once I have the image rebuild completed.



Cheers,
  Albert


Thanks,
Ben

Re: Problems while attempting configure the CI to build Konqueror for both KF5 and KF6

[Nicolas Fella]

Am 01.10.23 um 16:37 schrieb Stefano Crocco:

Hello to everyone,
in the last weeks, I worked on making Konqueror compile with both KF5 and KF6.
I had all the code on my PC and today I tried to upload it on GitLab. I
created a kf6 branch for Konqueror, pushed the code in my Konqueror fork and
created a merge request [1] for the kf6 branch. However, I don't know what to
do so that the CI tries compiling the code both with KF5 and KF6.

I wasn't able to find any documentation explicitly stating how to do this, so
Konqueror's current .gitlab-ci.yml with that of other KDE programs, I added
the following two lines at the former:
   - https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/
linux-qt6.yml
   - https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/
freebsd-qt6.yml

Unfortunately, this doesn't seem to work: the CI will indeed try to compile
Konqueror with both KF5 and KF6 in linux and FreeBSD, but the compilation with
KF6 fails in both platforms. I don't know whether this is because I didn't
correctly configure the CI or because there's something wrong in the way I
changed the CMakeLists.txt files (on my system Konqueror built correctly with
both KF5 and KF6).

The error message I get from the CI is the following (the full build log is
attached):
Exception: Unable to locate requested dependency in the registry: kdesu
(branch: kf5)

If I read this correctly, it seems that the system tries to find kdesu in the
kf5 branch which seems wrong, since the compilation should be for KF6.
Looking at the CMakeLists.txt files, I can't spot anything wrong. Before going
on investigating them, I'd like to be sure that what I did to make the CI
compile Konqueror with KF6 is correct and there's nothing else to do. Can
anyone give any hints or pointers to documentation about this?

Thanks in advance

Stefano

[1] https://invent.kde.org/network/konqueror/-/merge_requests/237


Hi,

you need to adjust .kde-ci.yml to pull the KF dependencies from the
@latest-kf6 branch group. See for example
https://invent.kde.org/graphics/gwenview/-/blob/master/.kde-ci.yml

Cheers

Nico

Re: KDE Gear projects with failing CI (release/23.08) (26 September 2023)

[Nicolas Fella]

On 9/30/23 11:13, Alexander Semke wrote:


On Dienstag, 26. September 2023 21:19:26 CEST 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.

> [...]

> cantor:

> * https://invent.kde.org/education/cantor/-/pipelines/488141

> * freebsd_qt515 tests are failing


Cantor's unit tests should be fine now but the flatpak build is
failing. Doesn't seem to be related to any recent code changes in
Cantor though:

https://invent.kde.org/education/cantor/-/jobs/1223632


Can somebody who is more familiar with ECM and with the flatpack build
please check this error?


The Flatpak build builds the master branch of analitza, which since
recently requires Qt6. I'd recommend changing the Flatpak manifest to
build the stable branch instead.

Re: Per project repository snapcraft files?

[Nicolas Fella]

Am 18.08.23 um 21:41 schrieb Ben Cooksley:

On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore
 wrote:



On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley  wrote:

On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore
 wrote:

Hello everyone,


Hey Scarlett,

I am asking to revisit per project repo snapcraft files. I
see now
that flatpak files are in project repos but I understand
this was
rejected for snapcraft. I would like to re-propose the
idea, and here
is why.
The CI jobs for snap builds is cludgy at best. We have
huge amounts of
failures because we must do a public upload to launchpad
which places
us at the lowest priority and we have many timeouts etc. Their
solution is to create proper snap recipes pointing to our
repos with
the snapcraft.yaml. Our current setup won't work because
we use
subdirectories in one repo.
Thoughts?


My understanding (when automating the triggering of these
builds on invent.kde.org  was discussed
with Sysadmin) was that the Snap folks had wanted to have
everything in one repository.
I had queried at the time why we weren't adding a file into
each repository (which is what we do with Flatpak, and now
with Craft as well - although those builds have yet to be
widely rolled out)

With regards to the triggering of these builds, how will this
happen?
It sounds like what you are describing here will result in
Canonical servers polling invent.kde.org
 for changes, which is something we're
not huge fans of as most projects only change every couple of
days.


Thanks for your time,
Scarlett


Cheers,
Ben



Hi!

Thanks all for responding.

Albert: snapcraft files have been ironed out. I have been quite
busy over the last year doing so.

Ben: There is an option to have launchpad build on changes which
would have polling. However, I would opt out of this feature and
instead write some tooling using launchpad API and Neons watcher
tooling to update versions and trigger launchpad builds. It would
actually lighten the load on KDE servers significantly.


Yes, we would definitely want to opt out of that completely - due to
the number of repositories we have, any kind of polling quickly turns
into a fairly significant number of requests.

Wouldn't you want to trigger this from a .gitlab-ci.yml job definition
though like we do for Flatpak and will be doing very soon for all of
the Craft builds that support Android, Windows and Linux appimage
binaries?

I was about to ask how the "future binary-factory" on invent will look
like and suggest to follow that precedent. Can you elaborate on that?
Will these be jobs in the relevant repos or will there be a meta-repo
with all of the "release" jobs?

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: KDE Gear projects with failing CI (master)

[Nicolas Fella]

Am 04.07.23 um 22:47 schrieb Albert Astals Cid:

= FAILING ANDROID (9 repos) =

kirigami-gallery:
  * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/427680
* Android build fails
 * There is some issue with qtsvg and qtwidgets

elisa:
  * https://invent.kde.org/multimedia/elisa/-/pipelines/427683
* Android build fails
 * There is some issue with qtsvg and qtwidgets

alligator:
  * https://invent.kde.org/network/alligator/-/pipelines/427723
* Android build fails
 * There is some issue with qtsvg and qtwidgets

kasts:
  * https://invent.kde.org/multimedia/kasts/-/jobs/1040376
   * Android build fails
 * There is some issue with qtsvg and qtwidgets

kongress:
  * https://invent.kde.org/utilities/kongress/-/pipelines/427741
   * Android build fails
 * There is some issue with qtsvg and qtwidgets

krecorder:
  * https://invent.kde.org/utilities/krecorder/-/pipelines/427743
* Android build fails

ktrip:
  * https://invent.kde.org/utilities/ktrip/-/pipelines/427745
   * Android build fails

kweather:
  * https://invent.kde.org/utilities/kweather/-/pipelines/427747
   * Android build fails
 * There is some issue with qtsvg and qtwidgets

neochat:
  * https://invent.kde.org/network/neochat/-/pipelines/427750
   * Android build fails

Those are a problem with the CI setup, which is being worked on. Nothing
the apps can do about

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: Ask about new KDE functionnalities.

[Nicolas Fella]

Am 28.04.23 um 12:14 schrieb Nicolas Lécureuil:

Hello,

i don't know if i post on the good ML but i have a friend searching
for developpers to mostly integrate ChatGPT into KDE. He accepts to
contribute financially.

"
    I don't know if it's possible, but for example, I would like to
allow the generation and saving of configuration files from the UI.
    integrate "a chatGPT" to enable script generation within the
graphical environment and thus execute these scripts: for example,
read the headers of a message and its attachments and suggest saving
the email "in a hard copy" (.eml) to the hard drive with the
attachments, with the help of voice and multiple choice help bubbles.
    for me, ChatGPT should be an everyday aid and from what I see, it
doesn't seem super complicated to integrate.
    I am willing to finance the project, but I don't know how much it
would cost.
    I would also like to have some software modified, such as OKULAR,
dolphin, etc.
"

if you know better places to ask this, please tell :-)


Hi,

you are approaching this from the wrong direction. You should not be
asking "How can I integrate ChatGPT into KDE?", rather you need to ask
"What problem do I want to solve and how?" and if the answer to that is
ChatGPT (or AI in general, let's not conflate the two), then the
question becomes whether and how we can use that in KDE.

Otherwise you have a solution looking for a problem, which is rarely a
good idea. And unless your problem is "How to I generate
plausible-appearing text given an input prompt" ChatGPT is likely not
the solution.

Cheers

Nico

Re: what to do with phonon & why aren't you using it?

[Nicolas Fella]

Am 14.03.23 um 13:04 schrieb Harald Sitter:

Hola!

Why don't you use phonon?

What would it make it useful?

What do you reckon we should do with it?

A bit of background perhaps: wy back when phonon was conceived as
multimedia abstraction library to serve as multimedia pillar. While it
is certainly abstract and a library I'm not so sure about the pillar
aspect ;) In fact, phonon is barely even an abstraction since I only
maintain the vlc backend and nobody else maintains any other backend.
So, one has to wonder if it'd not make more sense to put the bit of
energy that flows into phonon to instead go into qtvlc and not have to
deal with the abstraction element at all. Indeed all these
abstractions seem a bit silly because the multimedia libraries
gstreamer and vlc are already abstractions... it's nesting dolls all
the way down.
With all that in mind I was prototyping a revisit of the API many
years ago. Away from complicated mediagraph pipeline building
abstraction to simple player abstraction (you have a player, you give
it a url, it plays the url, that's it), as indeed that seems to be
what most remaining users want to do these days - hassle free
playback. Perhaps that is a path to take? But then the question
remains, do we need the abstraction at all?

Any and all thoughts welcome.

HS


Hi,

I don't really have any first-hand experience of (not) using Phonon to
give. But from my perspective the obvious question is:

How does all of this compare to QtMultimedia? It's also an abstraction
that kind of isn't any more, where things seem to converge on using the
FFMPEG implementation for all platforms.

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

Plasma master switches to Qt6

[Nicolas Fella]

Hi,

The master branch for Plasma repos will be made Qt6-only tomorrow,
28.02.2023.

There will be disruption because of this. While we aim for getting a
basic workspace running as soon as possible non-essential functionality
might be broken for a while.

Existing kdesrc-build setups will be switched to building Plasma from
the Plasma/5.27 branch to keep things building with Qt5. Make sure your
.kdesrc-buildrc contains "branch-group kf5-qt5".

You can build the Qt6/master version by specifying the "kf6-qt6" branch
group.

Cheers

Nico

Re: KDE Review: Arianna

[Nicolas Fella]

Am 25.02.23 um 14:59 schrieb Carl Schwan:

Hi folks,

I want to move Arianna to KDE review. Arianna is an ebook reader
currently only supporting epubs. This is based on top of epub.js
and QtWebEngine for the actualy rendering of ebooks as doing that
from scratch in Qt would be too much work.

The repo can be found here: https://invent.kde.org/graphics/arianna/

I create a gitlab issue to track the progress of this:
https://invent.kde.org/graphics/arianna/-/issues/1 Please free to add
your comments as recently suggested in this mailing list.


I've added some comments/suggestions to the issue.

Overall looks quite good to me.

Cheers

Nico

Re: Proposal for using gitlab for kdereview process

[Nicolas Fella]

On 2/17/23 08:53, David Redondo wrote:

Hi,

I observed that participation in kdereview is fairly low. Usually only the
same few people participate (I have to admit this does not include me either).
Further follow up to their comments tends sometimes to be slow or is missed.
Sometimes it fizzles out completely.
I think nowadays we have better tools to streamline the whole process, which
we are familiar with and make the barrier to participation lower. My idea is
to use Gitlab which we use for normal code review also for the kdereview
process. For example it could be as follows
- Announce the intention to go through kdereview as usual to kde-core-devel
- Create a MR in your project's repo from master branch into an empty
kdereview branch
- Could copy the sanity checklist [1] as task list and check things there
- Reviewers can leave review comments in the familiar web interface
- Commits that fix review comments are pushed to master branch and so update
the code seen in the MR
- Once the reviewers are satisfied and their feedback incorporated, they
approve the MR and it can be closed

Thoughts?

David
[1] https://community.kde.org/ReleasingSoftware#Sanity_Checklist


Hi,

I definitely like the idea of a more structured approach to the review,
e.g. by following a checklist.

Currently it feels somewhat ad-hoc and arbitrary what people suggest (or
don't suggest), and it's not always clear what's "required" to pass and
what's more of an optional suggestion.

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: 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: 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

VDG application design sprint?

[Nicolas Fella]

Hi,

I think it would make sense for us to have a VDG sprint of sorts in the
near-ish future. This would allow to discuss some larger design topics
and set a vision for the longer-term future. I believe this is important
for us to be able to work together effectively.

I'd suggest to focus on application design topics, like layout,
structure, and arrangement of apps, and less on things like Plasma and
styles/themes. I'd also suggest to approach this more from a design/UX
PoV and don't let us be driven by implementation details. But these are
just my suggestions that are subject to debate.

Time/place/modality is all to be discussed, I'm mainly writing this to
gauge interest, so if you are interested let me know.

Cheers

Nicolas

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: 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: 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

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

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

Re: "Gardening" old bugreports

[Nicolas Fella]

Hi,

Am 19.01.23 um 04:04 schrieb Justin:

Hi Nicolas,

This has been discussed with Nate Graham directly who has approved
this cleanup of Bugzilla including the messaging behind it.


KDE consists of more than Nate tough. We discuss and "review" things in
the open.



I am happy to discuss any concerns that people have around this. I
understand Krita requested we exclude them from any gardening and that
has been done, however this is the only feedback I have received.

The gardening team aims to find out if the bug reports are still
relevant by involving the users who reported them in determining if
they are still valid. This increases community involvement and helps
KDE as there isn't anywhere near enough manpower to review the
thousands upon thousands of bugs that haven't been touched in years.


Anecdotally many people don't like such automated changes being done to
their bugreports that don't actually engage with the content of the report.



The bugs that we are interacting with are ones that have not had any
activity for over 2 years. We are simply trying to reinvigorate
discussion on those bugs to see if they are still valid. If the user
does not reply within the standard 30 day period after a bug is set to
NEEDSINFO, it is automatically closed by the Bug Janitor.

I am not simply closing bugs, so I do take offense that care is not
applied.


Properly "triaging" old reports requires at least some level of
understanding of the project, codebase etc. I'm afraid there is no
simple solution to that and rule-based approaches aren't good enough.
Even taking things like CONFIRMED status or wishlist priority into
account assumes that these have actually been consistently applied.



I will halt it until it is approved by more developers. However if it
is decided that it isn't wanted then the KDE as a whole will need to
entice more people in sorting old bugs individually as it is clearly
not a priority right now for the majority.

Regards,

Justin


Don't get me wrong, I do appreciate the initiative of cleaning up bugs.
But we do need to handle this with a lot of care to avoid it backfiring.

Cheers

Nico



On 19/1/23 11:05, Nicolas Fella wrote:

Hi,

can we please put the effort of "gardening" old bugreports on hold until
we figured out whether this is actually something we want to do? Several
people already expressed concerns about this.

Improperly applied such mass changes can do more harm than good. We may
close bugreports that are actually still useful just because nobody
replied on then in a relatively short timeframe.

Properly cleaning up old bugreports is important. However, it requires
some level of care and expertise to judge whether a bugreport is still
useful. Judging by the volume of bugreports that is pinged with the same
copy message this care is not  applied here.

At minimum such initiatives should be announced and discussed before
doing them, to allow people to give their input on the proposal. I am
not aware of any such announcement/discussion.

Cheers

Nicolas

Re: "Gardening" old bugreports

[Nicolas Fella]

Am 19.01.23 um 01:35 schrieb Nicolas Fella:


Hi,

can we please put the effort of "gardening" old bugreports on hold until
we figured out whether this is actually something we want to do? Several
people already expressed concerns about this.

Improperly applied such mass changes can do more harm than good. We may
close bugreports that are actually still useful just because nobody
replied on then in a relatively short timeframe.

Properly cleaning up old bugreports is important. However, it requires
some level of care and expertise to judge whether a bugreport is still
useful. Judging by the volume of bugreports that is pinged with the same
copy message this care is not  applied here.

At minimum such initiatives should be announced and discussed before
doing them, to allow people to give their input on the proposal. I am
not aware of any such announcement/discussion.


For context, since not everyone may be aware of what's going on:

I'm referring to the practice of pinging old bugreports with a generic
"Is this still happening" message and setting the status to
NEEDSINFO_WAITINGFORINFO, which will cause the bug to be closed in 30(?)
days if not reset.

"Gardening" old bugreports

[Nicolas Fella]

Hi,

can we please put the effort of "gardening" old bugreports on hold until
we figured out whether this is actually something we want to do? Several
people already expressed concerns about this.

Improperly applied such mass changes can do more harm than good. We may
close bugreports that are actually still useful just because nobody
replied on then in a relatively short timeframe.

Properly cleaning up old bugreports is important. However, it requires
some level of care and expertise to judge whether a bugreport is still
useful. Judging by the volume of bugreports that is pinged with the same
copy message this care is not  applied here.

At minimum such initiatives should be announced and discussed before
doing them, to allow people to give their input on the proposal. I am
not aware of any such announcement/discussion.

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

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

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

Re: New santizer warning in KF 5.98 headers

[Nicolas Fella]

On 1/10/23 22:49, Michael Reeves wrote:

/usr/include/KF5/KConfigWidgets/kstandardaction.h:261:64: runtime
error: load of value 4294967295, which is not a valid value for type
'Qt::ConnectionType'

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/include/KF5/KConfigWidgets/kstandardaction.h:261:64 in

The issue stems for assigning an int to a enum which is internally
considered unsigned and possibly smaller than the four byte int. If
this is doing what we expect than I need a way to shut off the warning.

Looks like
https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/175
aims to address this?

Re: Unknown protocol "konq"

[Nicolas Fella]

Am 27.12.22 um 18:56 schrieb Reindl Harald:

Hi

for month now on Fedora you get a error message everytime you start
konqueror or open a new tab that the protocol "knoq" isn't known

nobody in the distro bugtarcker cares, recently again kf5/konqueror
updates and still the same issue

dunno what this protocol should be for, maybe a missing but obious
useless dependecny because besides the annoying message you need to
confirm all day long everything works

Dez 27 18:51:00 srv-rhsoft.rhsoft.net kioexec[2417]: kf.kio.core:
Protocol Class of url QUrl("konq:blank") , isn't ':local', cancelling
job.
Dez 27 18:51:00 srv-rhsoft.rhsoft.net kioexec[2417]: kf.kio.core:
couldn't create slave: "Unbekanntes Protokoll „konq“."


Please don't use the mailing list to report bugs, that's what
https://bugs.kde.org is for.

Re: Can we make kpat not depend on black-hole-solitaire by default?

[Nicolas Fella]

Am 30.11.22 um 15:26 schrieb Marius P:

Hello,

Debian and Ubuntu do not package yet
https://github.com/shlomif/black-hole-solitaire
Can we make kpat not depend on
https://github.com/shlomif/black-hole-solitaire by default?

Reasons:
1. In order to build kpat on Kubuntu 22.10, we need to edit kdesrc-build.
2. Debian and Ubuntu need to have in file "rules"
"override_dh_auto_configure:... -DWITH_BH_SOLVER=OFF".

Thanks.

Technical details. kdesrc-build patch:

$ git diff
diff --git a/kf5-applications-build-include
b/kf5-applications-build-include
index 52b453c..63ed776 100644
--- a/kf5-applications-build-include
+++ b/kf5-applications-build-include
@@ -145,6 +145,12 @@ module-set kmix
     cmake-options -DKMIX_KF5_BUILD:STRING=TRUE
 end module-set

+module-set kpat
+    repository kde-projects
+    use-modules kpat
+    cmake-options -DWITH_BH_SOLVER=OFF
+end module-set
+
 module-set kdegames
     repository kde-projects
     use-modules kde/kdegames amor


The obvious solution here is "Make Debian and Ubuntu package
black-hole-solitair". Anything else is just a workaround for a problem
that shouldn't exist.

Archiving KDE Telepathy?

[Nicolas Fella]

Hi,

there various KTP modules have seen very little development over the
last years. Most of the activity that did happen was either release
housekeeping stuff like version bumps or general code cleanup (i.e. the
kind of cleanup that some people do across the whole KDE codebase and
not necessarily out of a genuine interest in KTP). There is also no
significant activity around it on bugs.kde.org.

While certainly amazing in its vision it anecdotally never fully made
use of that potential, partly because it's just trying to solve a
problem that is really hard to solve.

Most of the activity I see around KTP is from people trying to use it
out of curiosity but finding it broken/unpolished or not what they
expected it to be. We like to say that "Everything in KDE Gear is
maintained". I'd argue that from this follows that if it isn't actually
maintained we should drop it from the Gear releases.  We are doing our
users a disservice by pretending something is maintained when it
actually isn't. We are also doing ourselves a disservice since
unpolished software "leaking" into the desktop experience is going to
make the whole product appear unpolished.

Furthermore, with the transition to Qt6 very soon now we should make a
decision: Either we invest a non-trivial amount of work into making it
work against Qt6/KF6, or we pronounce it dead. Having it "alive" but
unported isn't helping anyone in the long term.

Therefore I propose that we stop releasing the various ktp- modules with
KDE Gear and archive the repositories after the last relevant KDE Gear
cycle finished.

Cheers

Nico

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: Plasma Welcome Center on KDEReview

[Nicolas Fella]

Am 16.09.22 um 17:59 schrieb Nate Graham:

Hello folks!

I've been working with Aleix on an onboarding wizard for Plasma, based
on work originally started by Felipe Kinoshita last year.

You can see some screenshots at
https://invent.kde.org/websites/product-screenshots/-/commit/e300be66e62263c63d8a85ba391bbcc1de691148.

I'd like to target Plasma 5.27 for release and am submitting it for
KDEReview. The repo is at https://invent.kde.org/plasma/welcome-app.


Hi,

- I'd suggest to rename the repository to plasma-welcome to be
consistent with the internal name and also other Plasma repos

- The version number in KAboutData says "1.0", this should follow the
Plasma version

- There's no Qt6 build yet, please look into that

- Some distributions have their own welcome apps, please coordinate with
them so that we don't end up greeting the user with two welcome apps

- The appstream id ends with .desktop, which I understand is deprecated

- appstreamcli validate --pedantic org.kde.plasma-welcome.appdata.xml
has some warnings:

P: org.kde.plasma-welcome.desktop:12: screenshot-no-caption
P: org.kde.plasma-welcome.desktop:~: releases-info-missing
I: org.kde.plasma-welcome.desktop:3: cid-contains-hyphen
org.kde.plasma-welcome.desktop
P: org.kde.plasma-welcome.desktop:15: screenshot-no-caption

- There's a stray .directory file in src/

- Please add the ECM clang-format target and commit hook

Re: Plasma Welcome Center on KDEReview

[Nicolas Fella]

Am 16.09.22 um 23:40 schrieb Nate Graham:

On 9/16/22 15:31, Albert Astals Cid wrote:

Those screenshots show me the Wayland icon, please fix.


Sure, how do I fix that exactly?


Either

- Fix the first argument to KAboutData to be the same as the base name
in the desktop file. The desktop file name is org.kde.welcomecenter, so
you would need to pass "welcomecenter" instead of "plasma-welcome" to
KAboutData

- Use KAboutData::setDesktopFileName("org.kde.welcomecenter")

Re: Product organization in Bugzilla

[Nicolas Fella]

Am 16.09.22 um 13:00 schrieb Dawid Wrobel:

On Thu, Sep 15, 2022 at 11:59 PM Johannes Zarl-Zierl
 wrote:

Is the launcher category the same as on https://apps.kde.org/? If
so, I would
strongly prefer to use that as well. From a user perspective,
apps.kde.org 
should be the single source of truth.


I know this was discussed to death dozens of times before, but given
this context, wouldn't it make sense to devote bugs.kde.org
 to user-facing applications (as in
http://apps.kde.org/) *only*, and move all the issues related to the
underlying libraries, frameworks, tooling, etc. to GitLab, hopefully
after migrating away from Phabricator as well?

It is not uncommon for organizations to maintain two kinds of bug
trackers: one for end-users, and one internal, hiding the technical
discussion away. I am sure this would improve developers' workflow
while making bugs.kde.org  less intimidating to
end-users. Cause if I was coming from Windows/macOS and saw something
like this:

- KDE apps
- KDE Plasma Desktop
- KDE Plasma Mobile
- KDE Frameworks
- KDE Neon

, I still would be confused as hell. I mean how many KDE users are
familiar with what Plasma (Desktop/Mobile), Frameworks or Neon are?
Let's bear in mind that many of them use KDE apps individually on
non-Linux platforms.

Just my 2c.


Hi,

you are on to something that I wanted to raise anyway: Quite often
people report bugs for a frameworks they think is related to the problem
instead of the product we expect them to use. Some examples:

- kwindowystem or kwayland instead of kwin

- pulseaudio-qt instead of plasma-pa

- bluez-qt instead of bluedevil

- networkmanager-qt instead of plasma-nm

- knotifications instead of plasmashell | notifications

Separating these "internal" components a bit from the user-facing
products could make sense to reduce the apparent confusion.

However, I don't think using an entirely separate (and different!)
system for app bugs (bugzilla) and library bugs (Gitlab Issues) is a
good idea. Those two are somewhat different in their workflows and
capabilities (each having pros and cons) and I doubt having to deal with
*both* would be challenging. For example think about moving bugs between
the two systems.

Cheers

Nico

Re: New releases for bugfixes

[Nicolas Fella]

Hi,

I don't think Nate or anyone wants to propose a strict policy that when
X then Y has to happen. That's just not how we operate in KDE. I do
think it is valuable though to discuss and create some guidelines/shared
understanding/soft policy that maintainers can use as a reference when
making decisions. That would match very well how decisions and policies
are made in KDE.

Cheers

Nico

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Nicolas Fella]

Only build.kde.org is shut down, binary-factory.kde.org is unaffected

On 9/3/22 16:12, Michael Reeves wrote:

I now have no way to even test macosx builds for kdiff3, I have no
access to a 64bit Intel mac. What are the plans for this and Windows
builds. I have a functional windows based craft installed locally.

Sep 3, 2022 12:47:06 AM Ben Cooksley :

On Sat, Aug 27, 2022 at 9:44 PM Ben Cooksley 
wrote:

Hi all,

This evening I completed the necessary setup required to
complete our Gitlab CI dashboards, which can now be found at
https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE
Developer account login required)

These allow any developer to get a view on the current CI
status of projects and groups of projects on a branch and
platform basis - and should hopefully provide useful insight
into the overall status that can currently be obtained from
Jenkins.

As this was the last thing holding us back from shutting down
build.kde.org , i'd like to proceed with
retiring and shutting down build.kde.org
 as soon as possible so the capacity it
occupies can be released and reallocated to Gitlab.


As previously indicated, I have now shutdown build.kde.org
 along with the domain that supported it's
version of the CI tooling.
The repository containing that tooling has now also been archived,
and the former build.kde.org  domain has
been redirected to metrics.kde.org .

The server which was acting as a builder for build.kde.org
 will be rebuilt in the coming days and
reallocated to support Gitlab CI workloads.


If anyone would like to experiment with customised views for
their own purposes (where the above provided ones are
insufficient) please file a Sysadmin ticket.

Please let me know if there are any questions on the above.

Thanks,
Ben


Thanks,
Ben

Re: Aura Browser in KDE Review

[Nicolas Fella]

Am 26.08.22 um 12:27 schrieb Aditya Mehra:

Hi,

Aura Browser is in KDE Review and would like to release it along with
Plasma Bigscreen

Aura browser is a web browser specifically designed to work with
remote controls and key navigation for Plasma Bigscreen, it supports a
virtual mouse cursor and multiple tabs it also includes a third party
AdBlock from brave browser based on easy list.

You can find the repository here:
https://invent.kde.org/plasma-bigscreen/aura-browser

Request to please review Aura Browser.

Regards,
Aditya



Hi,


- There is no Gitlab CI, please add that

- There is no support for Qt6. Please look into that and report any
blockers (e.g. missing API in Qt) you find. (not a blocker for kdereview)

- In
https://invent.kde.org/plasma-bigscreen/aura-browser/-/blob/master/app/CMakeLists.txt#L36
the desktop file is configured but only static values are passed in. Why?

- According to the desktop file the app can open .deb and .rmp files.
Why would a browser be able to open those?

- The executable name (AuraBrowser) is somewhat unconventional. Usually
we use lowercase names, i.e. aurabrowser or aura-browser


I also have some nitpicks about the CMake code, but it's probably more
productive if I just make a MR instead of listing every single one.


Cheers


Nico

Re: Automated usage of Gitlab

[Nicolas Fella]

On 7/3/22 12:45, Ben Cooksley wrote:

Hi all,

Recent analysis of the logs of our Giltab instance has revealed
numerous instances of files being directly retrieved from Gitlab
(using the /raw/ API). Much to my incredible sadness, this has
included accesses being made by KDE Applications themselves.

As a reminder, automated access to the "raw files" API of Gitlab is
strictly prohibited and not permitted under any circumstances. The
only use of it which is allowed is within .gitlab-ci.yml files to
import job definitions from sysadmin/ci-utilities.

At this time I am tracking:
- Retrieval of qt/qt/qtbase - .qmake.conf and extra-cmake-modules -
FindUDev.cmake and COPYING-CMAKE-SCRIPTS from systems operating in
Microsoft Azure using curl.

- Retrieval of *.colors files from the Breeze repositories,
originating from KDE CI/CD servers, likely as a consequence of unit
tests or Craft builds


That looks like
https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/kde/kdemultimedia/kdenlive/kdenlive.py#L116

That's the only usage of raw invent URLs I see in craft-blueprints-kde



- Retrieval of various code examples from various repositories,
originating from KDE CI/CD servers, likely due to unit tests or Craft
builds utilising them

- Retrieval by Digikam itself of files from the Digikam code
repository (see
https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/onlineversion/onlineversionchecker.cpp)

The last one is particularly upsetting, as this is how we ended up
with a bad situation with Discover.

Developers - please discuss with Sysadmin before implementing
functionality in your software that communicates with KDE.org
infrastructure so we can ensure that the endpoints you are contacting
are highly scalable.
Gitlab does not meet this criteria by any definition at all.

If we could please get these corrected that would be appreciated.

Thanks,
Ben

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: KPipeWire in kdereview

[Nicolas Fella]

On Monday, May 30, 2022 2:55:55 PM CEST Aleix Pol wrote:

   >Hi,
   >I'd like to get KPipeWire (https://invent.kde.org/plasma/kpipewire)
   >released from KDE eventually.
   >
   >At the moment it's under Plasma as it's the only place where it's
   >being used, I know we might want to use it in spectacle eventually,
   >although I feel like it's premature to get it in frameworks just yet,
   >although it should be a possibility down the line.
   >
   >If you wanted to test it beyond what Plasma does, you can try this
   >little app for recording your wayland desktops and windows.
   >https://invent.kde.org/apol/screenrecord
   >
   >Cheers!
   >Aleix


Hi,

- The repo could use a README that explains what it is and isn't
- The repo probably shouldn't have a .kdev4 file
- CMakeLists.txt states 5.20 as minimum ECM version. That sounds wrong
- (some of) the pkg_check_modules calls should probably have REQUIRED
- I get some build warnings:

[9/46] Building CXX object src/CMakeFiles/KPipeWire.dir/pipewirecore.cpp.o
/home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing
initializer for member ‘pw_core_events::done’ [-Wmissing-field-initializers]
   21 | };
  | ^
/home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing
initializer for member ‘pw_core_events::ping’ [-Wmissing-field-initializers]
/home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing
initializer for member ‘pw_core_events::remove_id’ [-Wmissing-field-
initializers]
/home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing
initializer for member ‘pw_core_events::bound_id’ [-Wmissing-field-
initializers]
/home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing
initializer for member ‘pw_core_events::add_mem’
[-Wmissing-field-initializers]
/home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing
initializer for member ‘pw_core_events::remove_mem’ [-Wmissing-field-
initializers]

- ecm_add_qtwayland_client_protocol can take a target since recently
- xdp-recordme probably shouldn't be installed (by default)?
- There's no FreeBSD CI yet

These are some minor things I noticed while glossing over. I won't
pretent to
understand enough about PipeWire to comment on the actual code.

Cheers

Nico

Re: NetworkManagerQt

[Nicolas Fella]

Hi,

On 27/05/2022 17:35, Kovour, Sathyanarayana wrote:


Hi

My name is Sathya Kovour, I am part of Baxter International, a medical
device manufacturer.

We come across NetworkManagerQt
https://marketplace.qt.io/products/networkmanagerqt, and we have a few
questions while we are making decision to use this very convenient
modules in our project.

  * As per above link this project is accessible for us with LGPL
v2.1+. According to our legal department this is very restrictive
for our distribution scenarios.  I am wondering if you offer any
additional licenses for this project to be used in our commercial
setup without copy left clause.


The short answer is: No.

The longer answer is: To do this one would need to contact all of the
contributors/copyright holders and ask them to agree to a new license.
That is doable in theory but prohibitively difficult in practice.


I understand Linux Network Manager 1.16 support WPA3, does
NetworkManagerQt enables us to use WPA3 capabilities if we have a
compatible network manager installed on our embedded system?

Without knowing all of the details I'd say: yes, probably. And even if
there are missing things for this in networkmanager-qt those should be
easy enough to add.


A quick reply is highly appreciated.

Thanks

Sathya


Cheers

Nicolas

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

Moving kartesio to unmaintained

[Nicolas Fella]

Hi,

https://invent.kde.org/education/kartesio hasn't seen any substantial
development commit since 2015. I also do not see any other signs of
activity (distro packages, bug reports, user inquiries etc).

I propose we move it to unmaintained.

Cheers

Nico

Re: The KIPI fate

[Nicolas Fella]

On 4/19/22 22:10, Nate Graham wrote:

So we just got our first bug report about this:
https://bugs.kde.org/show_bug.cgi?id=452738

The reporter says he was using two plugins that still worked: one to
upload files to Google Drive, and one to print multiple images
arranged on a single piece of paper.

He notes that the Google Drive plugin is about to break in 6 weeks due
to security changes from Google. However the printing plugin seemed to
be still functional without an impending expiration date.

Nate


Note that Purpose, the designated alternative, supports Google Drive too.

Re: Reviewing the process for giving people commit rights

[Nicolas Fella]

On 4/1/22 17:28, Nate Graham wrote:

Hello folks,

When someone is proposed to get commit access, currently a sponsor
proposes it, the intended recipient contacts sysadmin, sysadmin
reviews, and then asks the sponsor if it's okay. This process
essentially only allows for sysadmin review, since the sponsor has
already implicitly approved by virtue of being the sponsor.

This caused a problem recently in KWin. A new contributor was given
commit rights very soon after he appeared, and then immediately after
that, he inappropriately merged a not-fully-reviewed an un-accepted
merge request
(https://invent.kde.org/plasma/kwin/-/merge_requests/1980). It seems
that he did not have a sense of the cultural norms around committing
to KDE repos, and giving him commit access was probably premature.

I'd like to propose that we need to make the commit access review
process open to review by more people so that we can flag issues like
this sooner. Maybe kde-core-devel?

Nate


I think this case shows more a lack of communication towards the person
in question what rights and responsibilities come with commit access
rather than a problem with the current review process. In other words,
other reviewers would likely not have prevented what has happened. It's
hard for any kind of reviewer to know whether the person to be reviewed
knows the social etiquette that comes with commit access.

To summarize: I don't see a need to change how applications are
reviewed, but perhaps there are steps we can integrate into the
application process to communicate better the social etiquette that
comes with commit access.

Cheers

Nico

Re: RKWard is in kdereview - again

[Nicolas Fella]

On 3/30/22 17:55, Thomas Friedrichsmeier wrote:

An update and some questions:

Am Mon, 28 Mar 2022 15:39:55 +0200
schrieb Nicolas Fella :
[...]

- Consider adding a color scheme selector (KColorSchemeManager) to the
menu. On Windows that gives you dark mode support for free (this only
really works nicely when using Breeze QStyle). See
https://invent.kde.org/utilities/kate/-/blob/master/kate/katemainwindow.cpp#L235

Done that. On my Windows 8.1 VM, I notice some strange behavior:
  - By default, Breeze dark is loaded, even though I have not customized
my color settings at all in this VM.


I think I know what's happening there. In
https://invent.kde.org/frameworks/kconfigwidgets/-/blob/master/src/windowsmessagesnotifier.cpp#L30
we query the registry for AppsUseLightTheme, but IIRC that only exists
with Windows 10. With Windows 8 we then get false, causing Breeze Dark
to get used. Should be trivial to fix by passing a different default to
QSettings.


  - Using the "Default" color scheme option switches to Breeze classic.
However, this setting is not permanent in that Breeze dark is again
active in the next session.


That would be https://bugs.kde.org/show_bug.cgi?id=452091


  - Setting one of the themes explicitly, seems to be saved / loaded,
correctly, though.

Well, that's Windows 8.1, not much worth worrying about, I guess.

What's troubling me more is that QWebEngineView (used, among other
things, for Help->Help on RKWard) does not adapt to the color theme at
all. I tried adding CSS rules (@media (prefers-color-scheme: dark)
{...}), but QWebEngine simply seems to be unaware of the color scheme
in use. Any ideas, what I may be missing?

(Interestingly, KF5WebKit, still in use on MinGW does adjust itself to
the theme.)

No idea about that.

- On Windows the title bar shows a generic icon instead of the RKWard
icon

Fixed.


- Consider publishing RKWard on the Microsoft Store

- Consider publshing RKWard on Flathub

First step:
https://invent.kde.org/packaging/flatpak-kde-applications/-/merge_requests/81

Regards
Thomas

Re: RKWard is in kdereview - again

[Nicolas Fella]

On 3/28/22 16:53, Adriaan de Groot wrote:

On Saturday, 26 March 2022 21:34:06 CEST Thomas Friedrichsmeier wrote:

KDE.org has been our home for a 7.5(!) years, now (after over a
decade on sourceforge), but we still haven't left playground... After a
lot of procrastination on that matter, a previous review failed due to
lack of time on my part. Sorry! Now, finally, I'd like to ask you to
start reviewing RKWard for inclusion into exragear / education, once
more.


...

RKWard is used productively on Linux/BSD, Mac, and Windows.

Congratulations! RKWard has been packaged on FreeBSD for a long time already
(although it's only at version 0.7.1, not the latest release -- cc'ing the
FreeBSD maintainer there).

On the FreeBSD side there's only two patches in packaging; one missing include
(not needed with current git) and a CMake thingy that I don't quite understand
(about gfortran). I do notice that there's a FindR.cmake in Cantor, and one in
RKWard, and they are somewhat different: perhaps some coordination to make
them both do the same (and the right) things?

[ade]


Talking about FreeBSD: I started adding Gitlab CI and the FreeBSD build
fails: https://invent.kde.org/education/rkward/-/jobs/274861, presumably
due to having a different tar implementation than Linux.

I'd appreciate if someone could comment/look into that

Cheers

Nico

Re: RKWard is in kdereview - again

[Nicolas Fella]

Hi,

I recently used RKWard for my Master Thesis, cool project!

A couple of observations:

- CommitPolicy.txt still mentions Phabricator, that should point to
Gitlab instead

- CommitPolicy.txt mentions Ubuntu Trusty as base for requirements, that
is *ancient* by now, maybe 20.04 would be a more reasonable base?

- The repo doesn't have Gitlab CI, that should be added

- Optional/nice-to-have: We tend to use SPDX indentifiers for license
headers these days, maybe think about converting the existing headers

- You are using QtScript, which is deprecated. What's your plan for that?

- I see you are distributing stable Windows releases, but there are no
stable build jobs for that on binary-factory.kde.org

- Consider adding links to the Windows releases to the appstream
metadata. That way they show up on apps.kde.org/rkward. See
https://invent.kde.org/utilities/kate/-/merge_requests/667 for an example.

- On Windows we tend to use the Breeze QStyle since that looks and works
quite a bit better than the "native" style. See
https://invent.kde.org/utilities/kate/-/blob/master/kate/main.cpp#L110

- Consider adding a color scheme selector (KColorSchemeManager) to the
menu. On Windows that gives you dark mode support for free (this only
really works nicely when using Breeze QStyle). See
https://invent.kde.org/utilities/kate/-/blob/master/kate/katemainwindow.cpp#L235

- On Windows the title bar shows a generic icon instead of the RKWard icon

- Consider publishing RKWard on the Microsoft Store

- Consider publshing RKWard on Flathub


Feel free to reach out for questions/help with any of this.

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

Re: KConfig saving mecanism for kcm

[Nicolas Fella]

On 04/02/2022 12:03, Antoine Gatineau wrote:

Hello dear kde developpers.

I am writing a kcm module for system settings and I have an issue saving the 
configuration. So I'm reaching out here.
I can use KConfig to save the data but is goes in .config/systemsettingsrc, 
merged with the rest of systemsettings data.

As I have multiple groups, I'd prefer to have a dedicated config file for my 
kcm.

Is KConfig able to do that? How?

Thank you for any information or pointer that would allow this behavior.
If this is not the right place for such questions, please tell me were to go.

Kind regards
Antoine


Hi,

when creating a KConfig object without arguments it chooses the config
file based on the app name, which is what you see here.

By passing a name with it you can choose the config file, e.g.
KConfig("mysettings") will save in .config/mysettings

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: How do you label code to be deleted in KF6?

[Nicolas Fella]

On 09/11/2021 09:26, Ahmad Samir wrote:

On 11/9/21 04:33, Glen Ditchfield wrote:

I would like to have some members of KCalendarCore's incidence classes
removed during the transition from KF5 to KF6, and I'd like to be sure
that the changes won't be missed in the excitement.

Do you have some preferred way to label such changes?  For example, is
there some `#if` statement that can be wrapped around the code, such
that it will be compiled into KF5 but compiled out of KF6?




Hello. We use deprecation macros, grep for DEPRECATED in any KF repo,
and see the manual pages for those macros (defined by
extra-cmake-modules), lots of examples in the repos already.


You can wrap it in the deprecation macros, but a '// TODO KF6 remove'
will do too

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: 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: 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: kpeoplevcard in kdereview

[Nicolas Fella]

On 14/06/2021 21:28, Albert Astals Cid wrote:

El dissabte, 12 de juny de 2021, a les 15:56:36 (CEST), Nicolas Fella va 
escriure:

Hi,

https://invent.kde.org/pim/kpeoplevcard is now in kdereview.

kpeoplevcard is a data source plugin for KPeople that provides contacts
based on VCard files on the disk. The 0.1 release has been in use in
plasma-phonebook and kdeconnect-sms for a while, but I just realized it
was never properly reviewed.

I did some cleanup work to bring the repo up to standards, but in
general the thing is rather "finished". There is a pending MR adding
full REUSE compliance waiting for approval from the copyright holders.

There's i18n but no Messages.sh nor -DTRANSLATION_DOMAIN= (assuming this is a 
lib or similar and it makes sense to use -DTRANSLATION_DOMAIN=)

Cheers,
   Albert


Thanks, fixed with
https://invent.kde.org/pim/kpeoplevcard/-/commit/c6a135a4714627977f9c1caee4a352c995e9

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

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

kpeoplevcard in kdereview

[Nicolas Fella]

Hi,

https://invent.kde.org/pim/kpeoplevcard is now in kdereview.

kpeoplevcard is a data source plugin for KPeople that provides contacts
based on VCard files on the disk. The 0.1 release has been in use in
plasma-phonebook and kdeconnect-sms for a while, but I just realized it
was never properly reviewed.

I did some cleanup work to bring the repo up to standards, but in
general the thing is rather "finished". There is a pending MR adding
full REUSE compliance waiting for approval from the copyright holders.

Cheers

Nico

Re: Can we get tags and tarballs for the KDE Qt patch collection

[Nicolas Fella]

On 07/06/2021 20:46, Nate Graham wrote:

Hello folks,

The Fedora packagers were mentioning to me today that it would be a
lot easier for them to ship Qt with our patch collection if we made
tags and tarballs. Is this something we could look into doing?

Nate



I think it would help the discussion to know what exactly of the status
quo is creating problems. The lack of tags/version number? That there is
no tarball on download.kde.org? The lack of notifying when distros
should update their package? Something else?

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.