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

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

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 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 18.01.23 um 23:58 schrieb Nicolas Fella:

Hi,

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

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

Those building manually please adjust your workflow accordingly.

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

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

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


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

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

- Drop build system code to build with Qt5

- Rename library/target names to KF6

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

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

Cheers

Nicolas

Frameworks master is Qt6 now

[Nicolas Fella]

Hi,

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

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

Those building manually please adjust your workflow accordingly.

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

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

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

Cheers

Nicolas

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

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: New Git Hooks Deployed

[Nicolas Fella]

On 17.01.21 11:30, Albert Astals Cid wrote:

El diumenge, 17 de gener de 2021, a les 11:07:40 CET, Johnny Jazeix va escriure:

Hi Ben,

https://build.kde.org/view/Failing/job/Applications/job/kaccounts-integration/job/kf5-qt5%20SUSEQt5.15/lastFailedBuild/console

CMake Error at CMakeLists.txt:50 (include):
include could not find load file:  KDEGitCommitHooks

Side effect or bad ECM minimal version?

That's kind "a different git hook", what Ben wrote about is something that runs 
on the git server, this error is about something that runs on the developer side.

This error is because Nico forgot that kaccounts-integration is not a KDE 
Framework and thus it would be really desirable for it to not depend on an 
unreleased version of extra-cmake-modules for the benefit of all of us that 
don't compile our own KDE Frameworks and just use released versions.


I've now added a version check that should fix the build with KF 5.78.
That does not fix the CI though since that seems to have
master-but-not-latest-master, i.e. it fails because it says it has 5.79
but does not have the relevant commit.

Cheers

Nico

Re: Failing KDiff3 build due to kf5 internal dependency issue

[Nicolas Fella]

On 1/16/21 1:51 AM, Michael Reeves wrote:

KDiff3 MacOS X build at binary factory is failing with the fallowing
error:

16:04:13  CMake Error at
/Users/packaging/Craft/BinaryFactory/macos-64-clang/dev-utils/cmake-base/CMake.app/Contents/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:218
(message):
16:04:13    Could NOT find QtWaylandScanner (missing:
QtWaylandScanner_EXECUTABLE)
16:04:13  Call Stack (most recent call first):
16:04:13
/Users/packaging/Craft/BinaryFactory/macos-64-clang/dev-utils/cmake-base/CMake.app/Contents/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:577
(_FPHSA_FAILURE_MESSAGE)
16:04:13
/Users/packaging/Craft/BinaryFactory/macos-64-clang/share/ECM/find-modules/FindQtWaylandScanner.cmake:78
(find_package_handle_standard_args)
16:04:13    CMakeLists.txt:43 (find_package)

This is blocking release.


Hi,

this should be fixed with
https://invent.kde.org/frameworks/kguiaddons/-/commit/c882980869631be94510c62905feef18cdb73267,
which is part of KF 5.78. I see binary-factory builds 5.77 so I suggest
to update that. Alternatively you can pass -DWITH_WAYLAND=OFF when
building KGuiAddons.

Cheers

Nico

Re: KDE review for KWeatherCore

[Nicolas Fella]

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

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

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

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

clarify:

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

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

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


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

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

Cheers

Nico

Re: plasma-mobile/plasma-dialer in kdereview

[Nicolas Fella]

On 12/19/20 11:31 PM, Albert Astals Cid wrote:

I was mega surprised that it listed my contacts, it really seems the contacts 
are coming from my google account? But i don't have kaccounts set up here, so 
where do they come from? Maybe kdeconnect synced them at some point? (i don't 
have kde connect running/synced at this moment).


That's most likely KDE Connect indeed. It dumps the contacts to
.local/share/kpeoplevcard and the dialer fetches them through KPeople

Cheers

Nico

Re: KDEReview for Kontrast

[Nicolas Fella]

Hi Carl,

a couple of nitpicks, otherwise looks neat.

- your CMakeLists.txt does not specify a minimum Qt/KF5 version. Also
ECM 0.0.8 is likely quite old and a bit optimistic

- Setting CMAKE_CXX_STANDARD to 11 is implicitly done by ECM, no need to
do that manually. It also contradicts the
target_compile_features(kontrast PRIVATE cxx_std_17) you set later

- You can save yourself the explicit call to qt5_add_resources by adding
resources.qrc to the add_executable call. This is called AUTORCC in
cmake and ECM enables it by default

- Instead of using QScopedPointer you should be able to just
put Kontrast on the stack

- consider setting "isMenu: true" on your global drawer, that turns it
into a hamburger menu on the desktop, which is more appropriate than a
drawer


Cheers

Nico

On 30.07.20 11:16, Carl Schwan wrote:

Hi,
I would like to move Kontrast, a contrast checker application, to KDEReview. 
Kontrast can check if two colors pass the WCAG 2.0 specification and save some 
user's favorite color combinations.

