Re: Qrca in KDE review

[Aleix Pol]

On Sun, Oct 22, 2023 at 6:15 PM Jonah Brüchert  wrote:
>
> Hi everyone!
>
>
> I moved Qrca to KDEReview.
>
> It is a QR-Code scanner and generator for mobile and desktop devices. It
> is based on Prison and QtMultimedia.
>
> The repository is located here: https://invent.kde.org/utilities/qrca/
>
> If you find anything that needs changing, please comment on the issue
> here: https://invent.kde.org/utilities/qrca/-/issues/11

How good an idea is the name itself? How do you even pronounce it? :D

Also it could be mistaken with Orca.

Aleix

Re: Marknote KDE review (again)

[Aleix Pol]

It already seems to be part of KDE so it doesn't need a review to
enter KDE Review, KDE Review is already a review process in itself.
https://community.kde.org/Policies/Application_Lifecycle

Aleix

On Wed, Oct 4, 2023 at 9:50 PM Mathis Brüchert  wrote:
>
> Hello,
>
> could you please  review https://invent.kde.org/office/marknote/ so that it 
> can be moved to Kde review?
>
> It is a small note taking app saving your notes to Markdown files.
>
> here is the issue: https://invent.kde.org/office/marknote/-/issues/24
>
> thanks in advance.

Re: XWayland Video Bridge in kdereview

[Aleix Pol]

I'm not so sure. Is the fact that it works on a non-Plasma system by
design or just a happy coincidence?

On Tue, Jul 4, 2023 at 3:03 PM Neal Gompa  wrote:
>
> On Fri, Jun 30, 2023 at 7:09 AM Ben Cooksley  wrote:
> >
> > On Fri, Jun 30, 2023 at 10:01 AM Aleix Pol  wrote:
> >>
> >> On Mon, Jun 19, 2023 at 10:00 PM Jonathan Riddell  
> >> wrote:
> >> >
> >> > I got this compiling on neon unstable.  Our kpipewire is qt6 so I'm not 
> >> > sure how that affects it.  I don't have a way to test it quickly though.
> >> > https://build.neon.kde.org/job/jammy_unstable_neon-packaging_xwaylandvideobridge/
> >>
> >> The Qt 6 port is still ongoing:
> >> https://invent.kde.org/system/xwaylandvideobridge/-/merge_requests/11
> >>
> >> > How come it's in the system group on invent if you want it to be part of 
> >> > Plasma?
> >>
> >> To be honest, the invent groups are a mystery to me.
> >
> >
> > That is of some degree of concern that you don't understand the groupings.
> >
> > For the most part the groups are intended to reflect to an extent how the 
> > software relates to each other. You will find all of the Educational 
> > software under Education for instance, and all Games in Games.
> > Likewise, applications for handling images and other similar content are in 
> > Graphics, those that deal with video and audio are in Multimedia and 
> > libraries for use by other developers are in Libraries.
> >
> > All fairly straightforward I would have hoped.
> >
> > The reason for the placement of the XWayland Video Bridge comes back to the 
> > initial ticket that requested it be moved from a personal repository - 
> > which you filed Aleix.
> > This was targeting Graphics, which is clearly inappropriate as it would 
> > have put it alongside Krita and Digikam. For want of a better place as it 
> > was a bit of infrastructure / behind the scenes tooling it was therefore 
> > put in System.
> >
> > There was never any mention in the ticket that it was going to be exclusive 
> > to Plasma and not usable outside of a Plasma setting, hence why that was 
> > not considered.
> >
>
> It is supposed to be useful outside of KDE Plasma too, so that
> assumption is correct.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!

Re: XWayland Video Bridge in kdereview

[Aleix Pol]

On Mon, Jun 19, 2023 at 10:00 PM Jonathan Riddell  wrote:
>
> I got this compiling on neon unstable.  Our kpipewire is qt6 so I'm not sure 
> how that affects it.  I don't have a way to test it quickly though.
> https://build.neon.kde.org/job/jammy_unstable_neon-packaging_xwaylandvideobridge/

The Qt 6 port is still ongoing:
https://invent.kde.org/system/xwaylandvideobridge/-/merge_requests/11

> How come it's in the system group on invent if you want it to be part of 
> Plasma?

To be honest, the invent groups are a mystery to me.

Aleix

Re: XWayland Video Bridge in kdereview

[Aleix Pol]

On Fri, Jun 16, 2023 at 10:31 PM Albert Astals Cid  wrote:
>
> El divendres, 16 de juny de 2023, a les 18:43:59 (CEST), Aleix Pol va
> escriure:
> > Hi Everyone,
> > As discussed by david in his blog post [1], we worked on the component
> > in question to solve the problem of X11 applications that want to use
> > the screencasting services on Wayland.
> >
> > https://invent.kde.org/system/xwaylandvideobridge
> >
> > While there's some corners to polish here and there, it's ready to be
> > used by everyone who needs it. In fact, people are using it from the
> > flatpak and distros want to ship it so we should probably make it
> > easier and regulated through a proper release.
>
> CI seems borked
>
> https://invent.kde.org/system/xwaylandvideobridge/-/merge_requests/9
>
> Cheers,
>   Albert
>
> >
> > First it should go through kdereview, then I'd suggest starting to
> > release it with Plasma 5.27 in one of the minor releases. I don't
> > think it's something we have done before but it doesn't add new
> > dependencies and it has an impact in our product offering which is,
> > incidentally, frozen due to the switch to *6.
> >
> > I would appreciate the review of the module, I guess the "how to
> > release it" is something we can discuss in a couple of weeks once this
> > is sorted.
> >
> > Thanks everyone!
> > Aleix
> >
> > [1] https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/

Addressed, thanks!

https://invent.kde.org/system/xwaylandvideobridge/-/merge_requests/10

Aleix

XWayland Video Bridge in kdereview

[Aleix Pol]

Hi Everyone,
As discussed by david in his blog post [1], we worked on the component
in question to solve the problem of X11 applications that want to use
the screencasting services on Wayland.

https://invent.kde.org/system/xwaylandvideobridge

While there's some corners to polish here and there, it's ready to be
used by everyone who needs it. In fact, people are using it from the
flatpak and distros want to ship it so we should probably make it
easier and regulated through a proper release.

First it should go through kdereview, then I'd suggest starting to
release it with Plasma 5.27 in one of the minor releases. I don't
think it's something we have done before but it doesn't add new
dependencies and it has an impact in our product offering which is,
incidentally, frozen due to the switch to *6.

I would appreciate the review of the module, I guess the "how to
release it" is something we can discuss in a couple of weeks once this
is sorted.

Thanks everyone!
Aleix

[1] https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/

Re: sentry evaluation

[Aleix Pol]

I think it has been a good tool. There's some problems that are simply
too hard to report using bugzilla and these can be analyzed
accordingly. In the end, they are all problems that exist and users
face. I understand it's a problem that we don't really get the context
in these but maybe it's just a price to pay.

I'm sure there's still room for improvement, but I'm sure there's
crashes we don't have now because our devs have seem there that they
appear and addressed them, even if from a theoretical perspective.

Aleix