Some screenshots of the application and a design review from the VSG is 
available here: https://invent.kde.org/accessibility/kontrast/-/issues/1

 From a code point of view, the application is very simple, but I still would 
appreciate a general code review on it (it's my first Qt app written from 
scratch). The code is available here: 
https://invent.kde.org/accessibility/kontrast

I don't plan to add new features and would like after the KDEReview, to release 
a first version of the application, and then move it to the release service so 
that the application gets regularly translations improvement.

Thanks
Carl

Re: Kup in KDE Review

[Nicolas Fella]

On Montag, 6. April 2020 12:32:54 CEST Simon Persson wrote:
> Hello!
>
>
> Please help to review kup.
>
> It is a backup scheduler tightly integrated with plasma (has system
> setting kcm, systray plasmoid, kioslave). It supports saving backups
> either with bup or with rsync.
>
> It has been developed outside of KDE for many years and only now is
> being incubated.
>
> I am unsure if it should end up in extragear or some release service
> bundle. Perhaps people have an opinion on this?
>
> https://invent.kde.org/kde/kup
>
>
> Thanks,
>
> Simon

Hi,

I briefly skimmed trough the codebase. Looks all sane to me. A few minor 
observations:
- You may want to look into KConfigXT. It should be able to generate the 
classes from
settings/ from an XML description.
- You are using KInit for the daemon executable. We are looking into killing 
that in the KF6
transition (https://phabricator.kde.org/T12140[1] ) so consider it deprecated 
(although it is
not offically yet). If you do not care about using kup outside of Plasma you 
might also
consider implementing the daemon part as a kded module.
- In 
https://invent.kde.org/kde/kup/-/blob/master/filedigger/mergedvfsmodel.cpp#L60[2]
please check if instead of calling loadMimeTypeIcon simply returning the 
iconname is
enough, or return QIcon::fromTheme(name). loadMimeTypeIcon looks like a likely
candidate for deprecation/removal to me. That would also get rid of the 
KIconThemes
dependency.

Cheers

Nico




[1] https://phabricator.kde.org/T12140
[2] 
https://invent.kde.org/kde/kup/-/blob/master/filedigger/mergedvfsmodel.cpp#L60

Re: Urgent(ish) Contract KDE Developer availability?

[Nicolas Fella]

Hi Bernie,

have a look at the list of trusted consulting firms: 
https://ev.kde.org/consultants/[1]

Cheers

Nico

On Montag, 30. März 2020 07:23:04 CEST Bernard Gray wrote:
> Hi all,
> My name is Bernie, I work for an Australian Winemaking company and we
> have been KDE Users for many years now
> (https://dot.kde.org/2014/02/18/kde-software-down-under)
> 
> I apologise if this is the wrong platform to pose the question, but I
> wasn't sure where else would suit -
> 
> In short, due to COVID-19 we have rapidly had to transition our
> workforce to remote functions, and we're doing this by running a
> (actually, multiple) terminal server setup with xrdp.
> In the course of this migration, we have uncovered a number of bugs in
> multi-user KDE that are having a fairly significant impact on the
> functionality of this setup.
> 
> We'd like to contract one or more people to spend some time patching
> these issues (and potentially a few other issues which are impacting
> less heavily for now) - if you are able to, willing to, or especially
> are in need of some contract work due to loss of income from COVID-19,
> please get in touch.
> 
> The major bugs, in order of priority:
> 
> 1. Bug 418906 - UDI (Unique Device Identifier) provided by solid is
> not actually unique, entry gets overwritten
>  - https://bugs.kde.org/show_bug.cgi?id=418906
> This one is our current hardest hitter - every subsequent user that
> logs in overwrites the previous user's specific network mount point
> references in solid, and all the device shortcuts in the left pane of
> dolphin break for all other users. It is possible to workaround by
> navigating to specific folders, but this is causing a significant
> amount of extra support on an already lean and hard worked department
> and resolving this would be huge.
> 
> 2. Bug 347772 - kscreenlocker_greet using 100% cpu on plasma 5
>  - https://bugs.kde.org/show_bug.cgi?id=347772
> This is longstanding, but it hits us on a per user basis. Once a few
> users have logged in, timed out and the screensaver started up, 10-15%
> cpu * user adds up very quickly and the machine gradually maxes out
> each core. I've had to workaround this by disabling the screensaver
> altogether on the terminal server.
> 
> Thanks for your time - once again, apologies if this was an
> inappropriate place to post, please direct me to a more suitable
> platform if so.
> 
> Regards,
> Bernard Gray




[1] https://ev.kde.org/consultants/

Re: KTrip in kdereview

[Nicolas Fella]

On Sonntag, 27. Oktober 2019 15:29:10 CET Nicolas Fella wrote:
> Hi,
>
> KTrip (https://invent.kde.org/kde/ktrip) has been moved to kdereview.
>
> KTrip is a public transport assistant based on KPublicTransport targeted
> towards Plasma Mobile and Android. Currently it supports querying journeys
> between two locations as well as departures for a location but more advanced
> features are possible in the future.
>
> Nightly builds for Android are available on the binary factory (https://
> binary-factory.kde.org/view/Android/job/KTrip_android/).
>
> Destination would be extragear for now, but whatever comes out of KDE
> Applications might make sense.
>
> Cheers
>
> Nico

Thanks for the feedback, it has all been addressed. Since way more than two
weeks passed and there hasn't been any objections I will move it to extragear/
utils now.

Thanks

Nico

Re: KTrip in kdereview

[Nicolas Fella]

On Mittwoch, 30. Oktober 2019 08:57:19 CET Christophe Giboudeaux wrote:
> On dimanche 27 octobre 2019 15:29:10 CET Nicolas Fella wrote:
> > Hi,
> >
> > KTrip (https://invent.kde.org/kde/ktrip) has been moved to kdereview.
>
> Some files don't have a license header (ClockFace.qml, DateInput.qml,
> TimezoneTable.qml, plugin.cpp).
>
>
> Christophe

Fixed, sorry for the delay

Nico

Re: KTrip in kdereview

[Nicolas Fella]

On Dienstag, 29. Oktober 2019 23:25:44 CET Albert Astals Cid wrote:
> El diumenge, 27 d’octubre de 2019, a les 15:29:10 CET, Nicolas Fella va 
escriure:
> You're not calling
>   KLocalizedString::setApplicationDomain
> as far as i can see so translations won't work.
Fixed.

> It would be good for it to use feature_summary so instead of a hard to read
> error http://paste.debian.net/810/ one would get the nice summary with
> "you're missing this required package, find it here"
I'm using feature_summary. What should I do differently?
> Is running on the desktop supposed to work? http://paste.debian.net/811/
Yes. I've fixed most of the warnings about Android stuff. There's still a few 
left, needs a closer look from me.
> The time picker looks megaweird on the desktop
> https://i.imgur.com/ksBMhzj.png
Agreed. I didn't do that myself, it's a copy and paste from Calindori. We need 
to sit down with VDG and design something and then implement is in a proper 
lib.
> What's the 3rd box here supposed to be? https://i.imgur.com/PQMvsgP.png Is
> it "wait there for a bit"?
yes, waiting or transfer. I fixed the appearance a bit, but it's still not the 
most beautiful design
> Cheers,
>   Albert
> 
Thanks,

Nico

Re: KTrip in kdereview

[Nicolas Fella]

On Mittwoch, 30. Oktober 2019 12:04:55 CET Jonathan Riddell wrote:
> There's a file called LICENSE with the text of the GPL 2.  We usually call
> this COPYING in KDE.
>
> Some of the source code files are under the LGPL 2+ so there should be a
> copy of that licence too usually in a file called COPYING.LIB
>
I added COPYING and COPYING.LIB

Nico

Re: KTrip in kdereview

[Nicolas Fella]

On Mittwoch, 30. Oktober 2019 08:57:19 CET Christophe Giboudeaux wrote:
> On dimanche 27 octobre 2019 15:29:10 CET Nicolas Fella wrote:
> > Hi,
> >
> > KTrip (https://invent.kde.org/kde/ktrip) has been moved to kdereview.
>
> Some files don't have a license header (ClockFace.qml, DateInput.qml,
> TimezoneTable.qml, plugin.cpp).
Those file are not my code. I will contact the authors and ask for
clarification.

Nico

KTrip in kdereview

[Nicolas Fella]

Hi,

KTrip (https://invent.kde.org/kde/ktrip) has been moved to kdereview.

KTrip is a public transport assistant based on KPublicTransport targeted
towards Plasma Mobile and Android. Currently it supports querying journeys
between two locations as well as departures for a location but more advanced
features are possible in the future.

Nightly builds for Android are available on the binary factory (https://
binary-factory.kde.org/view/Android/job/KTrip_android/).

Destination would be extragear for now, but whatever comes out of KDE
Applications might make sense.

Cheers

Nico

Re: Move pulseaudio-qt to Extragear

[Nicolas Fella]

I've fixed the remaining clazy warnings.

Cheers

Nicolas

On Mittwoch, 7. November 2018 00:48:31 CET Albert Astals Cid wrote:
> 
> I proposed some small clazy fixes, but there's some more warnings that may
> make sense having a look over.
> 
> https://paste.kde.org/p5lhjhosn
> 
> Cheers,
>   Albert

Move pulseaudio-qt to Extragear

[Nicolas Fella]

Hi,

together with David Rosca and Aleix Pol I have worked on extracting the 
libpulse abstraction from plasma-pa into a library [0][1]. It is 
currently optionally required by KDE Connect. plasma-pa and 
libtaskmanager will use it at some point in the future. Long-term plan 
is to move it to Frameworks, but until the required documentation and 
testing is done I'd like to move it to Extragear and make an initial 
release.


Cheers

Nicolas

[0] https://phabricator.kde.org/T7994

[1] https://cgit.kde.org/pulseaudio-qt.git