On Thu, Jun 1, 2023 at 12:36 PM Harald Sitter  wrote:
>
> Hey,
>
> We've had almost a year, albeit in a super limited capacity for git
> builds, with sentry (https://errors-eval.kde.org) and we should
> probably render a final verdict on the evaluation.
>
> Did you like it?
> What could be improved?
> Should we move ahead with a more permanent setup?
>
> The overall game plan would be to have drkonqi ask the user to opt
> into automatic crash submission when they open drkonqi so we get close
> to all crashes (the ones caught by kcrash) automatically filed into
> sentry from then on out. To increase exposure of this feature I'd also
> like to glue it into the feedback KCM but I'm not yet sure if it
> should be a separate setting or linked to the regular feedback
> categories, the former sounds more accessible. The current bugzilla
> based workflow would still be available for when the user actually
> wants to write a description.
>
> (previous discussion: https://markmail.org/thread/6y5paczdposz3aoj)
>
> HS

Re: RFC: an improved ki18n_install

[Aleix Pol]

On Mon, Mar 6, 2023 at 8:31 PM Milian Wolff  wrote:
>
> Hey all,
>
> for context please see [1] and [2].
>
> [1]: https://bugs.kde.org/show_bug.cgi?id=460245
> [2]: https://discourse.cmake.org/t/feature-request-add-custom-command-all/7609
>
> The gist is that me and Igor are annoyed by `ki18n_install` abusing
> `add_custom_target`, which makes the build always dirty. I.e. every time we
> run `ninja` we will, at the very least, run the two mo & ts generation
> targets. For kdevelop, these do non-trivial amounts of work that takes time
> even on a beefy laptop:
>
> ```
> $ ninja && time ninja
> [2/2] Generating mo...
> [2/2] Generating mo...
>
> real0m1,780s
> user0m5,742s
> sys 0m2,327s
> ```
>
> I would like to fix this, but first want to get feedback from the KDE
> developers at large.
>
> First of all: Are all projects using ki18n_install in the way we do? Why is
> no-one else complaining about this so far? Are your po files so small that
> this doesn't take a significant amount of time? Or are there potentially just
> so few of them in your project? KDevelop is heavily plugin based which means
> we have tons of po files. 2464 *.po files to be exact...
>
> Secondly: does anyone know how to best approach a solution to this issue? The
> problem is that I don't see an easy way to solve it: While Kyle Edwards was
> nice enough to show me a way to tell CMake to not make the custom target
> always-dirty, `k18n_install` suffers from another design deficiency: It uses
> globbing internally and has an undefined amount of inputs and outputs, which
> basically makes it impossible for us to leverage `add_custom_command(OUTPUT`
> here, or?
>
> As such, it seems like one would need a different approach to this problem
> anyways. Globbing is a known-evil in cmake land, and I would personally prefer
> to have the inputs explicitly listed, just like we do for source files etc.
> Because we have many languages though, listing all possible *.po or *.ts files
> is cumbersome. Instead, what about we maintain the list of known languages in
> the ki18n framework? Then we could have something like
>
> ```
> ki18n_target(
> # the target for which we are handling messages
> TARGET KF5I18n
> # the translation domain, added as compile_options and to find files
> TRANSLATION_DOMAIN ki18n5
> # the root po folder location, to look for the .po/.js files
> PO_FOLDER ${KI18n_SOURCE_DIR}/po
> )
> ```
>
> Internally, this would do what is currently done manually:
>
> ```
> target_compile_options(KF5I18n PRIVATE -DTRANSLATION_DOMAIN=\"ki18n5\")
> ```
>
> Then it would iterate over the list of known languages and try to find the .po
> or .js file. For every match, we would add_custom_target to generate the
> corresponding .mo/.ts file and add the reverse dependency.
>
> What do others say to this approach?
>
> Thanks
>
> --
> Milian Wolff
> http://milianw.de
>
>

+1 to getting the problem solved. I've also been bothered by this and
thought about looking into this so thanks for stepping up! (also I'm
pretty sure this code is originally mine from a time when we didn't
generate translations on every single build ^^').

Having ninja/make do this dependency generation can end up being more
work than worth it because then we need to have a static list and then
we need to re-run it when the po files change and it's all a mess. How
about changing build-pofiles/build-tsfiles to only execute the process
if the origin file is newer than the target?

I've put together a MR to explain what I meant (and I guess out of
guilt for having produced this :D)
https://invent.kde.org/frameworks/ki18n/-/merge_requests/81

Aleix

Re: KUnifiedPush in KDE Review

[Aleix Pol]

Fair enough. For what it's worth, +1 from my side. This is something
super necessary.

Let's decide where it ends up landing when it's a good moment to
decide. At the moment, considering Plasma 5 is frozen sine die, we
better keep it outside of it all. IMO.

Thanks!
Aleix

On Wed, Feb 8, 2023 at 6:15 PM Volker Krause  wrote:
>
> On Mittwoch, 8. Februar 2023 13:11:52 CET Aleix Pol wrote:
> > On Tue, Feb 7, 2023 at 6:36 PM Volker Krause  wrote:
> > > Hello everyone,
> > >
> > > I'd like to get KUnifiedPush
> > > (https://invent.kde.org/libraries/kunifiedpush) through KDE Review.
> > >
> > > KUnifiedPush contains the client-side building blocks we need for making
> > > use of the UnifiedPush (https://unifiedpush.org/) push notification
> > > standard.
> > >
> > > In particular there are three parts:
> > > - an application-side client library
> > > - a client-side push notification daemon ("distributor")
> > > - a KCM to configure the preferred push provider and to see registered
> > > applications
> > >
> > > We might want to split out the application-side part eventually, to not
> > > mix
> > > platform and framework parts, but that shouldn't affect the review.
> > >
> > > Open issues:
> > > - this is only working for the D-Bus part of the UnifiedPush spec, there
> > > is a start of an Android implementation but that is still non-functional
> > > if the app isn't running while the platform receives a push notification.
> > > That needs some understanding of both the Qt <-> Android integration and
> > > the Android mechanisms around broadcast receivers and the restrictions on
> > > those, help very much welcome.
> > > - while this is generally functional and usable, actual deployment is also
> > > depending on having a default push provider (the server side part). There
> > > have been a few discussions at FOSDEM on how to progress that.
> > >
> > > For more background, there has been an Akademy talk on this, and there is
> > > a
> > > writeup of that here:
> > > https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.htm
> > > l.
> > >
> > > Thanks!
> > > Volker
> >
> > Hi Volker,
> > This sounds great, super encouraging to see progress on this front!
> >
> > I was wondering, what's the reason to include this in libraries rather
> > than frameworks directly? Is it because of the current state of KDE
> > Frameworks transition?
>
> unclear policies regarding adding things to the frameworks group mainly, when
> I use frameworks directly I get told to use something else, when I use
> something else I get told to use frameworks :)
>
> > I see that KUnifiedPush already sees itself as
> > tier 1 (which is probably also something to address since it has a
> > number of KF dependencies).
>
> The application-side part is only depending on Qt::DBus so far, the extra KF
> dependencies are for the KCM. Splitting would fix that as well.
>
> Following discussions with the UnifiedPush team about push message encryption
> OpenSSL might become an additional dependency. Technically message encryption
> is something to be solved on the application layer, UnifiedPush just passes on
> opaque messages and thus can't ensure encrypted content. But it's probably a
> good idea to have a recommended default implementation around (RFC 8188/HTTP
> ECE).
>
> > Splitting it would make sense, but I understand this is something to
> > happen at least with Plasma 6 as Plasma 5 is feature frozen.
>
> Right. There's no time pressure as we need the server side sorted out as well
> anyway. The only reason this is still mainly 5-focused is that it started
> early last year already.
>
> A split would look like this I guess:
> frameworks/kunifiedpush - containing src/client, src/interfaces and 
> src/shared,
> with the latter turned into public API.
> plasma?/kunifiedpush-distributor - containing everything else, and a copy of
> src/interfaces, and depending on frameworks/kunifiedpush for what's now in 
> src/
> shared.
>
> Regards,
> Volker

Re: KUnifiedPush in KDE Review

[Aleix Pol]

On Tue, Feb 7, 2023 at 6:36 PM Volker Krause  wrote:
>
> Hello everyone,
>
> I'd like to get KUnifiedPush (https://invent.kde.org/libraries/kunifiedpush)
> through KDE Review.
>
> KUnifiedPush contains the client-side building blocks we need for making use 
> of
> the UnifiedPush (https://unifiedpush.org/) push notification standard.
>
> In particular there are three parts:
> - an application-side client library
> - a client-side push notification daemon ("distributor")
> - a KCM to configure the preferred push provider and to see registered
> applications
>
> We might want to split out the application-side part eventually, to not mix
> platform and framework parts, but that shouldn't affect the review.
>
> Open issues:
> - this is only working for the D-Bus part of the UnifiedPush spec, there is a
> start of an Android implementation but that is still non-functional if the app
> isn't running while the platform receives a push notification. That needs some
> understanding of both the Qt <-> Android integration and the Android
> mechanisms around broadcast receivers and the restrictions on those, help very
> much welcome.
> - while this is generally functional and usable, actual deployment is also
> depending on having a default push provider (the server side part). There have
> been a few discussions at FOSDEM on how to progress that.
>
> For more background, there has been an Akademy talk on this, and there is a
> writeup of that here: 
> https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.html.
>
> Thanks!
> Volker

Hi Volker,
This sounds great, super encouraging to see progress on this front!

I was wondering, what's the reason to include this in libraries rather
than frameworks directly? Is it because of the current state of KDE
Frameworks transition? I see that KUnifiedPush already sees itself as
tier 1 (which is probably also something to address since it has a
number of KF dependencies).

Splitting it would make sense, but I understand this is something to
happen at least with Plasma 6 as Plasma 5 is feature frozen.

Aleix

Re: KJournald in KDE-Review

[Aleix Pol]

On Tue, Oct 11, 2022 at 9:47 PM Andreas Cord-Landwehr
 wrote:
>
> On Montag, 10. Oktober 2022 15:34:30 CEST Aleix Pol wrote:
> > On Sun, Oct 9, 2022 at 7:18 PM Andreas Cord-Landwehr
>  [...]
> > > Even though KJournald is currently contained in the "libraries" playground
> > > module, I would like to get it included in the "utilities" module after
> > > passing KDE Review. The reason is that at the moment I more focus on the
> > > application part and that is the most user-facing part. Having it in
> > > "utilities" thus will avoid confusion.
> > >
> > > Looking forward for your review comments!
> >
> > I'm a bit confused by the context.
> >
> > It's placed in libraries although it seems like system would be the
> > place for it.
> > https://invent.kde.org/system
> >
> > I see there's a library, are you planning on maintaining compatibility
> > there? Are there other users? If there's no users outside, it could
> > make sense to skip installing headers until there is a use-case,
> > otherwise you might see yourself tied to an ABI unnecessarily.
>
> Yes, the https://invent.kde.org/system module sounds actually to be the best
> place for the app; I wrote "utilities" in the original mail, but agree that
> system is even better.
>
> I myself have use cases to use the library part as a library. Yet that is not
> for a public project. I could introduce a build option to only install headers
> optionally (default being OFF), which might makes it more clear to packagers
> that currently they do not have to package the headers. Moreover, at the
> moment their is not yet a fully stable API for the library, which is probably
> another good reason to not install headers by default.
>
> In the mid-term/long-run, I am planning to provide a stable API for the
> library.

Then I'd recommend to only make it public API when the time comes. :)

+1 to making it optional instead, if it makes your life any better.
That said, when we've needed this kind of flexibility in the past, we
have often ended up splitting the repository into a separate one, not
sure it would make sense here.

Also it would be useful to know what your plans are. :D

Aleix

Re: KJournald in KDE-Review

[Aleix Pol]

On Sun, Oct 9, 2022 at 7:18 PM Andreas Cord-Landwehr
 wrote:
>
> Hi, after a few releases over the past year, I would like to get KJournald
> included in KDE application releases. This project is about providing both an
> QItemModel abstraction library for the C-style journald API and providing an
> efficient graphical browser for journald logs.
>
> Sysadmins moved the repository to KDE Review today, you can find the source
> code here:
>
> https://invent.kde.org/libraries/kjournald
>
> (flatpack packaging is also available for easy trying it out)
>
> Even though KJournald is currently contained in the "libraries" playground
> module, I would like to get it included in the "utilities" module after
> passing KDE Review. The reason is that at the moment I more focus on the
> application part and that is the most user-facing part. Having it in
> "utilities" thus will avoid confusion.
>
> Looking forward for your review comments!

I'm a bit confused by the context.

It's placed in libraries although it seems like system would be the
place for it.
https://invent.kde.org/system

I see there's a library, are you planning on maintaining compatibility
there? Are there other users? If there's no users outside, it could
make sense to skip installing headers until there is a use-case,
otherwise you might see yourself tied to an ABI unnecessarily.

Aleix

Re: Telemetry in Plasma and Discover

[Aleix Pol]

It was discussed here:
https://mail.kde.org/pipermail/kde-core-devel/2020-November/091049.html

Aleix

On Tue, Jul 12, 2022 at 1:53 AM Nate Graham  wrote:
>
> Hello all,
>
> It's come to my attention that Plasma and Discover implemented support
> for opt-in-telemetry without complying with the requirements listed at
> https://community.kde.org/Policies/Telemetry_Policy#Compliance. The
> Request for review was done solely in a merge request, not also on these
> mailing lists.
>
> I am retroactively emailing the kde-core-devel and kde-community mailing
> lists to request review of the telemetry support in these KDE products
> so that we can be in compliance with our own policies, should the review
> be positive and use of opt-in telemetry continues.
>
> Relevant commits:
> -
> https://invent.kde.org/plasma/plasma-workspace/-/commit/15dd744a3ba42cecc04f3e7a51148e9be3345c6d
> -
> https://invent.kde.org/plasma/discover/-/commit/f1f1597f4f2ea3870456a2f2ed184f9ebfc62bc3
> - https://phabricator.kde.org/D5961
>
> Nate

Re: KPipeWire in kdereview

[Aleix Pol]

On Mon, May 30, 2022 at 3:44 PM Albert Astals Cid  wrote:
>
> El dilluns, 30 de maig de 2022, a les 14:55:55 (CEST), Aleix Pol va escriure:
> > 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
>
> It needs a Messages.sh

Added

> This signal is never emited?
>   void cursorModeChanged(Screencasting::CursorMode cursorMode);

Addressed.
>
> This property NOTIFY signal is wrong?
>   Q_PROPERTY(QString outputName READ outputName WRITE setOutputName NOTIFY 
> uuidChanged)
>

Addressed.

> The 3 signals in ScreencastingStream are never emitted?

they are emitted from ScreencastingStreamPrivate, the overriden
methods from the qtwayland generated code.

>
> PipeWireCore header is installed but not exported. If you export it, it will 
> need a d-pointer

Not installed anymore.

> PipeWireSourceItem is exported but has no d-pointer

Not installed anymore.

Left it to only install PipeWireSourceStream for now, which is the one
that is useful when you don't want to do QML.

Aleix

Re: KPipeWire in kdereview

[Aleix Pol]

> - xdp-recordme probably shouldn't be installed (by default)?

Thing is you need the test to be installed to work to request more
privileges to KWin. I guess we could default to BUILD_TESTING=OFF?

The rest of the points here are either addressed in master.

On Mon, May 30, 2022 at 3:17 PM Nicolas Fella  wrote:
>
> 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

KPipeWire in kdereview

[Aleix Pol]

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

Re: Git merge workflow: reverse it?

[Aleix Pol]

On Tue, May 10, 2022 at 9:36 AM Kai Uwe Broulik  wrote:
>
> Hi,
>
> can we get an update on this?
>
> Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and
> frustrating when some projects use cherry-pick (e.g. Kate) and some
> don't (e.g. Dolphin).
>
> I don't really mind what the outcome is but I need it to be consistent
> and predictable where to target my MRs, at least for every domain
> (Plasma, Gear, ..).
>
> Cheers
> Kai Uwe
>
> PS: Since I can never remember: it's git rebase --onto newbase oldbase
> branch
>
> Am 29.07.20 um 14:01 schrieb Bhushan Shah:
> > Hello everyone!
> >
> > At plasma, we are experimenting with new workflow regarding how bugfixes
> > are put on the stable branch [1].
> >
> > # Previous workflow
> >
> > - Current workflow is that we commit to stable branch and then merge it
> >upwords until master branch
> > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then
> >master
> >
> > # Current workflow
> >
> > - Proposed workflow is to instead commit all changes in master, and
> >cherry-pick related changes in the stable branch as needed
> > - We had been using this workflow for about 1 month now and I'd say it
> >is working nicely for us.
> >
> > # Why?
> >
> > We occasionally hit several issues with previous workflow,
> >
> > - Merge conflicts when merging changes upwords
> > - Changes which are valid only for stable branch needs to be reverted in
> >master branches. So you end-up with, stable-fix, revert of stable fix
> >and then different fix and overall weird history.
> > - Accidential merges from the master branch to stable branch which
> >needs to be force-resetted.
> > - It's worth noting that Qt also recently changed to merge to dev,
> >cherry-pick backwards.
> > - This also allows for workflows where we want to commit some bugfix in
> >the master branch for few days/weeks and if it works fine in general
> >testing then, cherry-pick it in stable branches.
> >
> > Proposal is to probably adapt this policy kde-wise if people feel that
> > advantages are worth it.
> >
> > Thanks
> >
> > [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html
> >

After having worked with using the Plasma workflow of cherry-picking
into stable (and especially since switching to gitlab) I don't really
see ourselves using something else.

As far as I remember it's worked great, it's super easy to implement
and I don't really remember things going worse but it sure is simpler
to track as a developer (and maintainer).

Aleix

Re: Should we consider project basenames unique?

[Aleix Pol]

On Wed, Nov 24, 2021 at 2:10 AM ash...@linuxcomp.ru  wrote:
>
> Hello.
> There is currently a problem that projects are identified by path in 
> invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo twice, 
> first time to the dir with pkgbuild, and second time to the srcdir for build 
> package. And that second repo has first repo as origin, i.e. its origin is 
> path to the first repo. And this leads to breakage of determining project 
> identifier in cmake module. To workaround, I either need to clone to the path 
> that matches the regexp, such as crutch.kde.org:pim/zanshin.git or fixing the 
> origin of the problem.
>
> I wanted to fix it by identifying the project by its name. See 
> https://invent.kde.org/sdk/releaseme/-/merge_requests/13.
>
> Now, the question is, could we consider project names unique? In that case, 
> we can merge my mr, and path crutch will not be needed anymore.

I agree it would be a problem to have different repositories with the
same name. I'm not sure how we can enforce it though.

Aleix

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Fri, Sep 24, 2021 at 8:26 PM Ben Cooksley  wrote:
>
> On Sat, Sep 25, 2021 at 12:34 AM Aleix Pol  wrote:
>>
>> On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez
>>  wrote:
>> >
>> > El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) 
>> > escribió:
>> > >
>> > > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
>> > >  wrote:
>> > > >
>> > > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
>> > > > escribió:
>> > > > >
>> > > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  
>> > > > > wrote:
>> > > > > >
>> > > > > > Hi all,
>> > > > > >
>> > > > > > It has recently come to our attention that the number of queries 
>> > > > > > being handled for the endpoint 
>> > > > > > https://autoconfig.kde.org/ocs/providers.xml on a day to day basis 
>> > > > > > has gotten to the point where it is causing issues with server 
>> > > > > > responsiveness to other traffic. This is perhaps best summarised 
>> > > > > > by the following:
>> > > > > >
>> > > > > > root@nicoda /var/log/apache2 # ls -lah ...
>> > > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
>> > > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
>> > > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
>> > > > > >
>> > > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
>> > > > > > 4,222,343
>> > > > > >
>> > > > > > Based on those numbers we're looking at 48-49 requests per second 
>> > > > > > (on average - peaks are much higher by many magnitudes), which 
>> > > > > > seems extremely excessive given that this file is only supposed to 
>> > > > > > be retrieved by KDE software when GHNS functionality is triggered. 
>> > > > > > That is supported by the substantial size difference it has over 
>> > > > > > networkcheck.kde.org - which is used by plasma-nm and 
>> > > > > > NetworkManager (on Neon) to check for whether they have a working 
>> > > > > > internet connection - which i'd expect to be the site receiving 
>> > > > > > the most traffic.
>> > > > > >
>> > > > > > As such, I therefore suspect we have bug(s) in software that makes 
>> > > > > > use of GHNS functionality.
>> > > > > >
>> > > > > > It would therefore be appreciated if we could please review the 
>> > > > > > software in question to determine whether it is operating 
>> > > > > > correctly. Given that it usually runs in the background on user 
>> > > > > > systems, i'd especially appreciate it if a detailed review could 
>> > > > > > be conducted on Discover and other software that conducts package 
>> > > > > > management operations or assists in managing updates.
>> > > > > >
>> > > > > > Unfortunately all these applications submit a fairly useless user 
>> > > > > > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain 
>> > > > > > any further information. If we could get information on the 
>> > > > > > software that is originating the request added to the user agent 
>> > > > > > to assist in investigating these issues in the future that would 
>> > > > > > be extremely helpful.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Ben
>> > > > >
>> > > > > That's correct. Discover fetches them at startup. It's necessary to 
>> > > > > be
>> > > > > able to check if there are updates on KNS-provided resources.
>> > > > >
>> > > > > Incidentally,  I was looking into this yesterday incidentally. We
>> > > > > could see if caching is broken somehow. A request will still be 
>> > > > > needed
>> > > > > though to check if the cache is out of date.
>> > > >
>> > > > Caching seems to be working, since the v

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Fri, Sep 24, 2021 at 1:32 AM Nicolás Alvarez
 wrote:
>
> El jue, 23 de sep. de 2021 a la(s) 19:31, Aleix Pol (aleix...@kde.org) 
> escribió:
> >
> > On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
> >  wrote:
> > >
> > > El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> > > escribió:
> > > >
> > > > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > It has recently come to our attention that the number of queries 
> > > > > being handled for the endpoint 
> > > > > https://autoconfig.kde.org/ocs/providers.xml on a day to day basis 
> > > > > has gotten to the point where it is causing issues with server 
> > > > > responsiveness to other traffic. This is perhaps best summarised by 
> > > > > the following:
> > > > >
> > > > > root@nicoda /var/log/apache2 # ls -lah ...
> > > > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > > > >
> > > > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > > > 4,222,343
> > > > >
> > > > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > > > average - peaks are much higher by many magnitudes), which seems 
> > > > > extremely excessive given that this file is only supposed to be 
> > > > > retrieved by KDE software when GHNS functionality is triggered. That 
> > > > > is supported by the substantial size difference it has over 
> > > > > networkcheck.kde.org - which is used by plasma-nm and NetworkManager 
> > > > > (on Neon) to check for whether they have a working internet 
> > > > > connection - which i'd expect to be the site receiving the most 
> > > > > traffic.
> > > > >
> > > > > As such, I therefore suspect we have bug(s) in software that makes 
> > > > > use of GHNS functionality.
> > > > >
> > > > > It would therefore be appreciated if we could please review the 
> > > > > software in question to determine whether it is operating correctly. 
> > > > > Given that it usually runs in the background on user systems, i'd 
> > > > > especially appreciate it if a detailed review could be conducted on 
> > > > > Discover and other software that conducts package management 
> > > > > operations or assists in managing updates.
> > > > >
> > > > > Unfortunately all these applications submit a fairly useless user 
> > > > > agent (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any 
> > > > > further information. If we could get information on the software that 
> > > > > is originating the request added to the user agent to assist in 
> > > > > investigating these issues in the future that would be extremely 
> > > > > helpful.
> > > > >
> > > > > Thanks,
> > > > > Ben
> > > >
> > > > That's correct. Discover fetches them at startup. It's necessary to be
> > > > able to check if there are updates on KNS-provided resources.
> > > >
> > > > Incidentally,  I was looking into this yesterday incidentally. We
> > > > could see if caching is broken somehow. A request will still be needed
> > > > though to check if the cache is out of date.
> > >
> > > Caching seems to be working, since the vast majority of the requests
> > > are returning 304 Not Modified.
> > >
> > > However in *many* cases I see a single IP making multiple requests in
> > > the same second, and doing it again the next minute. Here's one IP
> > > address picked randomly:
> > >
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> > > [22/Sep/2021:06:27:58 +] "GET /ocs/p

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Thu, Sep 23, 2021 at 10:12 PM Nicolás Alvarez
 wrote:
>
> El jue, 23 de sep. de 2021 a la(s) 08:55, Aleix Pol (aleix...@kde.org) 
> escribió:
> >
> > On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> > >
> > > Hi all,
> > >
> > > It has recently come to our attention that the number of queries being 
> > > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on 
> > > a day to day basis has gotten to the point where it is causing issues 
> > > with server responsiveness to other traffic. This is perhaps best 
> > > summarised by the following:
> > >
> > > root@nicoda /var/log/apache2 # ls -lah ...
> > > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> > >
> > > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > > 4,222,343
> > >
> > > Based on those numbers we're looking at 48-49 requests per second (on 
> > > average - peaks are much higher by many magnitudes), which seems 
> > > extremely excessive given that this file is only supposed to be retrieved 
> > > by KDE software when GHNS functionality is triggered. That is supported 
> > > by the substantial size difference it has over networkcheck.kde.org - 
> > > which is used by plasma-nm and NetworkManager (on Neon) to check for 
> > > whether they have a working internet connection - which i'd expect to be 
> > > the site receiving the most traffic.
> > >
> > > As such, I therefore suspect we have bug(s) in software that makes use of 
> > > GHNS functionality.
> > >
> > > It would therefore be appreciated if we could please review the software 
> > > in question to determine whether it is operating correctly. Given that it 
> > > usually runs in the background on user systems, i'd especially appreciate 
> > > it if a detailed review could be conducted on Discover and other software 
> > > that conducts package management operations or assists in managing 
> > > updates.
> > >
> > > Unfortunately all these applications submit a fairly useless user agent 
> > > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > > information. If we could get information on the software that is 
> > > originating the request added to the user agent to assist in 
> > > investigating these issues in the future that would be extremely helpful.
> > >
> > > Thanks,
> > > Ben
> >
> > That's correct. Discover fetches them at startup. It's necessary to be
> > able to check if there are updates on KNS-provided resources.
> >
> > Incidentally,  I was looking into this yesterday incidentally. We
> > could see if caching is broken somehow. A request will still be needed
> > though to check if the cache is out of date.
>
> Caching seems to be working, since the vast majority of the requests
> are returning 304 Not Modified.
>
> However in *many* cases I see a single IP making multiple requests in
> the same second, and doing it again the next minute. Here's one IP
> address picked randomly:
>
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:25:41 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:27:57 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:27:58 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:32 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:28:59 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 200
> [22/Sep/2021:06:30:11 +] "GET /ocs/providers.xml HTTP/1.1" 304
> [22/Sep/2021:06:30:11

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Thu, Sep 23, 2021 at 1:54 PM Aleix Pol  wrote:
>
> On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > It has recently come to our attention that the number of queries being 
> > handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> > day to day basis has gotten to the point where it is causing issues with 
> > server responsiveness to other traffic. This is perhaps best summarised by 
> > the following:
> >
> > root@nicoda /var/log/apache2 # ls -lah ...
> > -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> > -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> > -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
> >
> > root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> > 4,222,343
> >
> > Based on those numbers we're looking at 48-49 requests per second (on 
> > average - peaks are much higher by many magnitudes), which seems extremely 
> > excessive given that this file is only supposed to be retrieved by KDE 
> > software when GHNS functionality is triggered. That is supported by the 
> > substantial size difference it has over networkcheck.kde.org - which is 
> > used by plasma-nm and NetworkManager (on Neon) to check for whether they 
> > have a working internet connection - which i'd expect to be the site 
> > receiving the most traffic.
> >
> > As such, I therefore suspect we have bug(s) in software that makes use of 
> > GHNS functionality.
> >
> > It would therefore be appreciated if we could please review the software in 
> > question to determine whether it is operating correctly. Given that it 
> > usually runs in the background on user systems, i'd especially appreciate 
> > it if a detailed review could be conducted on Discover and other software 
> > that conducts package management operations or assists in managing updates.
> >
> > Unfortunately all these applications submit a fairly useless user agent 
> > (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> > information. If we could get information on the software that is 
> > originating the request added to the user agent to assist in investigating 
> > these issues in the future that would be extremely helpful.
> >
> > Thanks,
> > Ben
>
> That's correct. Discover fetches them at startup. It's necessary to be
> able to check if there are updates on KNS-provided resources.
>
> Incidentally,  I was looking into this yesterday incidentally. We
> could see if caching is broken somehow. A request will still be needed
> though to check if the cache is out of date.
>
> Or we can prefer the cached version of the file for a few days and
> assume they don't change that much.
>
> I've seen some of them point at
> "https://download.kde.org/ocs/providers.xml;, I don't know if this is
> any better.
>
> Aleix

https://invent.kde.org/frameworks/attica/-/merge_requests/15/
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141
https://invent.kde.org/plasma/discover/-/merge_requests/165

This should lessen the problem from Discover's side. Still that one
providers.xml request at startup remains.

Aleix

Re: OCS Providers File - High Numbers of Requests

[Aleix Pol]

On Thu, Sep 23, 2021 at 11:52 AM Ben Cooksley  wrote:
>
> Hi all,
>
> It has recently come to our attention that the number of queries being 
> handled for the endpoint https://autoconfig.kde.org/ocs/providers.xml on a 
> day to day basis has gotten to the point where it is causing issues with 
> server responsiveness to other traffic. This is perhaps best summarised by 
> the following:
>
> root@nicoda /var/log/apache2 # ls -lah ...
> -rw-r- 1 root adm 458M Sep 23 06:25 autoconfig.kde.org.log.1
> -rw-r- 1 root adm 381M Sep 23 06:25 networkcheck.kde.org.log.1
> -rw-r- 1 root adm 143M Sep 23 06:25 www.kde.org.log.1
>
> root@nicoda /var/log/apache2 # cat autoconfig.kde.org.log.1 | wc -l
> 4,222,343
>
> Based on those numbers we're looking at 48-49 requests per second (on average 
> - peaks are much higher by many magnitudes), which seems extremely excessive 
> given that this file is only supposed to be retrieved by KDE software when 
> GHNS functionality is triggered. That is supported by the substantial size 
> difference it has over networkcheck.kde.org - which is used by plasma-nm and 
> NetworkManager (on Neon) to check for whether they have a working internet 
> connection - which i'd expect to be the site receiving the most traffic.
>
> As such, I therefore suspect we have bug(s) in software that makes use of 
> GHNS functionality.
>
> It would therefore be appreciated if we could please review the software in 
> question to determine whether it is operating correctly. Given that it 
> usually runs in the background on user systems, i'd especially appreciate it 
> if a detailed review could be conducted on Discover and other software that 
> conducts package management operations or assists in managing updates.
>
> Unfortunately all these applications submit a fairly useless user agent 
> (Mozilla/5.0) so it is impossible for Sysadmin to ascertain any further 
> information. If we could get information on the software that is originating 
> the request added to the user agent to assist in investigating these issues 
> in the future that would be extremely helpful.
>
> Thanks,
> Ben

That's correct. Discover fetches them at startup. It's necessary to be
able to check if there are updates on KNS-provided resources.

Incidentally,  I was looking into this yesterday incidentally. We
could see if caching is broken somehow. A request will still be needed
though to check if the cache is out of date.

Or we can prefer the cached version of the file for a few days and
assume they don't change that much.

I've seen some of them point at
"https://download.kde.org/ocs/providers.xml;, I don't know if this is
any better.

Aleix

Re: Towards Excellent Defect Management

[Aleix Pol]

On Tue, Sep 14, 2021 at 5:23 PM Harald Sitter  wrote:
>
> For many years now I've been unhappy with both the quality and volume
> of crash reports we get for our software. The barrier for crash report
> submissions is incredibly high because we've never really had tech to
> help elevate "insufficient" reports to become sufficient, outside the
> client on which the crash occurred. Out of the very few people that
> might want to report a crash even fewer will get beyond the first set
> of questions from drkonqi, once they've managed they still have to
> fight with their distro for debug symbols and quite possibly lose, and
> even if they win there is a good chance the report will either get a
> "this isn't very useful. install more symbols" comment or get marked
> as dupe. Meanwhile we are spending our days looking at duplicated
> crashes, or finding the right blurb to copy paste to ask for a better
> trace, or try to find out why software crashes that hasn't actually
> crashed for a year because the bug had already been fixed in the
> meantime.
>
> We are wasting our users' time. We are wasting our time. This waste
> needs to stop.
>
> The good news is that we have all the technical building blocks to fix
> it today. In fact, it's even getting better in the future still. All
> it takes is a bit of code and a bit of flexibility on our part.
>
> A while ago I started looking into improving the drkonqi experience.
> Specifically: submitting crash reports into a purpose built crash
> tracking system rather than a bug tracking system. The advantages are
> kind of obvious and ranging from server-side de-duplication to
> server-side retracing. I've spent many afternoons reading up on and
> poking demo instances of every somewhat suitable software I could
> find, and Sentry looks like the best option for what we need. It is
> practically free software as far as we are concerned, scales
> tremendously, has systems for server-side deduplication, server-side
> cross-distro/platform retracing (which might also help with some of
> the open questions of richer tracing for windows and android), data
> scrubbing (what with privacy concerns), client and server-side tags,
> can try to figure out when a crash first appeared if supplied with
> commit data, can track the quality of specific releases, when a given
> crash was fixed, health reports, performance tracking, warning rules,
> health report emails, ... I've been playing with it for a month and
> still find amazing new things!
>
> One of the best things about Sentry is that it has native support for
> debuginfod, enabling us to get debug symbols directly from
> distributions, solving the entire cross-distro aspect of crash tracing
> in just about the neatest way possible. We get the (incomplete) trace
> with lots of metadata, and Senty then uses the metadata to resolve the
> symbols through the distros' debuginfod instances to give us a
> complete trace.
>
> Even better: with relatively minor adjustments to drkonqi we could use
> it right now and get immediate advantage of server-side retracing! I
> already have a blob of prototype code for drkonqi that piggybacks
> Sentry submission onto the existing code such that we can have both
> bugzilla and Sentry.
>
> I am proposing that we roll out a Sentry instance for testing so we
> can see if we want to fully embrace it.
>
> You can get a general sense of the features at Sentry's demo instance
> https://sentry.io/demo/sandbox/
> Here's a code dump for drkonqi
> https://invent.kde.org/sitter/drkonqi/-/commits/work/sentry
>
> HS

+1 makes sense to me, it's exciting to find new ways that people can
help make our software better without a big effort.

I'd say the purpose of our manifesto clause that we need to rely
exclusively on FOSS tools wasn't designed for cases like this one.

Thanks for bringing it up!
Aleix

Re: New repo in kdereview: kasts

[Aleix Pol]

+1 thanks! And good job!

On Fri, Jul 2, 2021 at 2:34 PM Bart De Vries  wrote:
>
> On 27/05/2021 12:20, Bart De Vries wrote:
> > Hello everyone!
> >
> > I would like to move kasts to kdereview.
> >
> > https://invent.kde.org/plasma-mobile/kasts
> >
> > Kasts is a podcast app for Plasma Mobile. It was started as a fork of
> > Alligator, the Plasma Mobile feed reader. It currently features a play
> > queue, play position resume/persistence, MPRIS2 support, and suspend
> > inhibition.
> >
> > Kind regards,
> > Bart De Vries
> >
>
> Hi all,
>
> Kasts has been in KDE review for slightly over a month now.
> In the meantime, all issues and remarks raised during the review have
> been addressed.
>
> (The only exception is: the use of std::chrono in the audio player
> backend, which was marked as an optional improvement.  I still intend to
> investigate this, though.)
>
> The team have also worked on quite a few other bugfixes and
> improvements, a.o. a dedicated player controls UI for desktop.
>
> So, unless there are further objections, I will move Kasts to extragear
> in a few days from now.
>
> Best regards,
> Bart

Re: kpeoplevcard in kdereview

[Aleix Pol]

On Sat, Jun 12, 2021 at 3:56 PM Nicolas Fella  wrote:
>
> 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.

Thank you very much Nico for doing it!

Aleix

Re: New repo in kdereview: kasts

[Aleix Pol]

On Thu, May 27, 2021 at 12:20 PM Bart De Vries  wrote:
>
> Hello everyone!
>
> I would like to move kasts to kdereview.
>
> https://invent.kde.org/plasma-mobile/kasts  
> 
>
> Kasts is a podcast app for Plasma Mobile. It was started as a fork of 
> Alligator, the Plasma Mobile feed reader. It currently features a play queue, 
> play position resume/persistence, MPRIS2 support, and suspend inhibition.
>
> Kind regards,
> Bart De Vries

I gave it a try and imported my collection. I found a few issues, went
to bugs.kde.org and didn't find it. Can we create a product there?

There's some issues but it looks great and very promising, good job! :)

Aleix

Re: Qt5PatchCollection versions (broken QWE)

[Aleix Pol]

On Wed, May 26, 2021 at 1:19 PM Harald Sitter  wrote:
>
> Hola
>
> QWE and QtScript in our kde/5.15 branches currently have unaligned versions.
>
> QWE 5.15.4:
> https://invent.kde.org/qt/qt/qtwebengine/-/blob/kde/5.15/.qmake.conf
>
> QtBase 5.15.3:
> https://invent.kde.org/qt/qt/qtbase/-/blob/kde/5.15/.qmake.conf
>
> This then breaks version alignment expectations. For example QWECore
> requires QtWebChannel at the same version but since the versions are
> misaligned the requirement check changes.
>
> CMake Error at 
> /usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineCore/Qt5WebEngineCoreConfig.cmake:111
> (find_package):
>   Could not find a configuration file for package "Qt5WebChannel" that is
>   compatible with requested version "5.15.4".
>   The following configuration files were considered but not accepted:
> /usr/lib/x86_64-linux-gnu/cmake/Qt5WebChannel/Qt5WebChannelConfig.cmake,
> version: 5.15.3
>
> I would think that we should simply align the versions at whatever
> version seems appropriate. To that end I would propose that we lower
> the versions of QWE and QtScript to .3.
>
> Thoughts? Should I start an MR?
>
> (Also, kinda unrelated but I couldn't find a good venue to discuss
> things with all curators as gitlab issues are disabled for everything
> but the backport tracker :-( similarly I'm not sure where one would
> file a regression bug report if there were one - might need sorting
> out TBH)
>
> HS

Discussing here probably makes sense.

Does this maybe mean that we started from the wrong commit? I'd say
your recommendations are sound. +1

Aleix

Re: KDiff Bug 436958

[Aleix Pol]

On Thu, May 13, 2021 at 1:00 AM Michael Reeves  wrote:
>
> Could someone other than myself please have a look at this.
>
> https://bugs.kde.org/show_bug.cgi?id=436958
>
> None of these issues affect my system. I strongly suspect a distro
> specific issue. https://bugs.gentoo.org/show_bug.cgi?id=789330. The
> offending commit makes no sense as a true root cause. I would like an
> answer as to what is going on.

Hi,
I just tried opening it and I get this crash:

#5 0x7f088cf54ef5 in raise () from /usr/lib/libc.so.6
#6 0x7f088cf3e862 in abort () from /usr/lib/libc.so.6
#7 0x7f088d4dfc51 in qt_message_fatal (message=..., context=...) at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:1914
#8 QMessageLogger::fatal (this=this@entry=0x7ffef2f4b378,
msg=msg@entry=0x7f088d7ddea0 "ASSERT: \"%s\" in file %s, line %d") at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qlogging.cpp:893
#9 0x7f088d4df04a in qt_assert (assertion=,
file=, line=) at
/home/apol/devel/frameworks/qt5/qtbase/src/corelib/global/qglobal.cpp:3358
#10 0x55590227c7bb in SourceData::readAndPreprocess
(this=0x555903298590, pEncoding=0x555903144ab0,
bAutoDetectUnicode=true) at
/home/apol/devel/frameworks/kdiff3/src/SourceData.cpp:351
#11 0x5559021a6d5d in KDiff3App::mainInit (this=0x555903379bf0,
pTotalDiffStatus=0x55590334ae70, inFlags=...) at
/home/apol/devel/frameworks/kdiff3/src/pdiff.cpp:144
#12 0x5559021afecb in KDiff3App::slotFileOpen
(this=0x555903379bf0) at
/home/apol/devel/frameworks/kdiff3/src/pdiff.cpp:938
#13 0x55590215b154 in KDiff3App::completeInit
(this=0x555903379bf0, fn1=..., fn2=..., fn3=...) at
/home/apol/devel/frameworks/kdiff3/src/kdiff3.cpp:519
#14 0x55590214c2db in KDiff3Shell::KDiff3Shell
(this=0x5559031d7400, bCompleteInit=true) at
/home/apol/devel/frameworks/kdiff3/src/kdiff3_shell.cpp:60
#15 0x555902148223 in main (argc=1, argv=0x7ffef2f4d108) at
/home/apol/devel/frameworks/kdiff3/src/main.cpp:188

Re: Including LayerShellQt in Plasma in time for 5.22

[Aleix Pol]

On Thu, Apr 1, 2021 at 7:12 PM Aleix Pol  wrote:
>
> Hi,
> In Plasma we have wanted a way to work with wlr_layer_shell for a
> while, I'd tried taking this weird route, where we were adding it into
> the project ad hoc, but it didn't really go anywhere.
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20
>
> I then figured it would make sense to find a make sense to just go
> with what we need and implement it as a separate auto-contained
> component that can be used by any client:
> https://invent.kde.org/apol/layer-shell-qt
> Here's what it would look like when it's used by KScreenLocker:
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20
>
> I'd like to port KSplash to use it and possibly some other components
> it would make sense to get them there as well like KRunner or some
> plasma shell bits.
>
> The approach is a bit limited by QtWayland where it only supports
> having one shell per process. I hope to work upstream to improve the
> situation, this is a first step.
>
> So, I'd like to get it into the next Plasma release, I trust we can
> polish whatever might be necessary before 2021-04-29, the Repo freeze.
>
> I've requested the move to kdereview, for those of you who can see:
> https://phabricator.kde.org/T14327
>
> Best regards,
> Aleix
>
> PS: Not an April fools', no :)

So it's been two weeks and nobody found any striking issues. I'll move
on and request it's final move to Plasma.

Thanks everyone who looked into it! It did make a difference. :)

Cheers!
Aleix

Re: Including LayerShellQt in Plasma in time for 5.22

[Aleix Pol]

On Tue, Apr 6, 2021 at 11:08 AM Harald Sitter  wrote:

> - I'm like a broken record at this point: some of the cmake files and
> the json file lack licensing details. please run `reuse lint` to check
> the list. it's incredibly close to being fully licensed
> - you include KDEClangFormat but don't actually seem to enable it
> - along a similar note: the code style is inconsistent at times, you
> might want to also enable the githooks when built with a new enough
> ECM
> - CheckIncludeFiles is also included but not used
> - you sometimes use the Qt5::Foo targets rather than the Qt::Foo
> targets, I believe the latter is preferred for easier porting to qt6
> - the library code calls qputenv and ignores its return value, might
> make sense to qcwarning when the env variable failed to set
>
> other than that it looks lovely 
>
> HS
>

I think all the issues brought up here have been addressed.

Thanks everyone!
Aleix

Re: Including LayerShellQt in Plasma in time for 5.22

[Aleix Pol]

On Thu, Apr 1, 2021 at 7:12 PM Aleix Pol  wrote:
>
> Hi,
> In Plasma we have wanted a way to work with wlr_layer_shell for a
> while, I'd tried taking this weird route, where we were adding it into
> the project ad hoc, but it didn't really go anywhere.
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20
>
> I then figured it would make sense to find a make sense to just go
> with what we need and implement it as a separate auto-contained
> component that can be used by any client:
> https://invent.kde.org/apol/layer-shell-qt
> Here's what it would look like when it's used by KScreenLocker:
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20
>
> I'd like to port KSplash to use it and possibly some other components
> it would make sense to get them there as well like KRunner or some
> plasma shell bits.
>
> The approach is a bit limited by QtWayland where it only supports
> having one shell per process. I hope to work upstream to improve the
> situation, this is a first step.
>
> So, I'd like to get it into the next Plasma release, I trust we can
> polish whatever might be necessary before 2021-04-29, the Repo freeze.
>
> I've requested the move to kdereview, for those of you who can see:
> https://phabricator.kde.org/T14327
>
> Best regards,
> Aleix
>
> PS: Not an April fools', no :)

Now it's here:
https://invent.kde.org/plasma/layer-shell-qt

Cheers!
Aleix

Including LayerShellQt in Plasma in time for 5.22

[Aleix Pol]

Hi,
In Plasma we have wanted a way to work with wlr_layer_shell for a
while, I'd tried taking this weird route, where we were adding it into
the project ad hoc, but it didn't really go anywhere.
https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20

I then figured it would make sense to find a make sense to just go
with what we need and implement it as a separate auto-contained
component that can be used by any client:
https://invent.kde.org/apol/layer-shell-qt
Here's what it would look like when it's used by KScreenLocker:
https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20

I'd like to port KSplash to use it and possibly some other components
it would make sense to get them there as well like KRunner or some
plasma shell bits.

The approach is a bit limited by QtWayland where it only supports
having one shell per process. I hope to work upstream to improve the
situation, this is a first step.

So, I'd like to get it into the next Plasma release, I trust we can
polish whatever might be necessary before 2021-04-29, the Repo freeze.

I've requested the move to kdereview, for those of you who can see:
https://phabricator.kde.org/T14327

Best regards,
Aleix

PS: Not an April fools', no :)

Re: KDE Frameworks 6 - Virtual Sprint setup

[Aleix Pol]

On Fri, Jan 29, 2021 at 5:24 PM Adam Szopa  wrote:
>
> Hello,
>
> I've been talking with David Faure about setting up a Sprint focused on KF6  
> work. Some of the topics would include:
>
> - Reviewing the KF6 board (https://phabricator.kde.org/project/board/310/[1]):
>
> -- Clean up
>
> -- Tagging Junior Jobs
>
> - Working out a structure/process for handling:
>
> -- "Stuck" tasks
>
> -- Unit test regressions
>
> - Decide the 5.15 minimum requirement bump timeline
>
> - Decide on a 6 branching strategy and timeline
>
> - Decide if/how ECM should support multiple Qt versions
>
>
> That's just an example list - the wiki should include the up to date and 
> detailed topics.
>
>
> The Sprint will use the KDE BBB instance - same tech that powered last years  
> Akademy; I'll coordinate that with our sysadmins to have it available.
>
>
> As for the date and length, usually Virtual Sprints are a weekend thing. I'd
>
> love to hear from you if that sounds OK, and which weekend would be workable
>
> for you (how soon can we get this started) and your preferred availability
>
> hours. I'll set up a poll later to pinpoint the final timing.
>
>
> Thanks,
>
> - Adam

+1! :)

Re: Telemetry information in Plasma

[Aleix Pol]

On Mon, Nov 9, 2020 at 5:32 PM Aleix Pol  wrote:
>
> Hi,
> As discussed on the community mailing list, Plasma has been operating
> with the telemetry information with the discussion having happened on
> the wrong forum (being plasma-de...@kde.org instead of
> kde-core-devel@kde.org). It makes sense for the sake of consistency to
> have the discussion now rather than letting it slide for posterity. If
> there's changes required I'd suggest to address them on newer stable
> releases (be it on 5.20, 5.21 or the LTS one).
>
> Here is where we had the conversation:
> https://phabricator.kde.org/D24011
> https://phabricator.kde.org/D5961
>
> Basically what we are requesting is (from Plasma at bulk, including
> the Plasma shell and Discover):
> - BasicSystemInformation Level:
> Application version
> Compiler information
> Platform information
> Qt version information
>
> - BasicUsageStatistics
> Usage time
> Launches count (Discover)
>
> - DetailedSystemInformation
> OpenGL information
> Screen parameters
> QPA information
>
> - DetailedUsageStatistics
> Panel Count (Plasma shell)
> Application Source Name (Discover)
>
> Aleix

Including plasma-de...@kde.org for a wider audience.

Aleix

Re: Telemetry information in Plasma

[Aleix Pol]

On Tue, Nov 10, 2020 at 4:21 AM Nicolás Alvarez
 wrote:
>
> El lun., 9 de nov. de 2020 a la(s) 13:32, Aleix Pol (aleix...@kde.org) 
> escribió:
> > - BasicUsageStatistics
> > Usage time
> > Launches count (Discover)
>
> Is "launches count" reset to 0 after each telemetry submission, or is
> it cumulative / lifetime launch count?

It's number of launches, I guess it's a bit of a weird metric to have.
The idea was to measure if people are actually using it.

> > - DetailedUsageStatistics
> > Panel Count (Plasma shell)
> > Application Source Name (Discover)
>
> What is Application Source Name? Is this actually implemented? The
> database seems to have pure NULLs but I may be looking in the wrong
> place.

When I last tested it it was working.
It should be displaying which source for applications users are using.
Be it flatpak, packagekit or snap.

Aleix

Telemetry information in Plasma

[Aleix Pol]

Hi,
As discussed on the community mailing list, Plasma has been operating
with the telemetry information with the discussion having happened on
the wrong forum (being plasma-de...@kde.org instead of
kde-core-devel@kde.org). It makes sense for the sake of consistency to
have the discussion now rather than letting it slide for posterity. If
there's changes required I'd suggest to address them on newer stable
releases (be it on 5.20, 5.21 or the LTS one).

Here is where we had the conversation:
https://phabricator.kde.org/D24011
https://phabricator.kde.org/D5961

Basically what we are requesting is (from Plasma at bulk, including
the Plasma shell and Discover):
- BasicSystemInformation Level:
Application version
Compiler information
Platform information
Qt version information

- BasicUsageStatistics
Usage time
Launches count (Discover)

- DetailedSystemInformation
OpenGL information
Screen parameters
QPA information

- DetailedUsageStatistics
Panel Count (Plasma shell)
Application Source Name (Discover)

Aleix

Re: Git merge workflow: reverse it?

[Aleix Pol]

On Sun, Aug 2, 2020 at 2:44 PM Bhushan Shah  wrote:
>
> Hello everyone!
>
> At plasma, we are experimenting with new workflow regarding how bugfixes
> are put on the stable branch [1].
>
> # Previous workflow
>
> - Current workflow is that we commit to stable branch and then merge it
>   upwords until master branch
> - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then
>   master
>
> # Current workflow
>
> - Proposed workflow is to instead commit all changes in master, and
>   cherry-pick related changes in the stable branch as needed
> - We had been using this workflow for about 1 month now and I'd say it
>   is working nicely for us.
>
> # Why?
>
> We occasionally hit several issues with previous workflow,
>
> - Merge conflicts when merging changes upwords
> - Changes which are valid only for stable branch needs to be reverted in
>   master branches. So you end-up with, stable-fix, revert of stable fix
>   and then different fix and overall weird history.
> - Accidential merges from the master branch to stable branch which
>   needs to be force-resetted.
> - It's worth noting that Qt also recently changed to merge to dev,
>   cherry-pick backwards.
> - This also allows for workflows where we want to commit some bugfix in
>   the master branch for few days/weeks and if it works fine in general
>   testing then, cherry-pick it in stable branches.
>
> Proposal is to probably adapt this policy kde-wise if people feel that
> advantages are worth it.
>
> Thanks
>
> [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html

I was skeptical in the beginning about this, having used it in several
projects it's been quite pleasant and painless though.
+1

Aleix

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Fri, May 1, 2020 at 7:18 AM Ben Cooksley  wrote:
>
> On Fri, May 1, 2020 at 4:38 PM Nate Graham  wrote:
> >
> >
> >
> > On 4/30/20 5:59 PM, Aleix Pol wrote:
> > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> > >> Am I the only person that just has all the repos on the same folder? I 
> > >> thought it was the common thing to do :?
> > >
> > > I do too
> >
> > Same here. kdesrc-build's default settings do this, and download all
> > repos into ~/kde/src without any of the levels of hierarchy. This would
> > seem to require unique repo names, no?
>
> Not necessarily.
>
> Git allows you to override the name that the local folder is called
> when cloning, so there is no reason why we can't specify something in
> the metadata to override the local name that the folder gets called in
> your local checkout folder.
> This would allow for example:
>
> - frameworks/kcoreaddons on Gitlab continues to be called
> 'kcoreaddons' in your local checkout folder
> - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout 
> folder
>
> This allows for the URLs on Gitlab to make sense, while simultaneously
> allowing your local source checkout folders to continue to work in the
> manner in which they do currently.
> Note that we do not expect people to hit this in many cases - this is
> about giving us the flexibility for the long term without imposing
> unnecessary bureaucracy and limits on projects within the KDE
> umbrella.
>
> Automated tooling such as kdesrc-build and the proposed clone script
> (that searches in namespaces) should be able to handle this without
> much issue.
> In the case of manually done clones, it is reasonable to expect people
> to know what they're doing with their clones, and name them
> appropriately in the event they have a collision.
>
> Does this sound acceptable?

Okay, if that's necessary, we'll have to do it.

We'll appreciate simpler bureaucracy.

Aleix

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Fri, May 1, 2020 at 1:08 AM Nicolás Alvarez
 wrote:
>
> El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> (aa...@kde.org) escribió:
> >
> > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va 
> > escriure:
> > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > > >
> > > > > We have made a big fuss in the past about having different projects
> > > > > that do the same thing and now we'll have that but also we'll have
> > > > > several projects with the same name?
> > > > > It really feels off to me and I wonder if this is related to the move 
> > > > > to
> > > > > gitlab.
> > > >
> > > > +1 to both sentiments - that projects should have different names and 
> > > > that
> > > > this is a bit off topic for the gitlab migration.
> > >
> > > The projects *DO* have very different names. That *HAS NOT* changed.
> > > To use the example Bhushan gave above, one is called Plasma Mobile
> > > Dialer and the other one is called Maui Dialer.
> > >
> > > With the current git.kde.org setup, we have a flat namespace, so all
> > > repositories if the name appears to be generic (as dialer is) have to
> > > be namespaced by prefixing of the repository name.
> > >
> > > With Gitlab however we will now namespaces that group repositories,
> > > making the prefixing unnecessary and as some projects have complained
> > > about, duplicative.
> > >
> > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > > path, which just looks silly.
> >
> > Am I the only person that just has all the repos on the same folder? I 
> > thought it was the common thing to do :?

I do too

> Oh, your local path could be anywhere. It doesn't even need the same
> name, you can put it in the same folder as the rest and call it
> dial-thingy :)

And then you'll have to have a modified build script to account for
thingy because KDE can't stay consistent at naming.

I suggest not to use the gitlab transition to make such an important change.

Aleix

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah  wrote:
>
> Good afternoon,
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> I want to clarify some bits for which we have gotten a questions about,
>
> - Non unique naming: There's some teams which prefer if we dropped the
>   namespace- part from their name which we have added. While currently
>   this does not result in the naming conflict right away, we realize
>   this will cause it at one point, for example,
>
>   maui-dialer -> maui/dialer
>   plasma-dialer -> plasma-mobile/dialer
>
>   To minimize the impact of the Gitlab move we won't be doing such
>   renames which introduce non-unique names right away. But we would
>   prefer if the existing tooling or infrastructure is ready for this
>   kind of cases at later point. Only way to enforce non-unique naming is
>   one big KDE/ subgroup which we want to avoid.
>
>   Current naming in the repo-metadata branch[1] I've pointed does not
>   reflect those renames, as we are not planning to do those renames
>   right away during gitlab move, but at a later stage.

We have made a big fuss in the past about having different projects
that do the same thing and now we'll have that but also we'll have
several projects with the same name?
It really feels off to me and I wonder if this is related to the move to gitlab.

> - Existing configurations: we want to reduce impact on existing release
>   schedule, and existing developer workflow,  therefore we will continue
>   to privide the existing anongit.kde.org and git.kde.org (although this
>   will be read-only) with current flat structuring for 3 weeks after
>   actual migration, which will keep the existing scripts/clones working
>   enough to give developers time to change to the new structure.
>
>   We will also try to provide a script which allows you to migrate your
>   existing clones to new repo paths and as mentioned by Ben in other
>   message, potentially a git-kde script which would allow you to clone
>   individual repository without knowing it's namespace (provided that
>   there is no conflict of it's name). like "git kde karchive"

IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
I feel like these things make us look distant, it's important that
people's skills translate automatically when they want to get started.

> - Translations: we will co-ordinate with the translations team to let
>   them adapt their tooling to updated structure as this requires changes
>   on their side how translations are stored in svn repository

Thanks! :)

Re: Information regarding upcoming Gitlab Migration

[Aleix Pol]

On Mon, Apr 27, 2020 at 12:55 PM Ben Cooksley  wrote:
>
> On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol  wrote:
> >
> > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > >
> > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > replies]
> > >
> > > Hello Community members,
> > >
> > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > the recommended structuring for the repositories on Gitlab.
> > >
> > > We had multiple options,
> > >
> > > - Flat structure: In this option we would have everything under one
> > >   single namespace/group: https://invent.kde.org/kde/knetwalk
> > > - Subgroups under top-level group: In this option we would have a groups
> > >   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > - Groups at top level: In this option we would establish a series of
> > >   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > >
> > > We have discussed this with small but representative group of
> > > contributors or maintainers, and based on their suggestions, we
> > > recommend that we go with option 3. Having sub-groups at top level will
> > > allow us to,
> > >
> > > - Provides good visibility on all reviews, tasks and other items within
> > >   the groups/modules we define
> > > - Provides improvements to discoverability of projects
> > > - Makes it possible for groups of projects to establish a group level
> > >   task board should it fit their needs (for tracking a release for
> > >   instance)
> > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > >   in option 2 is duplicative considering the Gitlab instance is under
> > >   kde.org.
> > > - The discoverability of projects is maximised, as there is no need to
> > >   open the top level ‘KDE’ group before going into the subgroup.
> > >
> > > I've worked on draft "move" of the current set of the repositories in
> > > their respective subgroups at the repo-metadata project's branch [1].
> > > You can browse the directory structure to get idea of how final
> > > structure on Gitlab would look like.
> > >
> > > If we don't have any objections we would like to implement this next
> > > week and move projects to https://invent.kde.org.
> > >
> > > Thanks!
> > > Bhushan for sysadmin team
> > >
> > > [1] 
> > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
>
> Yes.
>
> >
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
>
> So you'd rather that we have no way to easily see a list of just
> Plasma / Frameworks / PIM / etc reviews?
> (See https://invent.kde.org/groups/kde/-/merge_requests for an example
> of the problem)
>
> Not to mention the fact that there will be several hundred
> repositories all in one group, so they will be completely
> undiscoverable to anyone outside of our community.
>
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
> >
> > I really prefer when I don't have to guess this kind of things when
> > fetching a repository.
>
> There is always the search on Gitlab, and you can keep a checkout of
> sysadmin/repo-metadata for grepping on.

I don't know, I've always felt that the nesting we have nowadays
stemmed from svn's tree structure more than convenience.

I don't have the feeling I'd use that feature and I'm happy to
convinced otherwise.

While discoverability would be an incentive, I don't know if it will
make a difference since it would be especially useful to see how
repositories relate one to another, but it's something we generally
split explicitly through frameworks so I don't see that will help
much, other than for the very big suites (kdepim, plasma, etc).

I know you don't like it when I do this, but:
https://gitlab.gnome.org/explore/groups < gnome kept all the programs
under the same group
https://gitlab.freedesktop.org/explore/groups < didn't, but they have
projects that have very little overlap of contributors

Aleix

Re: Information regarding upcoming Gitlab Migration

[Aleix Pol]

On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
>
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
>
> Hello Community members,
>
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
>
> We had multiple options,
>
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
>
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
>
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
>
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
>
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.
>
> Thanks!
> Bhushan for sysadmin team
>
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?

I really prefer when I don't have to guess this kind of things when
fetching a repository.

Aleix

Re: Type=FSDevice desktop files

[Aleix Pol]

On Sun, Apr 26, 2020 at 11:45 PM David Faure  wrote:
>
> Would it be OK if we dropped support for desktop files that represent devices?
> This was a KDE1/KDE2/KDE3? feature, you'd write/ship a desktop file with
> Type=FSDevice and Dev=/dev/sdc
> and this would give you Mount and Unmount in the context menu.
>
> This was useful back then, for USB keys and CDROMs (kids, ask your parents
> what that was), before Solid, before the plasma device notification popup...
>
> But has anyone been using this in the last 10 years? I kind of doubt it.
>
> Since I'm refactoring KRun and KDesktopFileActions to be asynchronous and
> independent from QtWidgets, I need to know what to do with this IMHO very dead
> code. Of course these classes will keep providing the feature, but once I
> write a KIO::OpenUrlJob as a replacement for KRun and we port the code to
> that, we'll lose the feature from a user's point of view.
> Not sure this is really a loss though ;)

I don't think anyone I've ever discussed OSs would miss it.

CCing plasma-devel since people there might know more about different use cases.

Aleix

Re: Update on Status of Gitlab Migration

[Aleix Pol]

On Mon, Apr 13, 2020 at 8:30 PM Ben Cooksley  wrote:
>
> On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
> >
> > On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > > Regarding this: is the subdomain going to stay invent.kde.org once we
> > > have officially moved? I find it's a bit confusing to use that instead
> > > of gitlab.kde.org
> >
> > I agree. gitlab.kde.org would make more sense to me, mirroring
> > phabricator.kde.org.
> >
>
> There is no intention to change the name from invent.kde.org.
>
> We have a long precedent of not using the name of the software for the
> name in DNS, and Gitlab is continuing with this, for example:
> - bugs.kde.org is run by Bugzilla
> - dot.kde.org is run by Drupal
> - techbase.kde.org is run by Mediawiki
> - conf.kde.org is run by Frab
> - reimbursements.kde.org is run by travel-support-program
> - websvn.kde.org is run by ViewVC
> - build.kde.org and binary-factory.kde.org are both run by Jenkins
> - stats.kde.org is run by Matomo (formerly Piwik)
> - survey.kde.org is run by Limesurvey
>
> For essentially all of the above, calling it after the software
> running it makes no sense, and given that in some cases we have
> multiple instances would have made things more confusing
> (jenkins1.kde.org and jenkins2.kde.org anyone?)
>
> Phabricator and Reviewboard were the only ones to not follow this
> rule, and that was an error on our part.
>
> Given that there is a popular instance at Gitlab.com, referring to
> ours as "KDE Invent" is more likely to ensure newcomers are not
> confused (as they may not be aware that you can setup an instance of
> Gitlab on your own systems)
>
> Regards,
> Ben

We also use git.kde.org and svn.kde.org.

It would too mimic what others are doing at gitlab.gnome.org and
gitlab.freedesktop.org. So at the very least we'll want a redirect.

Aleix

Re: Taking over maintainership of the kaccounts-* repos

[Aleix Pol]

On Fri, Sep 13, 2019 at 10:35 AM Bhushan Shah  wrote:
>
> Hello!
>
> At akademy we talked about the KAccounts and realized that kaccounts is
> unmaintained and/or Martin is not active.
>
> So I propose to take over maintainership of the following repositories.
>
> - kaccounts-integration
> - kaccounts-providers
> - kaccounts-mobile
>
> If you have any concerns/objections with this, let me know.
>
> Thanks
>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

:) thanks Bhushan!

Aleix

Re: Proposing Quick Charts as a new framework

[Aleix Pol]

On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra  wrote:
>
> On 02-09-2019 19:26, Luigi Toscano wrote:
> > Arjen Hiemstra ha scritto:
> >> Hi,
> >>
> >> I have been working on a library the past few months that provides a
> >> QtQuick
> >> module for rendering gpu-accelerated charts. It currently lives in a
> >> playground
> >> repository, here: https://invent.kde.org/kde/kf5quickcharts . I would
> >> like for
> >> this library to be included as a Tier 1 Framework.
> >
> > Hi,
> > I've noticed that some time ago (I didn't enable the translations yet,
> > but
> > maybe it's not needed).
>
> There are only user-visible strings in the example application. I
> haven't marked them
> to be translated since it is only an example.
>
> > I have a question and a comment:
> >
> > - what is the difference between this one and the existing
> > kqtquickcharts,
> > part of the KDE Applications bundle, from the KDEEdu project? At least
> > their
> > description overlaps. Is there any transition path? Having two
> > duplicate
> > libraries with the exact same goal may not be the best scenario.
>
> The main difference is in the rendering methods: kqtquickcharts uses
> QPainter for
> rendering, Quick Charts uses a technique called Signed Distance Fields
> to render
> certain charts with GPU acceleration and others use pure QtQuick
> scenegraph. I
> don't know if it would have been possible to retrofit that on to
> kqtquickcharts,
> but my guess is it would have been a major overhaul of that library
> anyway.
>
> An additional issue is that kqtquickcharts seems to be unmaintained,
> with the last
> major feature work having been done several years ago. So my personal
> opinion is
> that when Quick Charts is accepted as part of Frameworks, we deprecate
> kqtquickcharts as well as some other bits like the plotter item from
> kdeclarative.

Does it really have the same features? Otherwise it doesn't make sense
to deprecate anything. It will just frustrate the users of the
framework.

> > - I don't think that "5" should be part of the name; in two years from
> > now we
> > may have a Frameworks 6, and having a kf5quickchart as part of it may
> > be
> > confusing.
>
> That's actually a good point, though the kf5 is only in the repository
> name, I
> name it "Quick Charts" everywhere else. Which is probably a good reason
> to have
> the repo name changed in the first place. :) Originally, I put kf5 in
> the repo
> name because that's what is used once installed as part of Frameworks,
> but I
> agree that it can lead to confusing things.

It should be called kquickchart (which indeed is far too similar to
kqtquickcharts). Much like you use KF5CoreAddons, but the repository
is called kcoreaddons.

Aleix

We can't properly parse standard Desktop files

[Aleix Pol]

Hey,
Last week I was debugging an issue where I realised that we were not
splitting properly a StringList field in a desktop file coming from
Flatpak.

I notice then that we are using a coma to split desktop files instead
of a ; as the standard requests.

The multiple values should be separated by a semicolon and the value
of the key may be optionally terminated by a semicolon. Trailing empty
strings must always be terminated with a semicolon. Semicolons in
these values need to be escaped using \;.
https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

I suggested this patch, I'm not sure it's the best we can do given
we'll have to deal with quite a bit of legacy code but I'd say it's
the right thing to do.
https://phabricator.kde.org/D23381

Any thoughts?
Aleix

Re: Kdiff3 renovation

[Aleix Pol]

On Thu, May 9, 2019 at 5:19 PM Michael Reeves  wrote:
>
>
> Just a heads up kdiff3 is about to go through some major renovation. 
> Currently file processing is extremely in efficient.

Hi Michael,
I guess you meant "inefficient"? ^^'

Good luck and don't forget to add lots of tests! :)
Aleix

Re: freedesktop.org meeting again?

[Aleix Pol]

On Sat, Feb 9, 2019 at 1:32 PM David Faure  wrote:

> Is anyone interested in participating in a technical meeting with other
> desktop environments?
>
> I did that years ago and this is how we came up with various shared
> specifications, but at this point it might be more useful for people
> working
> on other things to attend.
>
> Cheers,
> David.
>
> --  Forwarded Message  --
>
> Subject: freedesktop.org meeting again?
> Date: mercredi 6 février 2019, 15:27:32 CET
> From: Agustin Benito Bethencourt 
> To: Lennart Poettering , David Faure <
> fa...@kde.org>,
> de...@desrt.ca
>
> Dear Allison, David and Lennart,
>
> this mail has as a goal to evaluate the interest you would have in meeting
> again like you guys did in 2013 and 2014 in Nuremberg, Germany, hosted
> again
> by SUSE, this time  during the openSUSE Conference[1], that will take
> place
> from May 24th to May 26th.
>
> If the dates, location matches your availability and there is interest in
> having this working sessions, I would be happy to coordinate the logistics
> and
> invite those who you think it should be present.. SUSE and openSUSE
> representatives are very interested in hosting this activity once again.
>
> What do you think? Who else should be at the event?
>
> [1] https://events.opensuse.org/conference/oSC19
>
>
It could be an interesting event to have indeed. Maybe it would make sense
to piggy-back on something more on-topic like XDC or LAS?
Or is SUSE especially interested?

Aleix

Re: Fwd: Kexi_flatpax fix and question

[Aleix Pol]

On Sat, Jan 26, 2019 at 1:43 AM Albert Astals Cid  wrote:

> As far as i know:
>  * The infrastructure we have at this point in KDE is more targeted to
> provide nightlies.
>  * If you want to provide stable flatpak, the current recommended solution
> is do it via flathub (like we do for several of our apps already).
>
> Cheers,
>   Albert
>
> El dijous, 24 de gener de 2019, a les 11:17:06 CET, Jaroslaw Staniek va
> escriure:
> > Hi
> > Can anyone approve it or confirm we can ship flatpacks for (stable) KDE
> > software?
> > We're close to release and Aleix seems to be silent.
> >
> >
> > -- Forwarded message -
> > From: Jaroslaw Staniek 
> > Date: Wed, 23 Jan 2019 at 11:40
> > Subject: Kexi_flatpax fix and question
> > To: Aleix Pol 
> >
> >
> > Hello Aleix!
> >
> > I'd like to ask for a review: https://phabricator.kde.org/T10377
> > .and have actual problem with lack of the stable software flatpacks (e.g.
> > for KEXI it's 3.2 now). More than nigtly unstables me and I guess some
> > other projects need stable flatpack packages to address the release
> problem
> > on Linux. What can we do to have them? We have resources for that.
> > Thanks.
> >
> >
>
>
>
>
>
Sorry I was AFK.
I'll reply in the phabricator ticket.

Aleix

Re: Move pulseaudio-qt to Extragear

[Aleix Pol]

On Sun, Nov 4, 2018 at 5:43 PM Nicolas Fella  wrote:
>
> 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
>

+1

Re: Adding Kirigami Gallery to kde-sdk

[Aleix Pol]

On Mon, Jun 18, 2018 at 12:21 PM Marco Martin  wrote:
>
> Hi all,
> in the kirigami framework repo, there is a little gallery application which
> outgrew the point of being a small example.
> It's now becoming a tutorial app: on each page an example and documentation on
> how to use a particular component and when with links on the relevant source
> code and HIG page about  such component (if available) becoming a developing
> aide while writing a Kirigami application.
>
> Also, since it's planned to add more graphics and heavy media files, makes it
> not particularly ideal to still use the framework repository.
> If no objections, it will be moved as a standalone repo as part of kde-sdk as
> developing aide.
>
> --
> Marco Martin

+1 makes sense to me.

Aleix

Re: Kde CI setup

[Aleix Pol]

On Mon, May 14, 2018 at 8:19 PM, Michael Reeves  wrote:
> How does one use kde's ci system? Is there a way to test a projects setup
> before going live with it?

Hi Michael,
Define "going live with it".

You can run your project locally using the same images the CI will for
linux, but then the CI will also do other OS and configurations.

If you're concerned with adding it and getting a red light. Don't
worry, just get your project on the CI and if there's any issues, you
can investigate and fix them. That's what the CI is for. :)

Aleix

Re: Installing qml caches

[Aleix Pol]

On Fri, Jun 1, 2018 at 1:10 PM, Alexander Volkov  wrote:
> Hi all,
>
> It would be nice to install .qmlc files in addition to .qml files to reduce
> start-up time of applications.
> They are generated with qmlcachegen. For Qt 5.11:
> qmlcachegen -o example.qmlc qxample.qml
>
> Currently qml files are usually installed the following way:
> install(DIRECTORY qml/ DESTINATION ${KDE_INSTALL_QMLDIR}/org/kde/kcm)
>
> So this could be changed to something like
> ecm_install_qml(qml org/kde/kcm)
>
> I wonder whether someone already working on this or want to implement such a
> function?
> If not, I'll try to do it myself.
>
> Cheers,
> Alexander.
>

I'm not sure this makes sense, as far as I know it's not a
binary-compatible format, so distros would have to recompile every
application with qmlc files upon Qt update.

Aleix

Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion

[Aleix Pol]

Hi Michael,
If you are interested in having the incubation happen, please get in
touch. I'll be glad to help.

Aleix

On Wed, Jan 17, 2018 at 9:40 PM, Michael Reeves  wrote:
> Yes I use this myself so I won't simply abandon it. That said I work in
> mostly in Unix world and could use help with the windows specific testing
> although I should be able to setup a build envirionment to do basic
> functionality testing. I'll have look at what needs done. Currently working
> on getting merging in changes from Thomas as needed.  Just got through
> bringing it up to date with Joachim's code. Real fun since it's still kde4.
>
>
> On Jan 15, 2018 5:47 PM, "Albert Astals Cid"  wrote:
>
> El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va
> escriure:
>> I have a version of kdiff3 that I ported to kf5. I like to what build
>> requirements kf5 as a whole has. Also what would be the process for being
>> considered for inclusion in kde?
>
> So now that we have Joachim's blessing to use the name, the process is
> basically outlined at https://community.kde.org/Incubator/Incubation_Process
> but it's basically importing the project into our git and then making sure
> it
> generally follows our rules & procedures.
>
> I understand you want to continue maintaining the new kdiff3 and you are not
> just "dumping it" into us, right?
>
>
> Cheers,
>   Albert
>
> El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va
> escriure:
>> Hi,
>
>> You have my blessing to use the name KDiff3.
>
>

Re: liquidshell in kdereview

[Aleix Pol]

On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller  wrote:
> Hi all,
>
> I'd like to announce an application I've implemented over the last few weeks 
> - liquidshell
>
> liquidshell is a replacement for plasmashell
>
> It does not use QtQuick but instead relies on QtWidgets,
> therefore no hardware graphics acceleration is needed.
>
> Main Features:
> - Wallpaper per virtual desktop
> - No animations, no CPU hogging, low Memory footprint
> - Instant startup
> - No use of activities (I never used nor needed them)
> - QtWidgets based, therefore follows widget style from systemsettings
> - Icons are used from your globally defined icon theme from systemsettings
> - Colors are used from your globally defined color theme from systemsettings
> - Can additionally be styled with css by passing the commandline option 
> -stylesheet filename.css
>   (see included example stylesheet.css)
> - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual 
> Desktops, Bluetooth, Network
> - Just one bottom DesktopPanel, containing:
>   StartMenu (allowing drag of entries into konqueror/dolphin to configure 
> QuickLaunch or AppMenu entries)
>   QuickLaunch (showing icons for .desktop files from a configurable folder)
>   AppMenu (showing .desktop files in a menu from a configurable folder, 
> defaults to users desktop folder)
>   Pager (for switching virtual desktops)
>   WindowList (Popup showing all open windows on all desktops)
>   TaskBar (showing windows on the current desktop, allowing drag of an entry 
> onto the Pager to move to a different desktop)
>   LockLogout
>   SysLoad widget including CPU, Memory, Swap and Network bars, live updated 
> tooltip
>   SysTray with integrated Network-, Notifications-, Device Notifier-, 
> Bluetooth-, Battery- display.
>   Display of StatusNotifier items from other applications (no legacy 
> embedded icons yet).
>   Notifications kept in a history list for some minutes, including 
> timestamp and text selectable per mouse
>   (very handy for copy/paste of TAC numbers from online banking received 
> via SMS and transferred to KDE
>via kdeconnect)
>   Clock widget (with calendar popup, tooltip for selected cities)
> - Desktop can contain applets (there's currently only a weather applet)
>
> The main motivation was to have a reliable desktop shell which does not hog 
> the CPU or RAM.
> (CPU usage and stability were the things driving me mad with plasmashell)
> It should be slick and have just the features I need in my daily
> work. No need having all the bells and whistles anyone can think of.
> Just have a plain, solid, fast workhorse.
>
> I think the final place should be extragear.
>
> Today I put it into openSuse's OBS and 2 packages for tumbleweed and factory 
> are already in place
> and ready to be installed.
>
> Screenshots:
> light color theme: 
> http://members.aon.at/m.koller/liquidshell_20171103_174650.png
> dark  color theme: 
> http://members.aon.at/m.koller/liquidshell_20171103_174944.png
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
>
>

Hi Martin,
I'm a bit confused, who is liquidshell for?

Aleix

Re: Plasma Browser Integration is in kdereview

[Aleix Pol]

On Tue, Jul 11, 2017 at 1:08 AM, David Edmundson
 wrote:
> Do you know if you can me it be a bit more quiet and only output errors on
>>
>> failure?
>
>
> I changed that a few weeks ago, I assume it's fine now?
>
>
> If there are no complaints I'll move this to Plasma.

+1
\o/

Aleix

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Thu, Jun 15, 2017 at 10:22 PM, Ben Cooksley <bcooks...@kde.org> wrote:
> On Fri, Jun 16, 2017 at 1:42 AM, Aleix Pol <aleix...@kde.org> wrote:
>> On Tue, Jun 13, 2017 at 6:56 PM, Volker Krause <vkra...@kde.org> wrote:
>>> On Monday, 12 June 2017 01:56:21 CEST Aleix Pol wrote:
>>>> On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause <vkra...@kde.org> wrote:
>>>> > On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote:
>>>> >> On Thu, May 25, 2017 at 4:42 PM, Volker Krause <vkra...@kde.org> wrote:
>>>> >> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
>>>> >> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
>>>> >> >> Hey Volker, I figured out this one. Never mind.
>>>> >> >>
>>>> >> >> I've done a proof of concept integrating it in Discover, here's 2
>>>> >> >> patches:
>>>> >> >> https://phabricator.kde.org/D5960
>>>> >> >> https://phabricator.kde.org/D5961
>>>> >> >
>>>> >> > There's still two aspects missing in the integration:
>>>> >> > - configure Provider to actually submit (see productIdentifier,
>>>> >> > feedbackServer and submissionInterval properties)
>>>> >> > - probably add some data sources (in the current form you only get an
>>>> >> > indication on how many users you have, and untargeted surveys, nothing
>>>> >> > more)
>>>> >> >
>>>> >> > The second point will need some more QML wrapper API. I'll look into
>>>> >> > adding a QML plugin to KUserFeedback directly for this.
>>>> >> >
>>>> >> >> Now to proceed I'd like to give a try to whole system including the
>>>> >> >> server. Do you have documented how to set it up anywhere? Would make
>>>> >> >> it easier.
>>>> >> >
>>>> >> > INSTALL contains the deployment documentation, both for the full setup
>>>> >> > with
>>>> >> > authentication on an Apache server, and locally for unsecured testing
>>>> >> > using
>>>> >> > the built-in PHP server.
>>>> >> >
>>>> >> > I've also got a playground server on my own infrastructure now that I
>>>> >> > can
>>>> >> > provide accounts for. And Jan has published his ongoing work on
>>>> >> > creating a
>>>> >> > Docker image for the server here:
>>>> >> > https://github.com/KDAB/kuserfeedbackdocker
>>>> >> >
>>>> >> > Regards,
>>>> >> > Volker
>>>> >>
>>>> >> Hi Volker,
>>>> >> More noob feedback:
>>>> >> I set up a local system I could tinkle with using your colleague's
>>>> >> docker. Worked quite well. But, I was getting an issue, possibly fixed
>>>> >> by this patch:
>>>> >> https://phabricator.kde.org/D6117
>>>> >
>>>> > This looks good, I'll try to get that path unit-tested to make sure this
>>>> > works with sqlite too. However, you should not actually hit this path in
>>>> > the first place, which is probably also why you are not seeing any data.
>>>> >
>>>> >> Now I get to see things being sent on the UserFeedbackConsole
>>>> >> application, but I only see timestamps. I added debug information to
>>>> >> see what is being sent and (after updating the discover patch above)
>>>> >> and I see all sort of data, being delivered. Is it being lost in the
>>>> >> internets? Or am I not looking into it correctly? If I export the
>>>> >> product using UserFeedbackConsole I also only get timestamps :(.
>>>> >
>>>> > Do you see the empty columns for the other data in UserFeedbackConsole, 
>>>> > or
>>>> > do you only see the Timestamp column? In the former case the data is
>>>> > either not transmitted, or rejected by the server for some reason, we'd
>>>> > need to look at the JSON payload sent to the server in that case. In the
>>>> > other case, you probably need to set up a product schema first with
>>>> > UserFeedbackConsole (easiest via 

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Tue, Jun 13, 2017 at 6:56 PM, Volker Krause <vkra...@kde.org> wrote:
> On Monday, 12 June 2017 01:56:21 CEST Aleix Pol wrote:
>> On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause <vkra...@kde.org> wrote:
>> > On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote:
>> >> On Thu, May 25, 2017 at 4:42 PM, Volker Krause <vkra...@kde.org> wrote:
>> >> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
>> >> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
>> >> >> Hey Volker, I figured out this one. Never mind.
>> >> >>
>> >> >> I've done a proof of concept integrating it in Discover, here's 2
>> >> >> patches:
>> >> >> https://phabricator.kde.org/D5960
>> >> >> https://phabricator.kde.org/D5961
>> >> >
>> >> > There's still two aspects missing in the integration:
>> >> > - configure Provider to actually submit (see productIdentifier,
>> >> > feedbackServer and submissionInterval properties)
>> >> > - probably add some data sources (in the current form you only get an
>> >> > indication on how many users you have, and untargeted surveys, nothing
>> >> > more)
>> >> >
>> >> > The second point will need some more QML wrapper API. I'll look into
>> >> > adding a QML plugin to KUserFeedback directly for this.
>> >> >
>> >> >> Now to proceed I'd like to give a try to whole system including the
>> >> >> server. Do you have documented how to set it up anywhere? Would make
>> >> >> it easier.
>> >> >
>> >> > INSTALL contains the deployment documentation, both for the full setup
>> >> > with
>> >> > authentication on an Apache server, and locally for unsecured testing
>> >> > using
>> >> > the built-in PHP server.
>> >> >
>> >> > I've also got a playground server on my own infrastructure now that I
>> >> > can
>> >> > provide accounts for. And Jan has published his ongoing work on
>> >> > creating a
>> >> > Docker image for the server here:
>> >> > https://github.com/KDAB/kuserfeedbackdocker
>> >> >
>> >> > Regards,
>> >> > Volker
>> >>
>> >> Hi Volker,
>> >> More noob feedback:
>> >> I set up a local system I could tinkle with using your colleague's
>> >> docker. Worked quite well. But, I was getting an issue, possibly fixed
>> >> by this patch:
>> >> https://phabricator.kde.org/D6117
>> >
>> > This looks good, I'll try to get that path unit-tested to make sure this
>> > works with sqlite too. However, you should not actually hit this path in
>> > the first place, which is probably also why you are not seeing any data.
>> >
>> >> Now I get to see things being sent on the UserFeedbackConsole
>> >> application, but I only see timestamps. I added debug information to
>> >> see what is being sent and (after updating the discover patch above)
>> >> and I see all sort of data, being delivered. Is it being lost in the
>> >> internets? Or am I not looking into it correctly? If I export the
>> >> product using UserFeedbackConsole I also only get timestamps :(.
>> >
>> > Do you see the empty columns for the other data in UserFeedbackConsole, or
>> > do you only see the Timestamp column? In the former case the data is
>> > either not transmitted, or rejected by the server for some reason, we'd
>> > need to look at the JSON payload sent to the server in that case. In the
>> > other case, you probably need to set up a product schema first with
>> > UserFeedbackConsole (easiest via Schema -> Source Templates in the Schema
>> > view).
>>
>> Here's what I'm seeing: https://imgur.com/a/BmH2B
>> I've seen the schema view, I haven't pushed it much. I see I can add
>> stuff but I'm not sure what it's for. I expected the system to
>> integrate all data offered, but maybe I need to set the expectations
>> on the server side?
>
> Yes, exactly, that's what the schema does. Easiest way to get started is
> probably to just import the orwell example schema there, that contains all
> existing data sources, or you just create sources from their corresponding
> templates.
>
> That is, in the schema view chose schema -> import schema...

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause <vkra...@kde.org> wrote:
> On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote:
>> On Thu, May 25, 2017 at 4:42 PM, Volker Krause <vkra...@kde.org> wrote:
>> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
>> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
>> >> Hey Volker, I figured out this one. Never mind.
>> >>
>> >> I've done a proof of concept integrating it in Discover, here's 2
>> >> patches:
>> >> https://phabricator.kde.org/D5960
>> >> https://phabricator.kde.org/D5961
>> >
>> > There's still two aspects missing in the integration:
>> > - configure Provider to actually submit (see productIdentifier,
>> > feedbackServer and submissionInterval properties)
>> > - probably add some data sources (in the current form you only get an
>> > indication on how many users you have, and untargeted surveys, nothing
>> > more)
>> >
>> > The second point will need some more QML wrapper API. I'll look into
>> > adding a QML plugin to KUserFeedback directly for this.
>> >
>> >> Now to proceed I'd like to give a try to whole system including the
>> >> server. Do you have documented how to set it up anywhere? Would make
>> >> it easier.
>> >
>> > INSTALL contains the deployment documentation, both for the full setup
>> > with
>> > authentication on an Apache server, and locally for unsecured testing
>> > using
>> > the built-in PHP server.
>> >
>> > I've also got a playground server on my own infrastructure now that I can
>> > provide accounts for. And Jan has published his ongoing work on creating a
>> > Docker image for the server here:
>> > https://github.com/KDAB/kuserfeedbackdocker
>> >
>> > Regards,
>> > Volker
>>
>> Hi Volker,
>> More noob feedback:
>> I set up a local system I could tinkle with using your colleague's
>> docker. Worked quite well. But, I was getting an issue, possibly fixed
>> by this patch:
>> https://phabricator.kde.org/D6117
>
> This looks good, I'll try to get that path unit-tested to make sure this works
> with sqlite too. However, you should not actually hit this path in the first
> place, which is probably also why you are not seeing any data.
>
>> Now I get to see things being sent on the UserFeedbackConsole
>> application, but I only see timestamps. I added debug information to
>> see what is being sent and (after updating the discover patch above)
>> and I see all sort of data, being delivered. Is it being lost in the
>> internets? Or am I not looking into it correctly? If I export the
>> product using UserFeedbackConsole I also only get timestamps :(.
>
> Do you see the empty columns for the other data in UserFeedbackConsole, or do
> you only see the Timestamp column? In the former case the data is either not
> transmitted, or rejected by the server for some reason, we'd need to look at
> the JSON payload sent to the server in that case. In the other case, you
> probably need to set up a product schema first with UserFeedbackConsole
> (easiest via Schema -> Source Templates in the Schema view).

Here's what I'm seeing: https://imgur.com/a/BmH2B
I've seen the schema view, I haven't pushed it much. I see I can add
stuff but I'm not sure what it's for. I expected the system to
integrate all data offered, but maybe I need to set the expectations
on the server side?
Either way, this is the information being sent at the moment (I copied
your orwell.qml example sources so far).
{
"applicationVersion": { "value": "5.10.90" },
"compiler": { "type": "Clang", "version": "4.0" },
"platform": { "os": "linux", "version": "arch-unknown" },
"qtVersion": { "value": "5.9.0" },
"startCount": { "value": 76 },
"usageTime": { "value": 34132 }
}


> I'll also try your Discover patches here to see if I can reproduce this, the
> QML bindings haven't gotten any real use yet, quite possible some stuff
> doesn't work there correctly yet.

I'll update the patch to adapt to changes in kuserfeedback.

Aleix

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Thu, Jun 8, 2017 at 12:27 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dissabte, 3 de juny de 2017, a les 11:49:00 CEST, Volker Krause va
> escriure:
>> On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote:
>> > On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote:
>> > > I would have looked into fixing it, but I'm not sure I understand why
>> > > there's all the RPATH logic in place, so I'd prefer to hear from you
>> > > first.
>> >
>> > I have removed the remains of the pre-ECM rpath handling. This also
>> > changed
>> > binary output directories on Linux to follow KDE standards, so you might
>> > want to do a clean build to avoid issues with outdated binaries in the
>> > build dir.
>> >
>> > > A good next step would also be to get it running on build.kde.org, so
>> > > we can identify these issues.
>> >
>> > Indeed, I've requested CI coverage now.
>>
>> Looks like in order to get CI coverage we need to move to kdereview (which
>> is fine, I think it's ready for that), but that requires to know where this
>> should end up afterwards.
>>
>> I guess the candidates are extragear/libs or frameworks? frameworks seems
>> conceptually like the right place, but putting something there that is still
>> fairly new and has seen little field testing seems sub-optimal. Opinions?
>
> To me it seems a few releases from extragear would make sense before moving to
> frameworks and promise full API/ABI compatibility.
>
> OTOH when moving from extreagear to frameworks we may have to rename library
> (to have the KF5 suffix) which would break also API (at least at the cmake
> level).
>
> How do people feel having libs in extreager having the KF5 "cmake naming" in
> the understanding that we're stabilizing them to be part of frameworks
> eventually?

IMO it's a bit weird and unsettling. But then, we're already doing it
for many pim libraries (not in extragear but in applications, still
not part of KF5).

Aleix

Re: Plasma Browser Integration is in kdereview

[Aleix Pol]

On Wed, Jun 7, 2017 at 12:23 AM, David Edmundson
 wrote:
> Install the host part with the normal cmake && make.
> The bit that tries to install into /etc/ does need to go into /etc
>
> Easiest thing then is to then install the extension part from one of the
> links in my original email.

Yes, you are right, it's pretty easy.
That said, a wiki or a README.md would be nice too.

I'm having a crash on Chrome [1], on Chromium it's working perfectly
fine though. Impressive!

Aleix

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

Re: Plasma Browser Integration is in kdereview

[Aleix Pol]

On Mon, Jun 5, 2017 at 4:42 PM, David Edmundson
 wrote:
> Hey all,
>
> We'd like to add project plasma-browser-integration into KDE[0].
>
> The goal is to make chrome and firefox integrate better into a Plasma
> desktop environment through browser extensions.
>
> How?:
> Firefox and chrome (and potentially others) allow plugins to talk to a
> native binary host [1]. This binary host is launched by the the browser and
> has a socket to a conventional browser extension. This project consists of
> both parts allowing a chrome extension to make normal DBus calls to services
> just like other apps.
>
> Integrating what?:
> This gives us the following features:
>  - Finding open tabs via krunner
>  - Download progress in the task bar
>  - Showing now playing information with shortcuts (if the website supports
> it)
>  - "Send to KDE Connect" context menu on links
>  - Loading windows on the correct activity (WIP)
>  - An SNI if incognito windows are open with action to close them.
>
> And potentially more in the future. There is a config to enable/disable
> parts as appropriate.
>
> Deployment:
>  This repo consists of two parts. The binary host which should be
> distributed by normal distro means, and the browser extension which is going
> to be different.
>
> The browser extension can be deployed in one of 3 ways.
>  - manually by the user from the code (useful for devs)
>
>  - through the webstore [2][3]
>  - chrome also has a feature where we can ship a text file on the distro
> side that will make the browser automatically fetch an extension from their
> store.
>
> Ideally we want the extension available on the store from an official KDE
> channel.
>
>  - potentially it could also be done by the distro, but it seems like FF
> might be removing that possibility and the digital signing is an issue.
>
> [0] https://cgit.kde.org/plasma-browser-integration.git/
> [1] https://developer.chrome.com/extensions/nativeMessaging
> [2]
> https://chrome.google.com/webstore/detail/plasma-integration/cimiefiiaegbelhefglklhhakcgmhkai
> [3]
> https://addons.mozilla.org/en-US/android/addon/plasma-integration/?src=cb-dl-updated
>
> Regards
>
> David and Kai

General +1 to the features. Really awesome. :)

Do we have any documentation on how to test it?

Aleix

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Thu, May 25, 2017 at 4:42 PM, Volker Krause <vkra...@kde.org> wrote:
> On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
>> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
>> Hey Volker, I figured out this one. Never mind.
>>
>> I've done a proof of concept integrating it in Discover, here's 2 patches:
>> https://phabricator.kde.org/D5960
>> https://phabricator.kde.org/D5961
>
> There's still two aspects missing in the integration:
> - configure Provider to actually submit (see productIdentifier, feedbackServer
> and submissionInterval properties)
> - probably add some data sources (in the current form you only get an
> indication on how many users you have, and untargeted surveys, nothing more)
>
> The second point will need some more QML wrapper API. I'll look into adding a
> QML plugin to KUserFeedback directly for this.
>
>> Now to proceed I'd like to give a try to whole system including the
>> server. Do you have documented how to set it up anywhere? Would make
>> it easier.
>
> INSTALL contains the deployment documentation, both for the full setup with
> authentication on an Apache server, and locally for unsecured testing using
> the built-in PHP server.
>
> I've also got a playground server on my own infrastructure now that I can
> provide accounts for. And Jan has published his ongoing work on creating a
> Docker image for the server here: https://github.com/KDAB/kuserfeedbackdocker
>
> Regards,
> Volker

Hi Volker,
More noob feedback:
I set up a local system I could tinkle with using your colleague's
docker. Worked quite well. But, I was getting an issue, possibly fixed
by this patch:
https://phabricator.kde.org/D6117

Now I get to see things being sent on the UserFeedbackConsole
application, but I only see timestamps. I added debug information to
see what is being sent and (after updating the discover patch above)
and I see all sort of data, being delivered. Is it being lost in the
internets? Or am I not looking into it correctly? If I export the
product using UserFeedbackConsole I also only get timestamps :(.

HTH,
Aleix

Re: zanshin for kdereview

[Aleix Pol]

On Sat, Jun 3, 2017 at 9:01 AM, Kevin Ottens  wrote:
> Hello,
>
> Zanshin has been around for a while and I should have requested it to move to
> Extragear a long time ago but somehow forgot. The discussion regarding the
> next gen CI reminded me of that.
>
> I hereby request Zanshin to be moved out of playground and into kdereview so
> that it gets the usual review period. The aim is to have in in extragear/pim
> in the end.

Hi Kevin,
I'm pretty sure moving to kdereview is something to ask to sysadmin.
https://phabricator.kde.org/u/systickets

Then once it's there you request the move here saying it's in
kdereview, waiting to go to extragear/pim.

Aleix

PS: ah, bureaucracy! :D

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Sat, Jun 3, 2017 at 11:49 AM, Volker Krause <vkra...@kde.org> wrote:
> On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote:
>> On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote:
>> > I would have looked into fixing it, but I'm not sure I understand why
>> > there's all the RPATH logic in place, so I'd prefer to hear from you
>> > first.
>>
>> I have removed the remains of the pre-ECM rpath handling. This also changed
>> binary output directories on Linux to follow KDE standards, so you might
>> want to do a clean build to avoid issues with outdated binaries in the
>> build dir.
>> > A good next step would also be to get it running on build.kde.org, so
>> > we can identify these issues.
>>
>> Indeed, I've requested CI coverage now.
>
> Looks like in order to get CI coverage we need to move to kdereview (which is
> fine, I think it's ready for that), but that requires to know where this
> should end up afterwards.
>
> I guess the candidates are extragear/libs or frameworks? frameworks seems
> conceptually like the right place, but putting something there that is still
> fairly new and has seen little field testing seems sub-optimal. Opinions?

+1
Since we're still introducing it to projects maybe it could make sense
to have a couple of releases with it in extragear so people will be
less angry if we needed to break ABI (it's what we did for kirigami,
and I'd say it's worked reasonably well).
At Akademy we can discuss to get it in frameworks if it works for everyone?

Aleix

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause <vkra...@kde.org> wrote:
>> Hi,
>>
>> we have talked about the above topics a couple of times in the past, from 
>> what
>> I remember usually agreeing it would be nice to have some more statistical
>> information about our users, so we know what our applications are used for,
>> and to measure impact of changes. Similarly, it would be nice to be able to
>> actually ask our users questions without statistical bias by using 
>> out-of-band
>> channels like blogs or social media. This can be obviously addressed by 
>> adding
>> this into application code, but that raises some valid privacy concerns.
>>
>> Wanting this for GammaRay I attempted to implement a generic framework for
>> this, with the goal to make this fully transparent, and give the user full
>> control over what data is shared, and how often they want to participate in
>> surveys, ie. make this solid enough on the privacy side that even I would
>> enable it myself. You'll find the code in Git (kde:kuserfeedback).
>>
>> Feature-wise it so far contains:
>> - a set of built-in data sources (app version, Qt version, platform,
>> application usage time, screen setup, etc) that applications can choose to
>> enable
>> - generic data sources for tracking the time ratio a Q_PROPERTY has a 
>> specific
>> value, allowing to track e.g. which application view is used how much
>> - the ability to add custom/application-specific data sources
>> - reference widgets for customizing what data you want to share, and showing
>> exactly what that means, in human readable translated text and if you insists
>> also all the way down to the raw JSON sent to the server.
>> - survey targeting using simple C++/JS-like expressions that can access all
>> the data sources (ie. you can target e.g. only users with high DPI multi-
>> screen setups)
>> - configurable encouragement of users to contribute (ie. after X starts 
>> and/or
>> Y hours of usage, repeated after Z months, suggest the user to participate if
>> they aren't already doing so).
>> - a management and analytic tool that allows you to manage products and 
>> survey
>> campaigns, and view recorded data using configurable aggregations
>> - the entire thing works without unique user ids. Fingerprinting can still be
>> an issue on too small user sets and/or when using too much detail in the 
>> data.
>> - by default all of this is opt-in of course, although technically the API
>> doesn't prevent applications to change this
>> - it can deal with multiple products, each product can have different data
>> sources and survey campaigns
>>
>> Technically, this consists of the following parts:
>> - a library that goes into the target application, backward compatible all 
>> the
>> way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on
>> QtGui
>> - a library with the reference widgets, also with extended backward
>> compatibility
>> - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the
>> most fun technology, but that stuff is available almost anywhere, and easy to
>> deploy and maintain
>> - the management tool, recent Qt5/recent C++, using QtCharts for the data
>> analysis
>> - a command line tool for data import/export, useful for eg. automated 
>> backups
>>
>> All of this is LGPLv2+ licensed.
>>
>> Feedback obviously very welcome, in particular around privacy concerns, or
>> reasons that would make you enable/disable such a feature.
>>
>> Regards,
>> Volker
>
> Hi volker,
> I've been looking into how it works, I wanted to test the tests/orwell
> application but I keep getting this error:
> ./bin/orwell: symbol lookup error: ./bin/orwell: undefined symbol:
> _ZN12UserFeedback18CompilerInfoSourceC1Ev
>
> I'm seeing a similar error when running autotests:
> * Start testing of DataSourceTest *
> Config: Using QtTest library 5.9.0, Qt 5.9.0
> (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC
> 6.3.1 20170306)
> PASS   : DataSourceTest::initTestCase()
> PASS   : DataSourceTest::testPlatformInfoSource()
> PASS   : DataSourceTest::testScreenInfoSource()
> PASS   : DataSourceTest::testPropertyRatioSource()
> PASS   : DataSourceTest::testMultiPropertyRatioSource()
> PASS   : DataSourceTest::testApplicationVersionSource()
> PASS   : DataSourceTest::testQtVersionSource()
> PASS   : DataSourceTest::testStartCountSource()
> PASS   : DataSourc

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause  wrote:
> Hi,
>
> we have talked about the above topics a couple of times in the past, from what
> I remember usually agreeing it would be nice to have some more statistical
> information about our users, so we know what our applications are used for,
> and to measure impact of changes. Similarly, it would be nice to be able to
> actually ask our users questions without statistical bias by using out-of-band
> channels like blogs or social media. This can be obviously addressed by adding
> this into application code, but that raises some valid privacy concerns.
>
> Wanting this for GammaRay I attempted to implement a generic framework for
> this, with the goal to make this fully transparent, and give the user full
> control over what data is shared, and how often they want to participate in
> surveys, ie. make this solid enough on the privacy side that even I would
> enable it myself. You'll find the code in Git (kde:kuserfeedback).
>
> Feature-wise it so far contains:
> - a set of built-in data sources (app version, Qt version, platform,
> application usage time, screen setup, etc) that applications can choose to
> enable
> - generic data sources for tracking the time ratio a Q_PROPERTY has a specific
> value, allowing to track e.g. which application view is used how much
> - the ability to add custom/application-specific data sources
> - reference widgets for customizing what data you want to share, and showing
> exactly what that means, in human readable translated text and if you insists
> also all the way down to the raw JSON sent to the server.
> - survey targeting using simple C++/JS-like expressions that can access all
> the data sources (ie. you can target e.g. only users with high DPI multi-
> screen setups)
> - configurable encouragement of users to contribute (ie. after X starts and/or
> Y hours of usage, repeated after Z months, suggest the user to participate if
> they aren't already doing so).
> - a management and analytic tool that allows you to manage products and survey
> campaigns, and view recorded data using configurable aggregations
> - the entire thing works without unique user ids. Fingerprinting can still be
> an issue on too small user sets and/or when using too much detail in the data.
> - by default all of this is opt-in of course, although technically the API
> doesn't prevent applications to change this
> - it can deal with multiple products, each product can have different data
> sources and survey campaigns
>
> Technically, this consists of the following parts:
> - a library that goes into the target application, backward compatible all the
> way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on
> QtGui
> - a library with the reference widgets, also with extended backward
> compatibility
> - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the
> most fun technology, but that stuff is available almost anywhere, and easy to
> deploy and maintain
> - the management tool, recent Qt5/recent C++, using QtCharts for the data
> analysis
> - a command line tool for data import/export, useful for eg. automated backups
>
> All of this is LGPLv2+ licensed.
>
> Feedback obviously very welcome, in particular around privacy concerns, or
> reasons that would make you enable/disable such a feature.
>
> Regards,
> Volker

Hi volker,
I've been looking into how it works, I wanted to test the tests/orwell
application but I keep getting this error:
./bin/orwell: symbol lookup error: ./bin/orwell: undefined symbol:
_ZN12UserFeedback18CompilerInfoSourceC1Ev

I'm seeing a similar error when running autotests:
* Start testing of DataSourceTest *
Config: Using QtTest library 5.9.0, Qt 5.9.0
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC
6.3.1 20170306)
PASS   : DataSourceTest::initTestCase()
PASS   : DataSourceTest::testPlatformInfoSource()
PASS   : DataSourceTest::testScreenInfoSource()
PASS   : DataSourceTest::testPropertyRatioSource()
PASS   : DataSourceTest::testMultiPropertyRatioSource()
PASS   : DataSourceTest::testApplicationVersionSource()
PASS   : DataSourceTest::testQtVersionSource()
PASS   : DataSourceTest::testStartCountSource()
PASS   : DataSourceTest::testUsageTimeSource()
PASS   : DataSourceTest::testCpuInfoSource()
PASS   : DataSourceTest::testLocaleInfoSource()
./bin/datasourcetest: symbol lookup error: ./bin/datasourcetest:
undefined symbol: _ZN12UserFeedback16OpenGLInfoSourceC1Ev

I would have looked into fixing it, but I'm not sure I understand why
there's all the RPATH logic in place, so I'd prefer to hear from you
first.

A good next step would also be to get it running on build.kde.org, so
we can identify these issues.

Aleix

Re: Fwd: KF5 CMake usage question

[Aleix Pol]

On Mon, May 22, 2017 at 7:54 PM, Shaheed Haque <srha...@theiet.org> wrote:
> On 21 May 2017 at 22:27, Aleix Pol <aleix...@kde.org> wrote:
>> On Sat, May 20, 2017 at 7:41 PM, Shaheed Haque <srha...@theiet.org> wrote:
>>> Actually, there is one thing about "target CMake"-based KF5 that I
>>> don't quite understand: is there a way to get to the C++ compile flags
>>> needed from CMake? That is, the modern equivalent of Foo_COMPILE_FLAGS
>>> but for target Foo? Even if the general answer is "no", I'm interested
>>> in at least the CMake variables/properties/commands needed to get to
>>> "-fPIC" and "-std=gnu++14".
>>>
>>> I'm aware of the target properties
>>> COMPILE_FLAGS/OPTIONS/DEFINITIONS/OPTIONS as well as
>>> POSITION_INDEPENDENT_CODE and CXX_STANDARD but none of these seem to
>>> be set on targets I have tried.
>>>
>>> Perhaps these are only set if somehow the compiler name etc. is specified?
>>>
>>> Thanks, Shaheed
>>>
>>> On 18 May 2017 at 18:04, Shaheed Haque <srha...@theiet.org> wrote:
>>>> Hi,
>>>>
>>>> On 18 May 2017 at 12:51, Andreas Hartmetz <ahartm...@gmail.com> wrote:
>>>>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 13 May 2017 at 22:04, Sven Brauch <m...@svenbrauch.de> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:
>>>>>> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is
>>>>>> >> not
>>>>>> >> set. In poking around, I see references to a (new-to-me)
>>>>>> >> target-based
>>>>>> >
>>>>>> >> system, and using that like this:
>>>>>> > The question is, why do you need to do that?
>>>>>>
>>>>> The idea with the target based system aka "Modern CMake" is that you say
>>>>> you want to compile against a library, and that is all you have to do. A
>>>>> library requires you to add an include path for its own headers, include
>>>>> paths for headers of one of its dependencies, and link against a bunch
>>>>> of libraries? All covered by target properties.
>>>>> If for some reason (e.g. handover to an external tool) you need those
>>>>> properties, you can still query them. Under enforced names nonetheless,
>>>>> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?
>>>>
>>>> Ack. The problem from the point of view of an automated tool which starts
>>>> with a component called Foo arises ONLY because the target(s) of Foo are
>>>> called FooFoo and FooBar. CMake does not - AFAICS - allow one to query Foo
>>>> and somehow find FooFoo and FooBar inorder to look up FooFoo_INCLUDE_DIRS
>>>> etc.
>>>>
>>>>
>>>>>> I'm continuing to experiment with trying to build Python bindings for
>>>>>> KF5. As part of that, the SIP tooling creates C++ wrapper code which
>>>>>> must be compiled for each framework, and for that I need to know the
>>>>>> header file directories. So far, I have simply been hardcoding the
>>>>>> needed paths on my own system, but I now want to move to using
>>>>>> standard CMake-based logic instead.
>>>>>>
>>>>>> (In some sense, this might be seen as similar to the stuff that was
>>>>>> added to ECM, but I'm trying for a significantly more automated
>>>>>> approach).
>>>>>>
>>>>>> Also, I am trying to feel my way towards a Pythonic build system for
>>>>>> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in
>>>>>> other words I'm interested in using CMake as a stepping stone, not the
>>>>>> actual build system.
>>>>>>
>>>>> I would recommend against that unless you really need to have heavy
>>>>> logic in the build system. A build system's main job is to "solve" a
>>>>> dependency tree - that is the difference between a build system and a
>>>>> script that runs the compiler. The dependency tree enables cheap
>>>>> incremental builds and correct parallel builds. Maybe not that important
>>>>> for bindings, 

Re: Fwd: KF5 CMake usage question

[Aleix Pol]

On Thu, May 18, 2017 at 7:04 PM, Shaheed Haque  wrote:
> Hi,
>
> On 18 May 2017 at 12:51, Andreas Hartmetz  wrote:
>> On Samstag, 13. Mai 2017 23:48:33 CEST Shaheed Haque wrote:
>>> Hi,
>>>
>>> On 13 May 2017 at 22:04, Sven Brauch  wrote:
>>> > Hi,
>>> >
>>> > On 05/13/2017 06:06 PM, Shaheed Haque wrote:
>>> >> The printed output shows that the variable KF5KIO_INCLUDE_DIRS is
>>> >> not
>>> >> set. In poking around, I see references to a (new-to-me)
>>> >> target-based
>>> >
>>> >> system, and using that like this:
>>> > The question is, why do you need to do that?
>>>
>> The idea with the target based system aka "Modern CMake" is that you say
>> you want to compile against a library, and that is all you have to do. A
>> library requires you to add an include path for its own headers, include
>> paths for headers of one of its dependencies, and link against a bunch
>> of libraries? All covered by target properties.
>> If for some reason (e.g. handover to an external tool) you need those
>> properties, you can still query them. Under enforced names nonetheless,
>> unlike FOO_INCLUDE_DIR or was it FOO_INCLUDE_DIRS?
>
> Ack. The problem from the point of view of an automated tool which starts
> with a component called Foo arises ONLY because the target(s) of Foo are
> called FooFoo and FooBar. CMake does not - AFAICS - allow one to query Foo
> and somehow find FooFoo and FooBar inorder to look up FooFoo_INCLUDE_DIRS
> etc.
>
>
>>> I'm continuing to experiment with trying to build Python bindings for
>>> KF5. As part of that, the SIP tooling creates C++ wrapper code which
>>> must be compiled for each framework, and for that I need to know the
>>> header file directories. So far, I have simply been hardcoding the
>>> needed paths on my own system, but I now want to move to using
>>> standard CMake-based logic instead.
>>>
>>> (In some sense, this might be seen as similar to the stuff that was
>>> added to ECM, but I'm trying for a significantly more automated
>>> approach).
>>>
>>> Also, I am trying to feel my way towards a Pythonic build system for
>>> the KF5 bindings (as, roughly speaking, PyQt seems to be doing): in
>>> other words I'm interested in using CMake as a stepping stone, not the
>>> actual build system.
>>>
>> I would recommend against that unless you really need to have heavy
>> logic in the build system. A build system's main job is to "solve" a
>> dependency tree - that is the difference between a build system and a
>> script that runs the compiler. The dependency tree enables cheap
>> incremental builds and correct parallel builds. Maybe not that important
>> for bindings, admittedly.
>> Your advantage from using Python must be larger than the overhead from
>> doing your own dependency resolution plus the overhead from the CMake-
>> Python interfacing plus the build-related facilities that CMake has and
>> Python doesn't. Or were you considering scons?
>> PyQt may have chosen Python because qmake sucks, and it needs Python
>> anyway, so it avoids any extra dependencies. I know from experience that
>> you really want to avoid extra dependencies in commercial products.
>
> /me nods vigourosly.
>
> I'm not (yet) familair with all the intricacies of the Python build system
> (or CMake for that matter!), but I do see that PyQt has to work quite hard
> to keep its build system working as a Python user might expect. Further, the
> system I am seeking to build has to support more than KF5 (or even KDE). So,
> roughly speaking, the split I am going for is:
>
> - Keep all platform and system independent code in Python
> - Isolate all platform and system independent logic in CMake
>
> As I say, I am feeling my way a bit here, but this seems like a
> philosophically justifiable separation. Oh, and to solve the problem of
> finding the targets, I resorted to parsing the CMake files (!!). I can live
> with that hack precisely because by having the split, users of this code who
> are not using it against KF5 will need to replace this CMake part with their
> own anyway.
>
> (At this point, abstracting CMake away entirely is a minor detail).
>
> Thanks for the helpful remarks.
>
> Shaheed
>
>
>
>>> Thus, I'm after the moral equivalents of:
>>>
>>> Foo_INCLUDE_DIRS
>>> Foo_COMPILE_FLAGS
>>>
>>> Thanks, Shaheed
>>>
>>> > The usual way is to simply call
>>> >
>>> > target_link_libraries(mybinary KF5::KIOCore)
>>> >
>>> > and include paths etc. will be set up for your target automatically.
>>> >
>>> > Best,
>>> > Sven
>>
>> Cheers,
>> Andreas M9

BTW you don't need to do the parsing, you can run cmake in server mode
and query it: "cmake -E server...".

Re: kdereview - xdg-desktop-portal-kde

[Aleix Pol]

On Tue, May 2, 2017 at 12:15 PM, Albert Astals Cid  wrote:
> El dimarts, 2 de maig de 2017, a les 7:22:04 CEST, Jan Grulich va escriure:
>> On pondělí 1. května 2017 22:59:44 CEST Albert Astals Cid wrote:
>> > El divendres, 21 d’abril de 2017, a les 8:10:36 CEST, Jan Grulich va
>>
>> escriure:
>> > > Hi,
>> > >
>> > > I would like to request review of xdg-desktop-portal-kde [1]. We would
>> > > like
>> > > to make it part of Plasma releases, see [2].
>> > >
>> > > What is xdg-desktop-portal-kde:
>> > > It's a KDE implementation of Flatpak portals backend [3], currently with
>> > > support of AppChooser, FileChooser, Notification and Print portals.
>> > >
>> > > One mentioned issue on plasma-devel mailing list was usage of Qt's
>> > > private
>> > > print API. This will most likely go away if I find out it's useless,
>> > > otherwise I'll have to keep it as it's used to set CUPS properties which
>> > > are not available to the outside world.
>> >
>> > Since you have copied some code from Okular maybe you can add some other
>> > (C) there other than RedHat's?
>>
>> Added.
>>
>> > What about the unusued QVariantMap  in the print.cpp file? What
>> > are
>> > you supposed to return there?
>>
>> Seems not to be used at this moment or the portal frontend doesn't expect
>> something to be returned with "results". I guess it's just reserved for
>> future usage, given how complex the print API is.
>>
>> > I've no idea how to use this so can't really test it :/
>>
>> You can test it with this [1]. You just go to flapak-build folder and run
>> build.sh which will generate you a flatpak repo, you add it and install
>> using flatpak, but you also need to have xdg-desktop-portal installed.
>
> Got stuck trying to figure out what to install from that local flatpak repo
>
> $ flatpak remote-ls mylocalrepo
> error: GPG verification enabled, but no summary signatures found (use gpg-
> verify-summary=false in remote config to disable)
>
> And couldn't figure out how to do that, seems like the hint is only half there
> :D

Hi,
Here it's explained how to use a local repo:
https://community.kde.org/Guidelines_and_HOWTOs/Flatpak#Compile_your_application

The catch is --no-gpg-verify.

Aleix

Re: Application usage statistics and targeted user surveys

[Aleix Pol]

On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause  wrote:
> Hi,
>
> we have talked about the above topics a couple of times in the past, from what
> I remember usually agreeing it would be nice to have some more statistical
> information about our users, so we know what our applications are used for,
> and to measure impact of changes. Similarly, it would be nice to be able to
> actually ask our users questions without statistical bias by using out-of-band
> channels like blogs or social media. This can be obviously addressed by adding
> this into application code, but that raises some valid privacy concerns.
>
> Wanting this for GammaRay I attempted to implement a generic framework for
> this, with the goal to make this fully transparent, and give the user full
> control over what data is shared, and how often they want to participate in
> surveys, ie. make this solid enough on the privacy side that even I would
> enable it myself. You'll find the code in Git (kde:kuserfeedback).
>
> Feature-wise it so far contains:
> - a set of built-in data sources (app version, Qt version, platform,
> application usage time, screen setup, etc) that applications can choose to
> enable
> - generic data sources for tracking the time ratio a Q_PROPERTY has a specific
> value, allowing to track e.g. which application view is used how much
> - the ability to add custom/application-specific data sources
> - reference widgets for customizing what data you want to share, and showing
> exactly what that means, in human readable translated text and if you insists
> also all the way down to the raw JSON sent to the server.
> - survey targeting using simple C++/JS-like expressions that can access all
> the data sources (ie. you can target e.g. only users with high DPI multi-
> screen setups)
> - configurable encouragement of users to contribute (ie. after X starts and/or
> Y hours of usage, repeated after Z months, suggest the user to participate if
> they aren't already doing so).
> - a management and analytic tool that allows you to manage products and survey
> campaigns, and view recorded data using configurable aggregations
> - the entire thing works without unique user ids. Fingerprinting can still be
> an issue on too small user sets and/or when using too much detail in the data.
> - by default all of this is opt-in of course, although technically the API
> doesn't prevent applications to change this
> - it can deal with multiple products, each product can have different data
> sources and survey campaigns
>
> Technically, this consists of the following parts:
> - a library that goes into the target application, backward compatible all the
> way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on
> QtGui
> - a library with the reference widgets, also with extended backward
> compatibility
> - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the
> most fun technology, but that stuff is available almost anywhere, and easy to
> deploy and maintain
> - the management tool, recent Qt5/recent C++, using QtCharts for the data
> analysis
> - a command line tool for data import/export, useful for eg. automated backups
>
> All of this is LGPLv2+ licensed.
>
> Feedback obviously very welcome, in particular around privacy concerns, or
> reasons that would make you enable/disable such a feature.
>
> Regards,
> Volker

Hi Volker,
This is really cool and necessary! I'd really like to see it adopted
in our applications, hoping Krita can be the first of many. ;)

WRT the code, it depends needs Qt4, we can live with it, but isn't it
a bit weird that we have several ECM files forked in it? :/ is it
really that tough of a depenendency? (if so, maybe we should rethink
the whole KF5 approach x'D)

Aleix

Re: What's kde-core-devel for?

[Aleix Pol]

On Mon, Dec 19, 2016 at 10:48 PM, Albert Astals Cid  wrote:
> El dilluns, 19 de desembre de 2016, a les 17:42:17 CET, Alexander Neundorf va
> escriure:
>> On 2016 M12 19, Mon 10:24:29 CET Jan Kundrát wrote:
>> > KDE has expanded over the last few years to include projects which are not
>> > based on kdelibs or kf5 (or even Qt).
>>
>> I have heard that several times. Which are those beside Wiki2Learn ?
>
> Please let's try to stay focused on topic.
>
> Cheers,
>   Albert
>
> P.S: took me like 4 minutes
>
> PHP- https://cgit.kde.org/websites/capacity.git/
> Java   - https://cgit.kde.org/kdeconnect-android.git/
> Python - https://websvn.kde.org/trunk/l10n-support/pology/
> PHP- https://cgit.kde.org/websites/paste-kde-org.git/
> CMake  - https://cgit.kde.org/extra-cmake-modules.git/
> PHP- https://cgit.kde.org/websites/identity-kde-org.git/tree/

What Jan meant was Qt-only projects like Trojitá, I think.

Aleix

Re: Review Request 129644: i10n: update Czech Republic to Czechia

[Aleix Pol Gonzalez]

> On Dec. 13, 2016, 3:23 p.m., Luigi Toscano wrote:
> > Ahoj, out of curiosity: this is for kdelibs4 applications, how was handled 
> > in the sources used by Qt5 applications? I don't think we have those 
> > information in Frameworks anymore.
> > 
> > It would maybe worth to have consistency between the value of Frameworks 5 
> > and kdelibs4 applications.

I think this is now handled by Qt through icu.


- Aleix


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


On Dec. 13, 2016, 12:36 a.m., Jiri Bohac wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129644/
> ---
> 
> (Updated Dec. 13, 2016, 12:36 a.m.)
> 
> 
> Review request for KDE Runtime and Localization and Translation (l10n).
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> This year, the country has oficially adopted the short name Czechia.
> The short name has been entered to the UNTERM and UNGEGN databases in July 
> 2016
> Czechia is used in iso_3166 since September 2016
> 
> 
> Diffs
> -
> 
>   l10n/cz/entry.desktop 05297c3 
> 
> Diff: https://git.reviewboard.kde.org/r/129644/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jiri Bohac
> 
>

Re: Review Request 129208: Fix KUrl::isRelativeUrl to allow all RFC3986 characters in scheme.

[Aleix Pol Gonzalez]

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



I'm not sure it's a very good idea to introduce behavior changes in kdelibs 4. 
Why can't you use kde-open from kf5?

- Aleix Pol Gonzalez


On Oct. 17, 2016, 12:18 p.m., Gerhard Gappmeier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129208/
> ---
> 
> (Updated Oct. 17, 2016, 12:18 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> RFC3986 defines the following syntax for URI schemes
> scheme = alpha *( alpha | digit | "+" | "-" | "." )
> 
> The '.' was missing which leaded to the problem that
> xdg-open opc.tcp://localhost didn't work.
> 
> Background:
> xdg-open calls kde-open which then uses KUrl and so leaded to this
> problem. Of course this bug may affect also many other locations
> using KUrl::isRelativeUrl.
> 
> This fix also adds a unit test to test the fix and avoid future
> regressions.
> 
> 
> Diffs
> -
> 
>   kdecore/io/kurl.cpp d9661eab5f8df3bfbbd2900246437fb129037dba 
>   kdecore/tests/kurltest.cpp 3947724bfd1d26ad69b97789205a814a8d712591 
> 
> Diff: https://git.reviewboard.kde.org/r/129208/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gerhard Gappmeier
> 
>

Re: Review Request 129119: Fix HAVE_TRUNC cmake check

[Aleix Pol Gonzalez]

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


Ship it!




Ship It!

- Aleix Pol Gonzalez


On Oct. 7, 2016, 11:05 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129119/
> ---
> 
> (Updated Oct. 7, 2016, 11:05 p.m.)
> 
> 
> Review request for Build System and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> On newer distros the check fails because trunc is ambiguous, so tell sizeof 
> exactly which trunc we're speaking about.
> 
> 
> Diffs
> -
> 
>   ConfigureChecks.cmake 2729adb 
>   cmake/modules/CheckPrototypeExists.cmake 811d648 
> 
> Diff: https://git.reviewboard.kde.org/r/129119/diff/
> 
> 
> Testing
> ---
> 
> kdelibs compiles (a bit more, there's still an unrelated issue)
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

Re: Review Request 128909: initial, minimal support for OS X

[Aleix Pol Gonzalez]

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




processui/ReniceDlg.cpp (lines 56 - 57)
<https://git.reviewboard.kde.org/r/128909/#comment66908>

Wrong indentation



processui/ReniceDlg.cpp (line 79)
<https://git.reviewboard.kde.org/r/128909/#comment66909>

Wrong indentation.
Also isn't it possible to query the backend or something?


- Aleix Pol Gonzalez


On Sept. 22, 2016, 4:50 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128909/
> ---
> 
> (Updated Sept. 22, 2016, 4:50 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Software on Mac OS X.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This patch implements initial and rather minimal support for OS X, for now 
> focussing purely on process information. That feature is justified as it is 
> used by KDevelop in order to obtain the list of processes one can attach a 
> debugger to.
> 
> Mac OS X is tricky because it requires special privileges in order to obtain 
> certain types of information for any running process. For example, even 
> obtaining the number of threads spawned by a foreign process requires 
> privileges that aren't trivial to set up. I've prepared the terrain, but also 
> implemented a fallback strategy that calls `ps` to be sure that crucial 
> information like the command name is available for all processes.
> 
> 
> Diffs
> -
> 
>   processcore/CMakeLists.txt e7c9263 
>   processcore/Info.plist PRE-CREATION 
>   processcore/processes_darwin_p.cpp PRE-CREATION 
>   processcore/processes_local_p.cpp 2bc123f 
>   processui/ReniceDlg.cpp a97563f 
>   processui/ksysguardprocesslist.cpp 44603de 
> 
> Diff: https://git.reviewboard.kde.org/r/128909/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Frameworks 5.24.0 and Qt 5.6.1
> 
> 
> File Attachments
> 
> 
> Attach to Process widget in KDevelop
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/14/47468811-58cb-40b8-a735-4dd86dce98e1__Screen_Shot_2016-09-14_at_17.38.22.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 128909: initial, minimal support for OS X

[Aleix Pol Gonzalez]

> On Sept. 17, 2016, 9:52 p.m., René J.V. Bertin wrote:
> > processui/ReniceDlg.cpp, lines 78-87
> > 
> >
> > I've actually managed to get ksysguardprocesslist_helper to work with a 
> > patched libdbus and a hack to export the session bus socket name to the 
> > system dbus.

Is it really a good idea to rely on a patched libdbus?


- Aleix


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


On Sept. 17, 2016, 7:32 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128909/
> ---
> 
> (Updated Sept. 17, 2016, 7:32 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Software on Mac OS X.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This patch implements initial and rather minimal support for OS X, for now 
> focussing purely on process information. That feature is justified as it is 
> used by KDevelop in order to obtain the list of processes one can attach a 
> debugger to.
> 
> Mac OS X is tricky because it requires special privileges in order to obtain 
> certain types of information for any running process. For example, even 
> obtaining the number of threads spawned by a foreign process requires 
> privileges that aren't trivial to set up. I've prepared the terrain, but also 
> implemented a fallback strategy that calls `ps` to be sure that crucial 
> information like the command name is available for all processes.
> 
> 
> Diffs
> -
> 
>   processcore/CMakeLists.txt e7c9263 
>   processcore/Info.plist PRE-CREATION 
>   processcore/helper.cpp d54c8e1 
>   processcore/processes_darwin_p.cpp PRE-CREATION 
>   processcore/processes_local_p.cpp 2bc123f 
>   processui/ReniceDlg.cpp a97563f 
>   processui/ksysguardprocesslist.cpp 44603de 
> 
> Diff: https://git.reviewboard.kde.org/r/128909/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Frameworks 5.24.0 and Qt 5.6.1
> 
> 
> File Attachments
> 
> 
> Attach to Process widget in KDevelop
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/14/47468811-58cb-40b8-a735-4dd86dce98e1__Screen_Shot_2016-09-14_at_17.38.22.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 128909: initial, minimal support for OS X

[Aleix Pol Gonzalez]

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



+1


processcore/processes_local_p.cpp (line 34)
<https://git.reviewboard.kde.org/r/128909/#comment66802>

drop trailing space


- Aleix Pol Gonzalez


On Sept. 15, 2016, 2:47 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128909/
> ---
> 
> (Updated Sept. 15, 2016, 2:47 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Software on Mac OS X.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This patch implements initial and rather minimal support for OS X, for now 
> focussing purely on process information. That feature is justified as it is 
> used by KDevelop in order to obtain the list of processes one can attach a 
> debugger to.
> 
> Mac OS X is tricky because it requires special privileges in order to obtain 
> certain types of information for any running process. For example, even 
> obtaining the number of threads spawned by a foreign process requires 
> privileges that aren't trivial to set up. I've prepared the terrain, but also 
> implemented a fallback strategy that calls `ps` to be sure that crucial 
> information like the command name is available for all processes.
> 
> 
> Diffs
> -
> 
>   processcore/CMakeLists.txt e7c9263 
>   processcore/Info.plist PRE-CREATION 
>   processcore/processes_darwin_p.cpp PRE-CREATION 
>   processcore/processes_local_p.cpp 2bc123f 
> 
> Diff: https://git.reviewboard.kde.org/r/128909/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Frameworks 5.24.0 and Qt 5.6.1
> 
> 
> File Attachments
> 
> 
> Attach to Process widget in KDevelop
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/14/47468811-58cb-40b8-a735-4dd86dce98e1__Screen_Shot_2016-09-14_at_17.38.22.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 128909: initial, minimal support for OS X

[Aleix Pol Gonzalez]

> On Sept. 15, 2016, 1:29 a.m., Aleix Pol Gonzalez wrote:
> > processcore/helper.cpp, line 133
> > <https://git.reviewboard.kde.org/r/128909/diff/2/?file=476882#file476882line133>
> >
> > `KAUTH_HELPER_MAIN` doesn't work on OS X?
> 
> René J.V. Bertin wrote:
> Thanks for picking up on this, I'd forgotten to make a comment about it.
> 
> I think the macro does work, it's KAuth which currently doesn't seem to 
> work for me. It also doesn't in my Linux build, btw, but there at least it 
> gives some error output suggesting tries to use polkit and possibly even the 
> processlist helper from my KDE4 desktop. 
> 
> The explicit implementation on OS X wasn't because of the macro, it was 
> to allow running setuid root. Initial testing didn't show any benefit to 
> that, but it could well be that's because KAuth still fails somewhere and 
> then simply aborts the requested operation.
> 
> Suggestions very welcome, but if we can't get this to work I'll probably 
> want to disable changing process priorities.
> 
> René J.V. Bertin wrote:
> As to testing with setuid root: it looks it won't be trivial to hack 
> KAuth out of helper.cpp . Is there a way to take KAuth out of the loop one 
> way or another - for instance instruct it to do nothing when already running 
> with the required privileges, or to ignore failures?
> 
> I'm fully aware why Qt disables running setuid root, but I'd hope the 
> risk is minimal in a helper app like this that is designed to work as root 
> (and doesn't "linger").
> 
> Also, the helper is started via DBus, right? Doesn't DBus provide a 
> mechanism to launch a service with elevated privileges?
> 
> René J.V. Bertin wrote:
> FWIW, after I uninstalled the KDE4 helper app from my Linux system 
> (`apt-get remove ksysguard`) I started getting the same error as I see on OS 
> X when I try to increase a process's priority:
> 
> ```
> kf5.kauth: Tried to start an invalid action
> kf5.kauth: Tried to start an invalid action
> ```
> 
> After reinstalling the KDE4 ksysguard package all errors went away and 
> the feature works. Go figure ...
> (I don't have KDE4 ksysguard installed on OS X)

I suggest dropping the workaround for now and investigate how to get KAuth to 
work altogether then.


- Aleix


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


On Sept. 14, 2016, 9:37 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128909/
> ---
> 
> (Updated Sept. 14, 2016, 9:37 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Software on Mac OS X.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This patch implements initial and rather minimal support for OS X, for now 
> focussing purely on process information. That feature is justified as it is 
> used by KDevelop in order to obtain the list of processes one can attach a 
> debugger to.
> 
> Mac OS X is tricky because it requires special privileges in order to obtain 
> certain types of information for any running process. For example, even 
> obtaining the number of threads spawned by a foreign process requires 
> privileges that aren't trivial to set up. I've prepared the terrain, but also 
> implemented a fallback strategy that calls `ps` to be sure that crucial 
> information like the command name is available for all processes.
> 
> 
> Diffs
> -
> 
>   processcore/CMakeLists.txt e7c9263 
>   processcore/Info.plist PRE-CREATION 
>   processcore/helper.cpp d54c8e1 
>   processcore/processes_darwin_p.cpp PRE-CREATION 
>   processcore/processes_local_p.cpp 2bc123f 
> 
> Diff: https://git.reviewboard.kde.org/r/128909/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Frameworks 5.24.0 and Qt 5.6.1
> 
> 
> File Attachments
> 
> 
> Attach to Process widget in KDevelop
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/14/47468811-58cb-40b8-a735-4dd86dce98e1__Screen_Shot_2016-09-14_at_17.38.22.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 128909: initial, minimal support for OS X

[Aleix Pol Gonzalez]

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



Other than that, the patch LGTM.


processcore/helper.cpp (line 133)
<https://git.reviewboard.kde.org/r/128909/#comment66774>

`KAUTH_HELPER_MAIN` doesn't work on OS X?


- Aleix Pol Gonzalez


On Sept. 14, 2016, 9:37 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128909/
> ---
> 
> (Updated Sept. 14, 2016, 9:37 p.m.)
> 
> 
> Review request for KDE Base Apps and KDE Software on Mac OS X.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> ---
> 
> This patch implements initial and rather minimal support for OS X, for now 
> focussing purely on process information. That feature is justified as it is 
> used by KDevelop in order to obtain the list of processes one can attach a 
> debugger to.
> 
> Mac OS X is tricky because it requires special privileges in order to obtain 
> certain types of information for any running process. For example, even 
> obtaining the number of threads spawned by a foreign process requires 
> privileges that aren't trivial to set up. I've prepared the terrain, but also 
> implemented a fallback strategy that calls `ps` to be sure that crucial 
> information like the command name is available for all processes.
> 
> 
> Diffs
> -
> 
>   processcore/CMakeLists.txt e7c9263 
>   processcore/Info.plist PRE-CREATION 
>   processcore/helper.cpp d54c8e1 
>   processcore/processes_darwin_p.cpp PRE-CREATION 
>   processcore/processes_local_p.cpp 2bc123f 
> 
> Diff: https://git.reviewboard.kde.org/r/128909/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Frameworks 5.24.0 and Qt 5.6.1
> 
> 
> File Attachments
> 
> 
> Attach to Process widget in KDevelop
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/09/14/47468811-58cb-40b8-a735-4dd86dce98e1__Screen_Shot_2016-09-14_at_17.38.22.png
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 128637: Remove obsolete kdepasswd docbook

[Aleix Pol Gonzalez]

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


Ship it!




Ship It!

- Aleix Pol Gonzalez


On Aug. 9, 2016, 8:11 p.m., Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128637/
> ---
> 
> (Updated Aug. 9, 2016, 8:11 p.m.)
> 
> 
> Review request for Documentation, KDE Base Apps and David Faure.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> this docbook was for the "Password and User Account" KCM in kde4
> code for the KCM was removed in the frameworks branch, so the docbook is no 
> longer used
> 
> 
> Diffs
> -
> 
>   kdepasswd/CMakeLists.txt 7a62270 
>   kdepasswd/docs/CMakeLists.txt 8cf55fb 
>   kdepasswd/docs/index.docbook 557f458 
>   kdepasswd/docs/password.png 90bc47e 
> 
> Diff: https://git.reviewboard.kde.org/r/128637/diff/
> 
> 
> Testing
> ---
> 
> builds
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

Can't release applications

[Aleix Pol]

Hi,
There's a major blocker when trying to release applications nowadays.
To update the stable branch one needs to commit to the
kde:sysadmin/repo-metadata.git repository, which can't be accessed by
KDE Project maintainers.

How can we solve this?

Aleix

Re: Snappy sprint reporty musing

[Aleix Pol]

On Tue, Jul 26, 2016 at 2:07 PM, Sebastian Kügler  wrote:
> On Tuesday, July 26, 2016 1:08:28 PM CEST Harald Sitter wrote:
>> - a store REST API (of which the reference version is the ubuntu store)
>
> So something like this exists for flatpaks as well, and it's open source?
Note for Flatpak it's ostree repositories, not REST API's.
It's similar to flatpak repositories but not entirely. I'd assume that
the Ubuntu Store will be a tad more complex than a flatpak repository,
as they plan to have a big one for all the stuff (with a big
asterisk). For example, on the Ubuntu Store, you'd be able to have 5
firefoxes.

> For snappy, we'd either have to use the ubuntu store (non-free, right?) or 
> write our own from scratch?
2 things:
- it's seems that they want to set up stores within their instance, so
it's possible to have a custom one with some parameters.
- also it should be possible to set up a separate one.

> Could you expand on the distribution mechanism?
I don't understand the question.

Aleix

Re: Generating QtScript bindings for Qt5

[Aleix Pol]

On Mon, Jul 25, 2016 at 11:37 PM, R.Harish Navnit
 wrote:
> Hi,
>
> In Qt4, we had qtscriptgenerator which helped in generating Qt
> bindings, which are needed to import qt extensions to QScriptEngine
> etc. However, AFAIK this hasn't made it to Qt5 or at least there, is
> no official release yet.
>
> Can anyone point me to or show me how one can generate Qt script
> bindings in Qt5 ?
>
> I have considered using some unofficial Qt5 ports[1][2] of
> qscriptgenerator, but I faced errors while compiling/building them
> from source and they seem to be unmaintained too, since quite some
> time now. I have duly reported them as issues against the relevant
> repos.[3]
>
> What's the best fix/workaround to this ? Any suggestions ?
>
> [1] https://github.com/svalaskevicius/qtscriptgenerator
> [2] https://github.com/svalaskevicius/qtjs-generator
> [3] https://github.com/svalaskevicius/qtjs-generator/issues/24
>
> Regards,
> Harish

Hi Harish,
What are you trying to do? What do you need it for?

I'd recommend against adopting anything using QtScript, as it's deprecated.

Aleix

Re: Review Request 127924: Warn about KDateTimeParser::parseDateUnicode not being implemented

[Aleix Pol Gonzalez]

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



+1

- Aleix Pol Gonzalez


On May 15, 2016, 10:44 a.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127924/
> ---
> 
> (Updated May 15, 2016, 10:44 a.m.)
> 
> 
> Review request for kdelibs and John Layt.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> It's been like that for years, so i don't think anyone is actually using it, 
> but at least give a warning in case someone is.
> 
> I'll do the same thing to kdelibs4support if approved.
> 
> 
> Diffs
> -
> 
>   kdecore/date/kdatetimeparser.cpp a416808 
> 
> Diff: https://git.reviewboard.kde.org/r/127924/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

Re: Review Request 127823: Allow building without strigi on Linux

[Aleix Pol Gonzalez]

> On May 3, 2016, 2:58 p.m., Aleix Pol Gonzalez wrote:
> > Why touch the `if(WIN32)` though? If needed, just make it optional on all 
> > platforms.
> 
> Antonio Rojas wrote:
> That's what I'm doing... Currently it's only optional on WIN32, I'm 
> changing it to be optional regardless of the platform

Eh... fair enough.

+1


- Aleix


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


On May 3, 2016, 2:06 p.m., Antonio Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127823/
> ---
> 
> (Updated May 3, 2016, 2:06 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Now that kde-workspace is obsolete and kdelibs is only used by some still 
> unported applications, it doesn't make sense to force using strigi anymore. 
> This will allow dropping this old unmaintained library from distributions.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e7b2bea 
> 
> Diff: https://git.reviewboard.kde.org/r/127823/diff/
> 
> 
> Testing
> ---
> 
> Builds with and without strigi, everything seems to work
> 
> 
> Thanks,
> 
> Antonio Rojas
> 
>

Re: Review Request 127823: Allow building without strigi on Linux

[Aleix Pol Gonzalez]

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



Why touch the `if(WIN32)` though? If needed, just make it optional on all 
platforms.

- Aleix Pol Gonzalez


On May 3, 2016, 2:06 p.m., Antonio Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127823/
> ---
> 
> (Updated May 3, 2016, 2:06 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Now that kde-workspace is obsolete and kdelibs is only used by some still 
> unported applications, it doesn't make sense to force using strigi anymore. 
> This will allow dropping this old unmaintained library from distributions.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e7b2bea 
> 
> Diff: https://git.reviewboard.kde.org/r/127823/diff/
> 
> 
> Testing
> ---
> 
> Builds with and without strigi, everything seems to work
> 
> 
> Thanks,
> 
> Antonio Rojas
> 
>

Re: Review Request 127515: Port away keditbookmarks from KCmdLine* and K4AboutData

[Aleix Pol Gonzalez]

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



+1 LGTM

- Aleix Pol Gonzalez


On March 28, 2016, 6:06 p.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127515/
> ---
> 
> (Updated March 28, 2016, 6:06 p.m.)
> 
> 
> Review request for KDE Base Apps and David Faure.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> Starting point: the output of convert-kcmdlineargs.pl
> 
> Then cleanups: moved statements as suggested by scripts comments; converted 
> the remaining items (ki18n, etc); fixed headers; added consts, 
> QStringLiteral, translation domain; fixed termination on parser validity 
> errors (away from KCmdLineArgs::usage); etc, etc.
> 
> Set keditbookmarks version to 5.0.
> 
> Explicitly added KI18n and CoreAddons to the required libraries (cmake).
> 
> Commented out app.disableSessionManagement in kbookmarkmerger for now 
> (probably not critical anyway).
> 
> -
> If this proves to be correct, can I push directly push further porting 
> commits/cleanups to keditbookmarks (hoping for a standalone KF5 release in 
> the not far future) or do you prefer to review all changes?
> 
> 
> Diffs
> -
> 
>   keditbookmarks/CMakeLists.txt b44f389 
>   keditbookmarks/kbookmarkmerger.cpp 5f17a98 
>   keditbookmarks/main.cpp 4302318 
> 
> Diff: https://git.reviewboard.kde.org/r/127515/diff/
> 
> 
> Testing
> ---
> 
> Compile, the two programs can run, now with proper version details. No 
> apparent regression in parameter parsing.
> 
> 
> Thanks,
> 
> Luigi Toscano
> 
>

Re: build.kde.org What have you done to it!?!?! Serious explanation inside.

[Aleix Pol]

On Wed, Mar 23, 2016 at 11:02 PM, Scarlett Clark
 wrote:
> Ok, so we are migrating to docker builds tomorrow, (Ben's available time)
> Rather than continually mess with two set of builds I am only working on
> sandbox in preparation. The good news is many unstable builds have gone
> green, but will not be seen until we are live :) So I am hereby giving
> NOTICE of disruption in service for build.kde.org We hope for a swift and
> smooth transition.
> Thanks!!
> Scarlett

Looking forward to it!

And looking forward to the docs. :)

Good luck!
Aleix

Re: Review Request 127264: Set CMP0064 to OLD to suppress CMake warnings

[Aleix Pol Gonzalez]

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




cmake/modules/KDE4Macros.cmake (line 1003)
<https://git.reviewboard.kde.org/r/127264/#comment63484>

Without the conditionals, the code would work just as well.


- Aleix Pol Gonzalez


On March 3, 2016, 1:58 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127264/
> ---
> 
> (Updated March 3, 2016, 1:58 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This follows the same idea from 826a5ff3278f492a99ac6827614e1d0ca40a45e8
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 5bb2ffa 
> 
> Diff: https://git.reviewboard.kde.org/r/127264/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>

Re: KDE file dialog

[Aleix Pol]

On Sun, Feb 28, 2016 at 8:01 PM, Riccardo Iaconelli  wrote:
> On 28 February 2016 at 15:58, Luigi Toscano  wrote:
>>
>> This is what I use:
>> export QT_QPA_PLATFORMTHEME=kde
>
> (btw, shouldn't this be "plasma"?)

The string is in Qt, AFAIR. It probably can't be changed until Qt 6 if
we don't want to mess with existing installations.

Aleix

Re: Minuet (music education software) moved to kdereview

[Aleix Pol]

On Mon, Feb 1, 2016 at 12:30 AM, Albert Astals Cid  wrote:
> El Tuesday 26 January 2016, a les 10:15:47, Andreas Cord-Landwehr va escriure:
>> On Monday 25 January 2016 21:48:27 Albert Astals Cid wrote:
>> > El Sunday 24 January 2016, a les 16:50:18, Andreas Cord-Landwehr va
>>
>> escriure:
>> > > * it looks strange to me that in minuet/cmake/ there are Config-files
>> > > for
>> > > the 3rd-party library drumstick. My understanding was that such Config
>> > > files should only be shipped with the respective library (maybe someone
>> > > with a deeper CMake-knowledge can comment?)
>> >
>> > If upstream ships a cmake file awesome, but if not then we have to find it
>> > having our own cmake file.
>>
>> Absolutely, but shouldn't that be find-files then instead of config-files?
>> I always had the perception that those are quite different.
>
> Right, it most probably be a Find file not a Config file, as far as I
> understand it Config files are mostly for projects that ship the cmake file as
> part of their install.
>
> Can someone with more cmake knowledge comment?

Yes, the idea is that *Config.cmake files should be distributed by the
framework itself, otherwise you need to find it. It probably works
though, because such things are seldom checked within cmake though.

I suggest turning it into a normal Find*.cmake file. Or get Drumstick
to provide a cmake file, which is always more convenient.

Aleix

Re: Review Request 126704: [kde-gtk-config] Implement changing cursor theme for GTK applications

[Aleix Pol Gonzalez]

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



As put by reviewboard, the patch only has whitespace changes...

- Aleix Pol Gonzalez


On Jan. 13, 2016, 7:03 a.m., Andrey Bondrov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126704/
> ---
> 
> (Updated Jan. 13, 2016, 7:03 a.m.)
> 
> 
> Review request for kde-workspace, Aleix Pol Gonzalez and Harald Sitter.
> 
> 
> Repository: kde-gtk-config
> 
> 
> Description
> ---
> 
> Implement changing cursor theme for GTK applications. It's needed to set 
> cursor theme for Firefox and other applications that use GTK configs to set 
> cursors.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 78814fc 
>   src/abstractappearance.h 378b71d 
>   src/abstractappearance.cpp 6d0dc27 
>   src/appearancegtk2.cpp b1e0b52 
>   src/appearancegtk3.cpp 5c481c9 
>   src/appearencegtk.h f797a08 
>   src/appearencegtk.cpp 9dee2d5 
>   src/cursorthemesmodel.h PRE-CREATION 
>   src/cursorthemesmodel.cpp PRE-CREATION 
>   src/gtkconfigkcmodule.h 032a5ef 
>   src/gtkconfigkcmodule.cpp 3d70f6e 
>   src/ui/gui.ui ebfacdf 
> 
> Diff: https://git.reviewboard.kde.org/r/126704/diff/
> 
> 
> Testing
> ---
> 
> Tested on my local machine. Seems to do what it should properly.
> 
> 
> Thanks,
> 
> Andrey Bondrov
> 
>

Re: Review Request 126704: [kde-gtk-config] Implement changing cursor theme for GTK applications

[Aleix Pol Gonzalez]

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


Fix it, then Ship it!




Fix copyright and push.


src/cursorthemesmodel.h (line 3)
<https://git.reviewboard.kde.org/r/126704/#comment62216>

Fix copyright to your name and this year.



src/cursorthemesmodel.cpp (line 3)
<https://git.reviewboard.kde.org/r/126704/#comment62217>

Copyright


- Aleix Pol Gonzalez


On Jan. 16, 2016, 5:14 p.m., Andrey Bondrov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126704/
> ---
> 
> (Updated Jan. 16, 2016, 5:14 p.m.)
> 
> 
> Review request for kde-workspace, Aleix Pol Gonzalez and Harald Sitter.
> 
> 
> Repository: kde-gtk-config
> 
> 
> Description
> ---
> 
> Implement changing cursor theme for GTK applications. It's needed to set 
> cursor theme for Firefox and other applications that use GTK configs to set 
> cursors.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 78814fc 
>   src/abstractappearance.h 378b71d 
>   src/abstractappearance.cpp 6d0dc27 
>   src/appearancegtk2.cpp b1e0b52 
>   src/appearancegtk3.cpp 5c481c9 
>   src/appearencegtk.h f797a08 
>   src/appearencegtk.cpp 9dee2d5 
>   src/cursorthemesmodel.h PRE-CREATION 
>   src/cursorthemesmodel.cpp PRE-CREATION 
>   src/gtkconfigkcmodule.h 032a5ef 
>   src/gtkconfigkcmodule.cpp 3d70f6e 
>   src/ui/gui.ui ebfacdf 
> 
> Diff: https://git.reviewboard.kde.org/r/126704/diff/
> 
> 
> Testing
> ---
> 
> Tested on my local machine. Seems to do what it should properly.
> 
> 
> Thanks,
> 
> Andrey Bondrov
> 
>

Re: Review Request 126704: [kde-gtk-config] Implement changing cursor theme for GTK applications

[Aleix Pol Gonzalez]

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


All in all it looks quite good.

I'd suggest creating a CursorThemesModel inheriting IconThemesModel that 
overrides some methods (you can add virtuals). Otherwise we're adding weirdly 
specific logic.

Also I'd say it would be really good to be able to show some preview of the 
theme somehow, otherwise it's hard to tell them apart.

- Aleix Pol Gonzalez


On Jan. 10, 2016, 2:43 p.m., Andrey Bondrov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126704/
> ---
> 
> (Updated Jan. 10, 2016, 2:43 p.m.)
> 
> 
> Review request for kde-workspace, Aleix Pol Gonzalez and Harald Sitter.
> 
> 
> Repository: kde-gtk-config
> 
> 
> Description
> ---
> 
> Implement changing cursor theme for GTK applications. It's needed to set 
> cursor theme for Firefox and other applications that use GTK configs to set 
> cursors.
> 
> 
> Diffs
> -
> 
>   src/abstractappearance.h 378b71d 
>   src/abstractappearance.cpp 6d0dc27 
>   src/appearancegtk2.cpp b1e0b52 
>   src/appearancegtk3.cpp 5c481c9 
>   src/appearencegtk.h f797a08 
>   src/appearencegtk.cpp 9dee2d5 
>   src/gtkconfigkcmodule.h 032a5ef 
>   src/gtkconfigkcmodule.cpp 3d70f6e 
>   src/iconthemesmodel.h 2f0c453 
>   src/iconthemesmodel.cpp 07c7ad7 
>   src/ui/gui.ui ebfacdf 
> 
> Diff: https://git.reviewboard.kde.org/r/126704/diff/
> 
> 
> Testing
> ---
> 
> Tested on my local machine. Seems to do what it should properly.
> 
> 
> Thanks,
> 
> Andrey Bondrov
> 
>

Re: Review Request 126704: [kde-gtk-config] Implement changing cursor theme for GTK applications

[Aleix Pol Gonzalez]

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



src/iconthemesmodel.cpp (line 54)
<https://git.reviewboard.kde.org/r/126704/#comment62152>

No-op change.



src/iconthemesmodel.cpp (line 98)
<https://git.reviewboard.kde.org/r/126704/#comment62153>

Now that you have the CursorsThemeModel that shouldn't be needed anymore.

If it still is, add a virtual.


- Aleix Pol Gonzalez


On Jan. 12, 2016, 4:53 p.m., Andrey Bondrov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126704/
> ---
> 
> (Updated Jan. 12, 2016, 4:53 p.m.)
> 
> 
> Review request for kde-workspace, Aleix Pol Gonzalez and Harald Sitter.
> 
> 
> Repository: kde-gtk-config
> 
> 
> Description
> ---
> 
> Implement changing cursor theme for GTK applications. It's needed to set 
> cursor theme for Firefox and other applications that use GTK configs to set 
> cursors.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt bf002d1 
>   src/abstractappearance.h 378b71d 
>   src/abstractappearance.cpp 6d0dc27 
>   src/appearancegtk2.cpp b1e0b52 
>   src/appearancegtk3.cpp 5c481c9 
>   src/appearencegtk.h f797a08 
>   src/appearencegtk.cpp 9dee2d5 
>   src/cursorthemesmodel.h PRE-CREATION 
>   src/cursorthemesmodel.cpp PRE-CREATION 
>   src/gtkconfigkcmodule.h 032a5ef 
>   src/gtkconfigkcmodule.cpp 3d70f6e 
>   src/iconthemesmodel.cpp 07c7ad7 
>   src/ui/gui.ui ebfacdf 
> 
> Diff: https://git.reviewboard.kde.org/r/126704/diff/
> 
> 
> Testing
> ---
> 
> Tested on my local machine. Seems to do what it should properly.
> 
> 
> Thanks,
> 
> Andrey Bondrov
> 
>

Policy regarding QtWebKit and QtScript

[Aleix Pol]

Hi,
Soon Qt 5.6 will be released and with it, 2 quite widely used
frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but
I think this is much less of a problem.

I'd say we need a plan to figure out what to do with these
dependencies. I don't think assuming that they will stay around is
very wise, so I'd suggest to come up collectively or specifically on
each project how to deal with those.

I'd say it's especially pressing on KDE Frameworks where Qt5::Script
is still quite widely used (kio, ki18n, ktexteditor,
plasma-framework).

Aleix

Re: Please review Snorenotify (Finish Incubating)

[Aleix Pol]

On Wed, Nov 18, 2015 at 11:48 PM, Hannah von Reth  wrote:
> Hi there,
>
> Mario guided me until now through the incubation process and we think it is
> time to move Snorenotify from playground to extragear.
> Snorenotify is a notification framework supporting Linux, Windows and Mac
> OSX.
> It is not meant to replace Knotifications, it is more targeted on Qt
> applications without dependency to the plasma desktop, so it might become a
> backend for Knotifications.
>
> I guess you can find the most important information here
> https://community.kde.org/Incubator/Projects/Snorenotify.
>
> Besides Snorenotify there is also Snoretoast, a sub project of Snorenotify,
> https://quickgit.kde.org/?p=snoretoast.git.
> Snoretoast  is a command line application and used within Snorenotify for
> the Windows Toast notifications.
> The application can only be build using the Microsoft compiler.
>
> So it would be great if Snorenotify could become a official KDE library and
> maybe even a framework someday.
> Currently it is used by Quassel and Tomahawk but hopefully more will start
> to use it soon.
>
> So please review Snorenotify.
>
> If you find the idea of Snorenotify useful or you fancy notifications, like
> I do, feel free to contribute ;)  or start to use Snorenotify.

Hi Hannah,
I'm happy that you're decided to push this forward, I think it's a
framework that could be definitely useful. In KDE Connect we'd like to
be able to use it instead of KNotifications because it's leaner and
more straightforward to our notifications use-case. As I said before,
I already ported KDE Connect to use snore, nevertheless there's some
issues like the API that I would suggest to review before committing
to API and ABI stability.

Here's some thoughts:
- It feels overly complex that the Notification object is passed
around by value rather than by reference. For starters, being able to
connect to the notification would be very handy. I work-arounded it by
setting a hint with the relevant information, but I have the feeling
the API would be slightly smoother.
- There's a hard dependency on QtWidgets from the very core of the
framework. This requires applications that would use it to use
QApplication. In the case of KDE Connect, for instance, the plan was
to make it possible to have it in a QCoreApplication (or
QGuiApplication at least). It's a daemon from which we consider that
it's acceptable to show notifications but we don't really plan to open
a dialog from there. Do you think it could/should be worked out?
- There's a daemon. We're kind of trying to get rid of daemons. When
is it needed?
- enum values are all-caps joined by underscore (e.g. GLOBAL_SETTING).
Camel-case would be more Qt-friendly.
- Some methods use wid as a windows id. Please use QWindow whenever
possible, it's being an issue in Plasma nowadays already.
- Maybe we can port the internal logging infrastructure to just use
QLoggingCategory?

Cheers! :)
Aleix