Re: MegaRelease Freezes - Re: Release schedule proposal for the February MegaRelease

[Aleix Pol]

On Tue, Sep 26, 2023 at 12:29 AM Albert Astals Cid  wrote:
>
> El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid va
> escriure:
> > https://community.kde.org/Schedules/February_2024_MegaRelease
> >
> > Beta 1 is during Qt World Summit that is not ideal but I guess doable?
> >
> > I'll answer to this email with a few other emails things i thing we have to
> > discuss to try to organize the discusion earlier.
>
> Do we want common times for dependency/feature/string freezes for all the 3
> products or different for each of them?
>
> I have no particular opinion.

I'd say that by nature KF needs to freeze before Plasma & Apps.

I don't think there's any difference between apps and Plasma.

I'll include the Plasma and Frameworks lists JIC.

Aleix

Re: Plasma-integration and branches

[Aleix Pol]

On Fri, Jun 16, 2023 at 1:37 PM David Edmundson
 wrote:
>
> We've discussed a few times an issue with plasma-integration and
> supporting Qt5 and Qt6 clients.
>
> When we release Plasma 6, we need to ensure that a Qt5 and Qt6 builds
> are released. We need users to have both as they are plugins where
> users might have Qt5 and Qt6 codebases.
>
> Right now master branch supports both. The Qt branches are massively
> divergent for Qt 5 and 6 clients and we're filling it with a huge mess
> of if statements and it's a pain to work on. There's patches blocked
> on needing ifdefs.
>
> The proposal is we make a Plasma/6.0-qt5 branch based off the current
> Plasma/5.27 branch but fixing the version numbers.
>
> At release time we will release a tarball from Plasma/6.0 and
> Plasma/6.0-qt5 with different tarball names.
> Translations would have to be considered. Pragmatically translations
> will be identical to 5.27, though it's not guaranteed.
>
> Before we go ahead, are there any objections and can release team
> people and i18n confirm they're ok with the above.
>
> David

+1

Re: weird plural in XDG translation

[Aleix Pol]

It was indeed my intention. I don't know whether it was the right choice. :D

I'd leave it as is if it works for everyone.

Thanks for checking!
Aleix

On Mon, Apr 3, 2023 at 9:11 PM Frederik Schwarzer  wrote:
>
> On Monday, April 3, 2023 8:48:04 PM CEST Aleix Pol wrote:
>
> Hi Aleix,
>
> > Where do you think the problem is?
> >
> > If you are sharing only one stream, we just say we are sharing a
> > stream with %2, if there are several we specify how many.
> >
> > I'd expect 1 stream to be the norm anyway.
>
> I was only sumbling over the difference in wording. Usually with plurals it's 
> "One element / %1 Elements" or so, here it is "contents / %1 video streams". 
> Just wanted to double check if that's inntended.
>
> Cheers,
> Frederik
>
>
> > On Mon, Apr 3, 2023 at 5:38 PM Luigi Toscano  
> > wrote:
> > >
> > > Frederik Schwarzer ha scritto:
> > > > Hi,
> > > >
> > > > in xdg-desktop-portal-kde.po we have the following message:
> > > >
> > > > #: src/session.cpp:271
> > > > #, kde-format
> > > > msgctxt "%1 number of screens, %2 the app that receives them"
> > > > msgid "Sharing contents to %2"
> > > > msgid_plural "%1 video streams to %2"
> > > >
> > > > Well, it *could* be alright but it might as well be a mistake. So I 
> > > > wanted to ask if anyone knows about this.
> > > >
> > >
> > > Better ask plasma people, cc-ing...
> > >
> > > Ciao
> > > --
> > > Luigi
> >
>
>
>
>

Re: weird plural in XDG translation

[Aleix Pol]

Hi Frederik,
Where do you think the problem is?

If you are sharing only one stream, we just say we are sharing a
stream with %2, if there are several we specify how many.

I'd expect 1 stream to be the norm anyway.

Aleix

On Mon, Apr 3, 2023 at 5:38 PM Luigi Toscano  wrote:
>
> Frederik Schwarzer ha scritto:
> > Hi,
> >
> > in xdg-desktop-portal-kde.po we have the following message:
> >
> > #: src/session.cpp:271
> > #, kde-format
> > msgctxt "%1 number of screens, %2 the app that receives them"
> > msgid "Sharing contents to %2"
> > msgid_plural "%1 video streams to %2"
> >
> > Well, it *could* be alright but it might as well be a mistake. So I wanted 
> > to ask if anyone knows about this.
> >
>
> Better ask plasma people, cc-ing...
>
> Ciao
> --
> Luigi

Re: Outline intensity setting for 5.27

[Aleix Pol]

This is a new feature and has new strings. This is not something we
can shove into a stable release, I'm sorry.

Aleix

On Wed, Mar 8, 2023 at 5:46 PM Akseli Lahtinen  wrote:
>
> Hi!
>
> The new outline feature I've made has caused some annoyance among users,
> so I have now made an outline intensity setting for it.
>
> You can find it here https://invent.kde.org/plasma/breeze/-/merge_requests/292
>
> I would like to see it in 5.27 eventually, since this setting is something 
> people
> really want: People can turn the outlines off or make them even more intense,
> which can help with accessibility issues further.
>
> Having this setting in 5.27 would likely ease everyone's mind.
>
> Br,
> Akseli Lahtinen
>
> PS. I sent this mail before I had subscribed to the mailing list, but seems 
> it got drowned in a
> spam filter or something. I have now subscribed to the mailing list however.
>
>

Re: post 5.27 kickoff meeting?

[Aleix Pol]

On Tue, Feb 14, 2023 at 6:25 PM John P  wrote:
>
> Hey Jonathan, good to meet ya.
>
> I've taken a high interest in Plasma's development in the past month (been 
> using Plasma for over two years though), so I joined the mailing list to keep 
> updated. I did have a question though.
>
> For those that aren't currently contributing but looking to begin 
> contributing allowed to sit in on these calls to get a feel of how things are 
> run and how processes work? Or are these meetings contributors only? Asking 
> for myself.

You can participate in all aspects of this community, and of course
this includes the meetings.

Welcome!
Aleix

Re: post 5.27 kickoff meeting?

[Aleix Pol]

On Tue, Feb 14, 2023 at 5:23 PM Jonathan Riddell  wrote:
>
> Normally we might have a kickoff meeting so decide a timetable and plan for 
> the next Plasma release.  There's no 5.28 planned in the hope that it would 
> be ready to move to KF6 shortly.  Is there a need for a kickoff meeting soon?
>
> Jonathan

There sure is a need for a Plasma 6 kickoff meeting. Or two or three. :)

Also I sprint which we keep mentioning but never closing on.

Aleix

Re: Soft Feature Freeze Approaching

[Aleix Pol]

I would like to get this included in 5.27. I feel like the
RemoteDesktop XDP interface is useless without it.

Aleix

On Tue, Jan 3, 2023 at 5:37 PM David Edmundson
 wrote:
>
> Soft freeze takes effect on Thursday the 5th January After that we
> are to avoid any big changes and huge refactors until Plasma 6.
>
> All new repos should be announced and through kde-review by this point.
>
> Small features can land until the full final hard freeze on the 19th January.
> CC this thread if anything is slightly controversial or exceptions are needed.
>
> If there are any major things stuck in review, please respond to this
> email and make a fuss so they can be prioritised.
>
> David Edmundson
>
> https://community.kde.org/Schedules/Plasma_5

Re: Cherry-picking policy

[Aleix Pol]

+1, thanks for bringing this up, this is also something I'd pondered at times.

Adding  sysadmin on CC as automating this has been brought up and
AFAIR this was something they'd been working on before.

Aleix

On Wed, Nov 16, 2022 at 11:12 AM Vlad Zahorodnii
 wrote:
>
> Hi,
>
> At the moment, we have the following bugfixing workflow in plasma:
>
> * fix a bug in master
> * cherry pick the fix to stable branch(es)
>
> The last step is usually done without creating a MR. If there is a merge
> conflict, some people do create a MR though.
>
> I propose to make creating MRs for bugfix backports mandatory:
>
> - this helps us to ensure that CI is happy
> - increases the visibility of what happens in stable branches. For
> example some people help with backporting bugfixes, but they can forget
> to include a commit if the original MR included multiple commits.
> Hopefully, this can help us to catch these cases
>
> Ideally this should be automated, but we have no tooling to do that.
>
> Thoughts?
>
> Regards,
> Vlad

[Powerdevil] [Bug 348529] When screen is locked, turn off screen at some point

[Aleix Pol]

https://bugs.kde.org/show_bug.cgi?id=348529

Aleix Pol  changed:

   What|Removed |Added

 CC||aleix...@kde.org

--- Comment #42 from Aleix Pol  ---
I'm sorry, I was just pointed to this MR and am not sure what the problem
exactly is. 

Shouldn't the default mechanisms from PowerDevil kick in here and eventually
dpms=off the screen?

One thing that the new changes offer is that the script can be switched to use
"kscreen-doctor --dpms off" instead of messing with the powerdevil profiles.

Also you can press Esc to dim the screen, although I understand this isn't
exactly what we're after here.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: plasma-remotecontrollers and 5.26

[Aleix Pol]

Yes, we have been working with that in mind.

I think you included the wrong Aditya 

Aleix

El dl., 8 d’ag. 2022, 16:05, Jonathan Riddell  va escriure:

> There was talk of including plasma-remotecontrollers in Plasma 5.25 but it
> got pulled because it wasn't through KDE review.  Now that we're including
> plasma-bigscreen should it be considered again?
>
> Jonathan
>
>

Re: semicolons and the policy that was none

[Aleix Pol]

On Wed, Aug 10, 2022 at 6:42 PM Carl Schwan  wrote:
>
> Le mercredi 10 août 2022 à 3:57 PM, Harald Sitter  a écrit :
>
> > Aloha,
> >
> > Someone recently dug up this page from 2012
> >
> > https://community.kde.org/Plasma/QMLStyle#JS_Code_Blocks
> >
> > First I'd like to point out that this page isn't a policy page, if it
> > was meant to be then it needs to be linked on the policies page and
> > supposedly somehow agreed upon, which I don't recall this one being
> > (but then I wasn't really following plasma 10 years ago).
> >
> > Secondly, can we clarify our stance on semicolons?
> >
> > a) we don't care, do whatever you feel like but be consistent with
> > your surrounding
> > b) use semicolons never [*unless required]
> > c) use semicolons always
> > d) use semicolons sometimes [*define sometimes]
> >
> > Please cast votes
>
> I would vote for c, it's more consistent with C++ and avoids some rare
> issues where removing the semicolon creates issues. This is what I'd been
> already doing for the app I maintain.
>
> Cheers,
> Carl
>
> PS: speaking of outdated policies, we ought to maybe revisit this one
> https://community.kde.org/Policies/Packaging_Policy since we provide
> binary packages in some cases now
>
> and we should probably also try to enforce this one
> https://community.kde.org/Frameworks/Frameworks_Documentation_Policy
> more often in kirigami and plasma frameworks
>
>
> >
> > Please cast votes
> >
> > I vote for a) or b) because the point of having a policy on this
> > eludes me entirely
> >
> > HS

I don't know. We really are not adding ; everywhere now and I can
already feel the waves of pointless MRs adding/removing ;.

Big A) from me.

Aleix

Re: testing UIs and improving a11y all at once!

[Aleix Pol]

On Wed, Aug 10, 2022 at 12:29 PM Harald Sitter  wrote:
>
> Servus,
>
> A while ago I prototyped a "new" approach to UI testing and I'm
> wondering if there's general interest in doing more Plasma testing
> using it. I'm able to invest time in polishing the experience for us.
>
> Very rough prototype: https://invent.kde.org/sitter/selenium-webdriver-at-spi
>
> The testing is run through the accessibility API we have on Linux
> https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ as well as the
> testing API selenium https://www.selenium.dev/ respectively the more
> specific appium https://appium.io/
>
> Architecturally appium is an extension to selenium and selenium is a
> client-server system where the client is the test and the server is a
> so called webdriver. Webdriver is a standardized well-defined API of
> various UI interactions https://www.w3.org/TR/webdriver/ and we'd
> implement one based on the a11y APIs (the feature sets match fairly
> well).
>
> Since selenium has wide spread use across the industry we get to use
> excellent tooling on the client without any extra work from us. And
> because it is so wide spread the stuff is generally very well
> maintained. All we need to maintain is the webdriver that interacts
> with the a11y API.
>
> The way this type of testing works is by UI interaction and state
> validation. There is a kcalc test available in the prototype repo [1]
> - the test operates the various UI elements to perform a calculation
> and then checks that the output UI element contains the expected
> value.
>
> A simple plasma test might open kickoff, and launch one of the
> favorites, then validate that indeed a new window has opened.
>
> Since all this is driven by the a11y API there is the additional
> advantage of making us notice a11y problems and deal with them,
> resulting in bettery a11y support in the long run. Two birds, one
> stone!
>
> What do you reckon?
>
> [1] 
> https://invent.kde.org/sitter/selenium-webdriver-at-spi/-/blob/91486b50995ade23c6b03a54f77347c263c2f03a/calculatortest.py
>
> HS

It looks super interesting, always refreshing to see a plan to kill
such two very important birds. :)

Best,
Aleix

Re: Latte Dock Farewell

[Aleix Pol]

On Sat, Jul 30, 2022 at 2:31 PM Nicolas Fella  wrote:
>
> On 7/27/22 13:14, Aleix Pol wrote:
> > On Wed, Jul 27, 2022 at 12:15 PM Jonathan Riddell  wrote:
> >> Michail has announced he's not going to be developing Latte Dock in future
> >> https://psifidotos.blogspot.com/2022/07/latte-dock-farewell.html
> >> Thanks for all your work Michail!
> >>
> >> As far as we can tell Latte Dock is a popular Plasma addon.  If anyone is 
> >> looking for a project to take on this is your chance.
> >>
> >> Otherwise I expect it'll stop working before too long as it uses various 
> >> private APIs so we'll need to tell distros to stop shipping it when it 
> >> does.
> > Maybe someone could sit down and see which private APIs are being
> > used? then we can make sure it's in the right side of things and it
> > keeps working *FOREVER*.
> >
> > Aleix
>
> I think it could make sense to add Latte to the regular Plasma release,
> for the following reasons:
>
>   - It gives us regular releases "for free", which makes sure that
> occasional fixes/improvements actually reach users. It would be a shame
> if those never see the users because no one feels responsible enough to
> make a release
>
> - Having Plasma and Latte in sync helps with the private API problem
> since a release of Latte has to only support one Plasma release. See
> e.g. the recent KPipeWire topic where Plasma wanted to remove things
> Latte uses.

+1

Re: Latte Dock Farewell

[Aleix Pol]

On Wed, Jul 27, 2022 at 12:15 PM Jonathan Riddell  wrote:
>
> Michail has announced he's not going to be developing Latte Dock in future
> https://psifidotos.blogspot.com/2022/07/latte-dock-farewell.html
> Thanks for all your work Michail!
>
> As far as we can tell Latte Dock is a popular Plasma addon.  If anyone is 
> looking for a project to take on this is your chance.
>
> Otherwise I expect it'll stop working before too long as it uses various 
> private APIs so we'll need to tell distros to stop shipping it when it does.

Maybe someone could sit down and see which private APIs are being
used? then we can make sure it's in the right side of things and it
keeps working *FOREVER*.

Aleix

Re: KPipeWire dependency

[Aleix Pol]

On Tue, May 31, 2022 at 5:48 PM Luca Beltrame  wrote:
>
> In data martedì 31 maggio 2022 13:53:43 CEST, Aleix Pol ha scritto:
> > Sorry didn't see your e-mail, I addressed it yesterday.
>
> With these changes I was able to package KPipeWire successfully. Two more
> minor nits:
>
> - PROJECT_VERSION is not the same as the other Plasma projects in master
> (instead of 5.25.xxx it's 5.24.xxx).

Addressed, thanks!

> - A very basic README would be useful.
https://invent.kde.org/plasma/kpipewire/-/blob/master/README.md

Re: KPipeWire dependency

[Aleix Pol]

Sorry didn't see your e-mail, I addressed it yesterday.

Aleix

On Mon, May 30, 2022 at 6:06 PM Luca Beltrame  wrote:
>
> In data lunedì 30 maggio 2022 13:04:35 CEST, Aleix Pol ha scritto:
>
> Hello Aleix,
>
> > Addressed most "reuse lint" warnings in there.
> > Thanks for pointing it out!
>
> Thanks for fixing. While packaging it for openSUSE I've noticed that it
> installs libKPipeWire.so and libKPipeWireRecord.so, but the libraries don't
> have any soversion set. Are they meant to be used as shared libraries? If so,
> can this be addressed?
>
> --
> Luca Beltrame
> GPG key ID:  A29D259B

Re: KPipeWire dependency

[Aleix Pol]

Addressed most "reuse lint" warnings in there.

Thanks for pointing it out!
Aleix

On Mon, May 30, 2022 at 5:57 AM Luca Beltrame  wrote:
>
> In data lunedì 30 maggio 2022 02:08:25 CEST, Aleix Pol ha scritto:
>
> Hello Aleix,
>
> > This means it becomes a dependency for the master branch and thus the
> > unstable builds.
>
> KiPipeWire does not ship a license in its repository: would you be able to add
> one? Or packaging it would not be possible.
>
> --
> Luca Beltrame - KDE Forums team
> GPG key ID: A29D259B

KPipeWire dependency

[Aleix Pol]

Hi,
Just a quick note that I've merged the plasma-desktop MR that switches
to using KPipeWire instead of the components within plasma-workspace.
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/949
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/242#

This means it becomes a dependency for the master branch and thus the
unstable builds.

Cheers!
Aleix

Re: 5.24 LTS release dates

[Aleix Pol]

Sounds good, thanks Jonathan!

Aleix

On Fri, May 6, 2022 at 12:56 PM Jonathan Riddell  wrote:
>
> I'm proposing Tuesday July 5 for a 5.24.6LTS  release.  It's 11 weeks after 
> the 5.24.5 release and is mostly timed to be useful to Kubuntu.
>
> Jonathan
>
>
> On Thu, 5 May 2022 at 10:34, Jonathan Riddell  wrote:
>>
>> Does anyone have a request for a release date for the next or following 5.24 
>> LTS releases?
>>
>> I've had one from Kubuntu asking "the .6 is at least a few weeks to a month 
>> before the 22.04.1 point release on August 4"
>>
>> Any more?
>>
>> Jonathan
>>

Re: Soft Feature Freeze Tomorrow

[Aleix Pol]

On Wed, May 4, 2022 at 11:47 PM David Edmundson
 wrote:
>
> As a reminder it is the soft feature freeze tomorrow 05/05/2022
>
> Any massive refactors, new repos and big changes that have potential
> fallout should land by the end of the day.
>
> It is not a hard feature freeze, small features can still be added
> that goes right up until the day of the beta 19th of May. Basically
> use some common sense.
>
> The goal of the soft feature freeze is to make sure we don't have to
> rush and panic last minute. If there's stuff on review that isn't
> quite landed yet - don't rush and panic(!) - use this thread and let
> us know. The sooner the better.
>
> David

As for new repos, there's plasma-remotecontrollers
https://invent.kde.org/plasma-bigscreen/plasma-remotecontrollers/

This should be released with 5.25, Bart (CC) was asking the other day
how to get it released. Jonathan could you maybe look into it with
him?

Thanks!
Aleix

Re: Require passing unit tests

[Aleix Pol]

On Mon, Apr 11, 2022 at 11:10 AM David Edmundson
 wrote:
>
> There's a new flag we can set on CI to fail a job if unit tests fail.
> https://www.volkerkrause.eu/2022/04/09/kde-ci-required-unit-tests.html
>
> Catching things as early as possible will unquestionably be a good thing.
>
> Realistically right now this is going to cause some merge failures as
> we know some tests are flakey. It might act as good motivation to fix
> them, it might just be annoying.
>
> https://build.kde.org/job/Plasma/view/Everything%20-%20kf5-qt5/ is a
> good enough overview things either yellow or blue with a cloud will
> probably be issues.
>
> Should we:
>  - apply everywhere?
>  - apply in a few safe places?

It could make sense to start with the one projects where we don't have
flaky tests.

Either way, I think our mid-term plan should be to apply this everywhere.

Aleix

Re: Critical Denial of Service bugs in Discover

[Aleix Pol]

On Sat, Mar 5, 2022 at 8:36 AM Ben Cooksley  wrote:

> On Fri, Mar 4, 2022 at 12:49 AM Aleix Pol  wrote:
>
>> I'd say wireshark is too low level for what the problem is here. We are
>> talking about having too many HTTP requests for specific URLs.
>>
>
> Correct, I guess the difference in our approaches comes from a "before
> release" to a "monitor after release" angle to things.
> I'd like to see increased scrutiny during the development process as well
> to make sure that we release code that operates properly from Day 1.
>

A way to do this could be using commit hooks that do not allow to reach
certain services. (which we discussed in private chat).
We could also analyse at cmake time the knsrc files we install, but this
has a very limited and specific scope.


> I can think two main measures:
>> - Trigger an alarm (an e-mail notification?) if there's a specific
>> UserAgent that has a specific portion of the queries we have in a specific
>> day in the services we care about.
>> - Offer plots to see how queries by UserAgent evolve over the last couple
>> of months (or couple of years).
>>
>
> At the moment our ability to analyse our logs is somewhat limited by our
> Privacy Policy - https://kde.org/privacypolicy/
> Currently we don't have any provision for long term storage of
> this information even on an aggregated basis - so we would need to update
> this first.
>

Hopefully the NDA should help here and it doesn't seem all that far away. I
know Neofytos and Ade have been working on it lately.

The second issue there is that we are transitioning users to contact a CDN
> based endpoint (which is substantially more scalable).
> This does mean we lose visibility on data such as User Agents and the URLs
> being impacted though as we only get aggregated data unless we ask for
> raw logs - which makes implementing something like what you've described
> much harder.
>

That does seem like a stopper. Still, it seems like it's not that big of a
problem when there is a CDN, so we better worry about the other cases.

Aleix

Re: Critical Denial of Service bugs in Discover

[Aleix Pol]

I'd say wireshark is too low level for what the problem is here. We are
talking about having too many HTTP requests for specific URLs.

I can think two main measures:
- Trigger an alarm (an e-mail notification?) if there's a specific
UserAgent that has a specific portion of the queries we have in a specific
day in the services we care about.
- Offer plots to see how queries by UserAgent evolve over the last couple
of months (or couple of years).

Aleix


On Thu, Mar 3, 2022 at 9:59 AM Ben Cooksley  wrote:

> On Thu, Mar 3, 2022 at 8:41 AM Aleix Pol  wrote:
>
>> (dropping the distros list)
>>
>> @sysadmin have you been able to look into any tools we devs can have to
>> make sure this situation doesn't repeat in the future?
>>
>
> Hi Aleix,
>
> To be honest i've been struggling to think of ways that we could detect
> this on the server side prior to it becoming a massive issue.
> By the time an issue is evident server side it is usually much too late.
>
> The main tools i'd usually recommend would be the standard tools you would
> use for monitoring the network activity of any application - such as
> Wireshark.
>
> Is there something you were thinking of specifically in terms of us being
> able to provide?
>
> Thanks,
> Ben
>
>
>>
>> Aleix
>>
>> On Thu, Feb 10, 2022 at 1:10 PM Aleix Pol  wrote:
>>
>>> On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley  wrote:
>>> >
>>> >
>>> >
>>> > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol  wrote:
>>> >>
>>> >> [Snip]
>>> >>
>>> >> We still haven't discussed here is how to prevent this problem from
>>> >> happening again.
>>> >>
>>> >> If we don't have information about what is happening, we cannot fix
>>> problems.
>>> >
>>> >
>>> > Part of the issue here is that the problem only came to Sysadmin
>>> attention very recently, when the system ran out of disk space as a result
>>> of growing log files.
>>> > It was at that point we realised we had a serious problem.
>>> >
>>> > Prior to that the system load hadn't climbed to dangerous levels (>
>>> number of CPU cores) and Apache was keeping up with the traffic, so none of
>>> our other monitoring was tripped.
>>> >
>>> > If you have any thoughts on what sort of information you are thinking
>>> of that would be helpful.
>>>
>>> We could have plots of the amount of queries we get with a KNewStuff/*
>>> user-agent over time and their distribution.
>>>
>>> > It would definitely be helpful though to know when new software is
>>> going to be released that will be interacting with the servers as we will
>>> then be able to monitor for abnormalities.
>>>
>>> We make big announcements of every Plasma release... (?)
>>>
>>> >> Is there anything that could be done in this front? The issue here
>>> >> could have been addressed months ago, we just never knew it was
>>> >> happening.
>>> >
>>> >
>>> > One possibility that did occur to me today would be for us to
>>> integrate some kind of killswitch that our applications would check on
>>> first initialisation of functionality that talks to KDE.org servers.
>>> > This would allow us to disable the functionality in question on user
>>> systems.
>>> >
>>> > The check would only be done on first initialization to keep load low,
>>> while still ensuring all users eventually are affected by the killswitch
>>> (as they will eventually need to logout/reboot for some reason or another).
>>> >
>>> > The killswitch would probably work best if it had some kind of version
>>> check in it so we could specify which versions are disabled.
>>> > That would allow for subsequent updates - once delivered by
>>> distributions - to restore the functionality (while leaving it disabled for
>>> those who haven't updated).
>>>
>>> The file we are serving here effectively is the kill switch to all of
>>> KNewStuff.
>>>
>>> Aleix
>>>
>>

Re: Critical Denial of Service bugs in Discover

[Aleix Pol]

(dropping the distros list)

@sysadmin have you been able to look into any tools we devs can have to
make sure this situation doesn't repeat in the future?

Aleix

On Thu, Feb 10, 2022 at 1:10 PM Aleix Pol  wrote:

> On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley  wrote:
> >
> >
> >
> > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol  wrote:
> >>
> >> [Snip]
> >>
> >> We still haven't discussed here is how to prevent this problem from
> >> happening again.
> >>
> >> If we don't have information about what is happening, we cannot fix
> problems.
> >
> >
> > Part of the issue here is that the problem only came to Sysadmin
> attention very recently, when the system ran out of disk space as a result
> of growing log files.
> > It was at that point we realised we had a serious problem.
> >
> > Prior to that the system load hadn't climbed to dangerous levels (>
> number of CPU cores) and Apache was keeping up with the traffic, so none of
> our other monitoring was tripped.
> >
> > If you have any thoughts on what sort of information you are thinking of
> that would be helpful.
>
> We could have plots of the amount of queries we get with a KNewStuff/*
> user-agent over time and their distribution.
>
> > It would definitely be helpful though to know when new software is going
> to be released that will be interacting with the servers as we will then be
> able to monitor for abnormalities.
>
> We make big announcements of every Plasma release... (?)
>
> >> Is there anything that could be done in this front? The issue here
> >> could have been addressed months ago, we just never knew it was
> >> happening.
> >
> >
> > One possibility that did occur to me today would be for us to integrate
> some kind of killswitch that our applications would check on first
> initialisation of functionality that talks to KDE.org servers.
> > This would allow us to disable the functionality in question on user
> systems.
> >
> > The check would only be done on first initialization to keep load low,
> while still ensuring all users eventually are affected by the killswitch
> (as they will eventually need to logout/reboot for some reason or another).
> >
> > The killswitch would probably work best if it had some kind of version
> check in it so we could specify which versions are disabled.
> > That would allow for subsequent updates - once delivered by
> distributions - to restore the functionality (while leaving it disabled for
> those who haven't updated).
>
> The file we are serving here effectively is the kill switch to all of
> KNewStuff.
>
> Aleix
>

Re: Spring on 5-6 of March

[Aleix Pol]

+1 to the dates
+1 to the 5.25 kickoff to be within the sprint

Thanks!

On Mon, Feb 14, 2022 at 4:47 PM Jonathan Riddell  wrote:
>
> Should we have a 5.25 kickoff meeting? Should that be part of this sprint?  
> (It may be distracting if the point of the sprint is Plasma 6.)
>
> Jonathan
>
>
> On Mon, 14 Feb 2022 at 15:38, Marco Martin  wrote:
>>
>> also discussed during the meeting this seems the latest agreement for
>> the sprint.
>> is it ok for everybody? i would make this date final
>>
>> --
>> Marco Martin

Re: Plasma sprint doodle

[Aleix Pol]

We should wrap this as the dates are getting near.

Should we do March 5th and 6th?


On Mon, Jan 31, 2022 at 11:18 AM Marco Martin  wrote:
>
> Hi all,
> Here is a doodle with a bunch of dates to plan the sprint
> https://doodle.com/poll/nvdyzp979y8dvfyd?utm_source=poll_medium=link
> --
> Marco Martin
>
>

Re: plasma 5.24 tars ready for packaging

[Aleix Pol]

On Wed, Feb 9, 2022 at 11:05 AM Ben Cooksley  wrote:
>
> On Wed, Feb 9, 2022 at 4:30 AM Nate Graham  wrote:
>>
>> Much work is currently in progress to actually fix these issues. I see
>> multiple merge requests across multiple repos being reviewed and merged.
>> I think it makes sense to let that process happen. I see no indication
>> of the issue not being taken seriously, even considering the hyperbolic
>> and threatening way in which it was communicated mere days before a
>> major software release that is already occupying everyone's time. Let's
>> tone down the rhetoric and let developers do their jobs, now that
>> they've been made aware of this critical issue.
>
>
> Please note that it is extremely important that backports and the making of 
> releases containing those backports is a critical part of the process of 
> rectifying this issue.
> It cannot be left to just resolve itself via the organic process of users 
> updating their systems to major versions - because that won't happen for 
> months or longer and it is likely that the issue will continue to intensify 
> before it gets any better.
>
> Based on data we have we know that a big proportion of the traffic is coming 
> from KF 5.86 based systems so these patches need backporting as distributions 
> will not ship major version updates to these users.
> Patch releases however have a chance (especially if we prod packagers) of 
> making their way to those users within a matter of days.
>
> To date all mentions I have made of backports being essential have been 
> ignored.

I don't know why you are saying you have been ignored. Distributions
were notified yesterday and I know at least a portion of them are
working on it.

This problem has been ongoing for several weeks now. Mitigations are
in place, let's give ourselves the time to react.

I don't think that this general feeling of impending doom is making it
easier for anyone to address the problem.

Thank you for caring.
Aleix

Re: Critical Denial of Service bugs in Discover

[Aleix Pol]

On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley  wrote:
>
>
>
> On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol  wrote:
>>
>> [Snip]
>>
>> We still haven't discussed here is how to prevent this problem from
>> happening again.
>>
>> If we don't have information about what is happening, we cannot fix problems.
>
>
> Part of the issue here is that the problem only came to Sysadmin attention 
> very recently, when the system ran out of disk space as a result of growing 
> log files.
> It was at that point we realised we had a serious problem.
>
> Prior to that the system load hadn't climbed to dangerous levels (> number of 
> CPU cores) and Apache was keeping up with the traffic, so none of our other 
> monitoring was tripped.
>
> If you have any thoughts on what sort of information you are thinking of that 
> would be helpful.

We could have plots of the amount of queries we get with a KNewStuff/*
user-agent over time and their distribution.

> It would definitely be helpful though to know when new software is going to 
> be released that will be interacting with the servers as we will then be able 
> to monitor for abnormalities.

We make big announcements of every Plasma release... (?)

>> Is there anything that could be done in this front? The issue here
>> could have been addressed months ago, we just never knew it was
>> happening.
>
>
> One possibility that did occur to me today would be for us to integrate some 
> kind of killswitch that our applications would check on first initialisation 
> of functionality that talks to KDE.org servers.
> This would allow us to disable the functionality in question on user systems.
>
> The check would only be done on first initialization to keep load low, while 
> still ensuring all users eventually are affected by the killswitch (as they 
> will eventually need to logout/reboot for some reason or another).
>
> The killswitch would probably work best if it had some kind of version check 
> in it so we could specify which versions are disabled.
> That would allow for subsequent updates - once delivered by distributions - 
> to restore the functionality (while leaving it disabled for those who haven't 
> updated).

The file we are serving here effectively is the kill switch to all of KNewStuff.

Aleix

Re: Critical Denial of Service bugs in Discover

[Aleix Pol]

On Tue, Feb 8, 2022 at 7:00 PM Ben Cooksley  wrote:
>
> On Tue, Feb 8, 2022 at 4:24 AM Aleix Pol  wrote:
>>
>> On Sat, Feb 5, 2022 at 10:16 PM Ben Cooksley  wrote:
>> >
>> > Hi all,
>> >
>> > Over the past week or so Sysadmin has been dealing with an extremely high 
>> > volume of traffic directed towards both download.kde.org and 
>> > distribute.kde.org.
>> >
>> > This traffic volume is curious in so far that it is directed at two paths 
>> > specifically:
>> > - distribute.kde.org/khotnewstuff/fonts-providers.xml
>> > - download.kde.org/ocs/providers.xml
>> >
>> > The first path is an "internal only" host which we were redirecting a 
>> > legacy path to prior to the resource being relocated to cdn.kde.org. The 
>> > second path has been legacy for numerous years now (more than 5) and is 
>> > replaced by autoconfig.kde.org.
>> > It is of extreme concern that these paths are still in use - especially 
>> > the ocs/providers.xml one.
>> >
>> > The volume of traffic has reached an extent that to prevent the server 
>> > disk filling up we have had to disable logging for those two sites. Whilst 
>> > dependent on the time of day the server is currently dealing with the 
>> > current volume of requests, which is far outside normal specifications:
>> >
>> > 555 requests/sec - 4.5 MB/second - 8.3 kB/request - .739199 
>> > ms/request
>> >
>> > Analysis of a fragment of logs (comprising just a few minutes of traffic) 
>> > reveals the following:
>> >
>> >  63 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
>> > "KNewStuff/5.89.0-discoverupdate/5.23.5"
>> >  64 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
>> > "KNewStuff/5.89.0-discoverupdate/5.23.4"
>> > 104 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
>> > "KNewStuff/5.90.0-discoverupdate/5.23.90"
>> > 105 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
>> > "KNewStuff/5.88.0-discoverupdate/5.23.5"
>> >1169 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
>> > "KNewStuff/5.86.0-plasma-discover-update/"
>> >1256 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
>> > "KNewStuff/5.90.0-discoverupdate/5.23.5"
>> >2905 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "Mozilla/5.0"
>> >
>> >  86 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 200 6773 "-" 
>> > "Mozilla/5.0"
>> > 130 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "KNewStuff/5.89.0-discoverupdate/5.23.5"
>> > 136 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "KNewStuff/5.89.0-discoverupdate/5.23.4"
>> > 197 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "KNewStuff/5.88.0-discoverupdate/5.23.5"
>> > 199 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "KNewStuff/5.90.0-discoverupdate/5.23.90"
>> >2624 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "KNewStuff/5.86.0-plasma-discover-update/"
>> >2642 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "KNewStuff/5.90.0-discoverupdate/5.23.5"
>> >6117 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
>> > "Mozilla/5.0"
>> >
>> > This indicates that the bug lies solely within Plasma's Discover component 
>> > - more precisely it's updater.
>> >
>> > Examining the origin of these requests has indicated that some clients are 
>> > making requests to these paths well in excess of several times a minute 
>> > with a number of IP addresses appearing more 60 times in a 1 minute sized 
>> > sample window.
>> >
>> > Given that Sysadmin has raised issues with this component and it's 
>> > behaviour in the past, it appears that issues regarding the behaviour of 
>> > the OCS componentry within Discover remain unresolved.
>> >
>> > Due to the level of distress this is causing our systems, I am therefore 
>> > left with no other option other 

Re: plasma-phone-components release process

[Aleix Pol]

On Tue, Feb 8, 2022 at 3:21 PM Jonathan Riddell  wrote:
>
> plasma-phone-components is released as part of Plasma which has an 
> established release process that we review at the start of each cycle.  This 
> time it was renamed after the repo freeze and after the beta which causes 
> unpredictable problems in the packaging process.
>
> Should plasma-phone-components/plasma-mobile continue to be part of the 
> Plasma release? Or would it be better to move it to Plasma Mobile releases?

plasma-mobile is what plasma-phone-components used to be,
plasma-mobile should be released with plasma.

plasma-mobile (and previously plasma-phone-components) is tightly
coupled with certain changes in Plasma and they should go hand in
hand.

Aleix

Re: Critical Denial of Service bugs in Discover

[Aleix Pol]

On Sat, Feb 5, 2022 at 10:16 PM Ben Cooksley  wrote:
>
> Hi all,
>
> Over the past week or so Sysadmin has been dealing with an extremely high 
> volume of traffic directed towards both download.kde.org and 
> distribute.kde.org.
>
> This traffic volume is curious in so far that it is directed at two paths 
> specifically:
> - distribute.kde.org/khotnewstuff/fonts-providers.xml
> - download.kde.org/ocs/providers.xml
>
> The first path is an "internal only" host which we were redirecting a legacy 
> path to prior to the resource being relocated to cdn.kde.org. The second path 
> has been legacy for numerous years now (more than 5) and is replaced by 
> autoconfig.kde.org.
> It is of extreme concern that these paths are still in use - especially the 
> ocs/providers.xml one.
>
> The volume of traffic has reached an extent that to prevent the server disk 
> filling up we have had to disable logging for those two sites. Whilst 
> dependent on the time of day the server is currently dealing with the current 
> volume of requests, which is far outside normal specifications:
>
> 555 requests/sec - 4.5 MB/second - 8.3 kB/request - .739199 
> ms/request
>
> Analysis of a fragment of logs (comprising just a few minutes of traffic) 
> reveals the following:
>
>  63 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
> "KNewStuff/5.89.0-discoverupdate/5.23.5"
>  64 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
> "KNewStuff/5.89.0-discoverupdate/5.23.4"
> 104 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
> "KNewStuff/5.90.0-discoverupdate/5.23.90"
> 105 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
> "KNewStuff/5.88.0-discoverupdate/5.23.5"
>1169 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
> "KNewStuff/5.86.0-plasma-discover-update/"
>1256 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" 
> "KNewStuff/5.90.0-discoverupdate/5.23.5"
>2905 "GET /ocs/providers.xml HTTP/1.1" 301 6585 "-" "Mozilla/5.0"
>
>  86 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 200 6773 "-" 
> "Mozilla/5.0"
> 130 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "KNewStuff/5.89.0-discoverupdate/5.23.5"
> 136 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "KNewStuff/5.89.0-discoverupdate/5.23.4"
> 197 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "KNewStuff/5.88.0-discoverupdate/5.23.5"
> 199 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "KNewStuff/5.90.0-discoverupdate/5.23.90"
>2624 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "KNewStuff/5.86.0-plasma-discover-update/"
>2642 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "KNewStuff/5.90.0-discoverupdate/5.23.5"
>6117 "GET /khotnewstuff/fonts-providers.xml HTTP/1.1" 304 6132 "-" 
> "Mozilla/5.0"
>
> This indicates that the bug lies solely within Plasma's Discover component - 
> more precisely it's updater.
>
> Examining the origin of these requests has indicated that some clients are 
> making requests to these paths well in excess of several times a minute with 
> a number of IP addresses appearing more 60 times in a 1 minute sized sample 
> window.
>
> Given that Sysadmin has raised issues with this component and it's behaviour 
> in the past, it appears that issues regarding the behaviour of the OCS 
> componentry within Discover remain unresolved.
>
> Due to the level of distress this is causing our systems, I am therefore left 
> with no other option other than to direct the Plasma Discover developers to 
> create and release without delay patches for all versions in support, as well 
> as for all those currently present in any actively maintained distributions, 
> that disable all OCS functionality in the Discover updater. Distributions are 
> requested to treat these patches as security patches and to distribute them 
> to users without delay.
>
> In 24 hours time Sysadmin will be making a posting to kde-announce requesting 
> that users immediately cease use of the Discover update client as it is 
> creating a Denial of Service attack on our infrastructure.

I feel like your response here is out of proportion.

Last time we had this conversation, my impression was that the problem
was addressed for the most part. If you wanted people working on
KNewStuff, Attica or OCS to take any actions, we needed to at the very
least have information about you are complaining before you burst out
into mailing lists and the likes.

In terms of actual solutions this in would probably help to some
extent. We never merged it because it's not great design but good
results is more important than good design. At the moment they're in
their way in but it will take time until it hits users.
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/141/
https://invent.kde.org/plasma/discover/-/merge_requests/165/

These were of course not the only mitigation solutions put into place
back then. In fact many of them were geared towards 

Re: Monday meeting notes for 24/1/2022

[Aleix Pol]

Here's the ticket to gather topics for the Plasma sprint:
https://invent.kde.org/plasma/plasma-workspace/-/issues/32

On Mon, Jan 24, 2022 at 5:26 PM Marco Martin  wrote:
>
> Jonathan
> * beta is out, beta testing day is done
> * please fix bugs
> * is there any progress on answering the lts question?
> [discussion recap: lts now means we can't do the "last plasma release"
> for 2 years, which is a quite realistinc timeframe anyways, so
> decision is: let's do an lts-lite that can last less than 2 years]
> [Discussion  will continue on ML]
>
> Arjen
> * so I finally merged a set of patches that have been around for a
> while so we don't set default focus for a number of things if that
> would show a virtual keyboard
> * I also did a few small patches during the bug day last thursday to
> fix some "vhi regression" bugs
> * other than that, there was some discussion on the ml about doing a
> virtual sprint february or march, were there any more concrete plans
> there?
> [Discussion: needs doodle]
> [apol: I guess it could also make sense to discuss which topics we
> need to go through]
> [nico: I'd suggest that we collect topics on the ML in advance]
> [apol: maybe we can have an invent issue]
> [invent issue it is]
> [d_ed: one thing we need to do, potentially at a sprint, is tag things
> as "this is an interesting idea we could do" vs "this has to happen by
> 6.0"]
>
> Bhushan
> * So I've been trying to debug the weird plasma mobile issue where
> plasmashell fails to connect to kactivitymanagerd and then doesn't
> show anything.
> * Some people say it is happening after recent qtwayland update
> * But weirdly enough disabling systemd boot also makes it work
> * I'm continuing to debug it today
> [d_ed will look into it as it seems systemd-related]
>
> Nate
> * So I have been doing a lot of bug triaging for the Plasma 5.24 beta
> and we're in a pretty good shape.
> *We're down to only 6 issues in the "VHI regressions" list:
> https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED_status=CONFIRMED_status=ASSIGNED_status=REOPENED=regression%2C%20_type=allwords_name=VHI-priority%20Plasma%20regressions_id=1967106=VHI=Bluedevil=Breeze=Discover=drkonqi=frameworks-kirigami=frameworks-plasma=frameworks-qqc2-desktop-style=kactivitymanagerd=kde-gtk-config=kdeplasma-addons=khelpcenter=kinfocenter=klipper=kmenuedit=krunner=KScreen=kscreenlocker=ksmserver=ksysguard=KSystemLog=kwin=Plasma%20SDK=Plasma%20Vault=Plasma%20Workspace%20Wallpapers=plasma-integration=plasma-nm=plasma-pa=plasma-simplemenu=plasmashell=policykit-kde-agent-1=Powerdevil=print-manager=printer-applet=pulseaudio-qt=systemsettings=Touchpad-KCM=user-manager=xdg-desktop-portal-kde_based_on=VHI-priority%20Plasma%20regressions_format=advanced
>
> [d_ed will take 448475]
> [marco will take 370676]
>
>
> Aleix:
> * maybe most useful to comment is sddm. I'd encourage anyone who can
> to test the develop branch
> * we'd like to get a release out so we can work on simplifying some
> parts of the codebase and given how important a component it is, it
> would be useful
> * I'm aware there's some important pending PRs, we're trying to go
> through them but it's also a delicate beast in itself
> * testing these MRs on the different use-cases we might have would
> also make it easier for reviewers
> * other than that, I've been working on Discover and video recording
> on wayland, not much to comment on that though
>
>
> Kai Uwe
> Dolphin/KIO:
> Tab bar now accepts drop only ontop of a tab (denied cursor on blank 
> space)
> Fix for janky show/hide animation in KFilePlacesView, please
> review: https://invent.kde.org/frameworks/kio/-/merge_requests/725
> "Details" tab from Baloo-widgets is now only shown when it
> actually has some details (it doesn't fetch them for remote locations)
> Did some investigation as to why KFilePlacesView drop on place is
> broken (cf. last week's notes),
> Qt ignore()s the event and subsequently runs into the fallback
> of calling dropMimeData to add the place to the model
> 
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/itemviews/qlistview.cpp?h=5.15#n963
> No idea what the right fix would be here. Just not calling
> into the superclass in this case also wreaks all sorts of havoc to the
> view's internal state. And doing a check for that special case in
> KFilePlacesModel doesn't work as dropMimeData doesn't get the QEvent,
> just the QMimeData within. And adding a special mime type is also ugly
> because the QMimeData in the QEvent we get is const … whatever I try
> :-(
> Plasma:
> Fixed regression in Bluetooth applet breaking the big "Enable"
> button when it's off
> Other:
> Noticed a breakage in SDDM in neon, identical to
> https://bugs.kde.org/show_bug.cgi?id=441080 – no idea why and how
>
>
> Nico
> * Fixed task manager identification for some XWayland apps, e.g. Chrome 
> webapps
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1396
> * which requires 

Re: Plasma 6 Kickoff sprint

[Aleix Pol]

On Thu, Jan 13, 2022 at 11:13 PM Nicolas Fella  wrote:
>
> Hi,
>
> recently there was some discussion on Plasma 6 branching/timeline. At
> the KF6 meeting we figured it would help finding a timeline if we had
> some discussion on what kind of (architectural) changes we want to make.
>
> I know that Marco has some ideas in particular around plasma-framework
> and applets, and I'm sure others have other ideas worth discussing.
>
> Therefore I'd suggest we have a Plasma 6 Kickoff Sprint (pun intended)
> sometime soon. Date and everything to be discussed. Given _vaguely
> gestures at everything_ I don't see us doing a physical one though, sadly.
>
> Thoughts?

+1

Makes sense.

FWIW, I think we should meet again eventually. I agree that maybe
March is a bit rushed but I also wouldn't procrastinate much further.

Aleix

Re: 5.24 as LTS

[Aleix Pol]

On Wed, Dec 22, 2021 at 8:28 PM Jonathan Riddell  wrote:
>
> We've had a late request for 5.24 to be an LTS.
>
> We had previously said the final Plasma 5 release would be the one before 
> Plasma 6, but there's no immediate sign of a Plasma 6.
>
> What do devs think of making 5.24 an LTS?

There's no immediate sign but you must have seen our frameworks being
ported to Qt 6...

I'm not against it but I'd also want to make sure it won't be a big
problem to have concurrent LTS processes.

Aleix

Re: Can we move the Monday Plasma meeting to a later time?

[Aleix Pol]

On Mon, Dec 13, 2021 at 4:43 PM Nate Graham  wrote:
>
> Ping, any thoughts on this?
>
> Nate
>
>
> On 12/8/21 11:04, Nate Graham wrote:
> > Currently the Monday Plasma meeting is held at 3 or 4 AM for people in
> > the Americas, which is not a very convenient time for them to be able to
> > participate.
> >
> > Could we consider moving it to a few hours later?
> >
> > Nate

I think we are hitting a "people don't like mailing lists" issue here.
Maybe starting a doodle/framadate and getting people to vote on it
would work better.

+1 for me anyway, not that I really participated much on them :(

Aleix

Re: Proposal: Split oxygen sounds

[Aleix Pol]

Remember to tell packagers so they know about the new repository and
eventually the new tarball.

It would make sense to mark it as a runtime dependency to Breeze so
they can detect it too.

On Fri, Nov 26, 2021 at 1:12 PM Benjamin Port  wrote:
>
> Thanks for your reply Aleix,
>
> I suggest to do an oxygen-sounds repository that will install sounds to 
> /usr/share/sounds/oxygen/stereo/name_without_oxygen and add an oxygen.theme 
> file
> We can then create a breeze-sounds repository and as first step we can 
> inherit oxygen
> Create symlink to /usr/share/sounds/name_starting_with_Oxygen (like now)
>
> We will still need to implement the spec in knotification to support the spec
>
> Benjamin
>
> > On Thu, Nov 25, 2021 at 2:55 PM Benjamin Port  
> > wrote:
> > >
> > > Hello,
> > >
> > > Currently all plasma sounds came from oxygen, even if you use breeze 
> > > theme you still need to install oxygen package in order to have sound 
> > > notification for example.
> > >
> > > That's why I will suggest to split oxygen repository. Current oxygen 
> > > repository will keep everything except sounds. And a new one 
> > > oxygen-sounds will have them.
> > >
> > > This will allow to not depend on the whole oxygen theme anymore, and 
> > > allow more minimal setup
> > >
> > > My action Plan (if you are ok with the split):
> > > - Ask sysadmin to create the new repository
> > > - Do the split
> >
> > Not opposing, but:
> > - We need to be clear to coordinate with whoever takes on the task to
> > do the new sound theme:
> > https://community.kde.org/SoK/Ideas/2022#Plasma_Sound_Design
> > - Are you sure about oxygen-sounds? If we rely on it (at least for
> > now) from breeze it should be called something different like ocean or
> > whatever.
> >
> > Aleix
> >
>
>
>
>

Re: Proposal: Split oxygen sounds

[Aleix Pol]

On Thu, Nov 25, 2021 at 2:55 PM Benjamin Port  wrote:
>
> Hello,
>
> Currently all plasma sounds came from oxygen, even if you use breeze theme 
> you still need to install oxygen package in order to have sound notification 
> for example.
>
> That's why I will suggest to split oxygen repository. Current oxygen 
> repository will keep everything except sounds. And a new one oxygen-sounds 
> will have them.
>
> This will allow to not depend on the whole oxygen theme anymore, and allow 
> more minimal setup
>
> My action Plan (if you are ok with the split):
> - Ask sysadmin to create the new repository
> - Do the split

Not opposing, but:
- We need to be clear to coordinate with whoever takes on the task to
do the new sound theme:
https://community.kde.org/SoK/Ideas/2022#Plasma_Sound_Design
- Are you sure about oxygen-sounds? If we rely on it (at least for
now) from breeze it should be called something different like ocean or
whatever.

Aleix

Re: RFC: Using `-Wno-unused-parameter` in Plasma projects

[Aleix Pol]

I agree that the status quo isn't ideal. Q_UNUSED() adds too much
relevance to the argument that happens to be not needed.

I think that the best most usable way is your b) where you comment out
the arguments.
I think the warning should be kept. The problem with c) is that we
pollute the namespace with an identifier that we don't use and in the
end I know I've solved issues at times noticing this warning.

That's all very subjective though, so take this all prefixed with a
big fat IMHO.

Cheers!
Aleix

On Wed, Oct 27, 2021 at 7:42 PM Vlad Zahorodnii  wrote:
>
> Hi,
>
> The main issue with -Wunused-parameter is that it makes development more
> painful. For example, say that you have an observer class and you need
> to override a dozen of methods to handle various events, but you don't
> really care about arguments... In every method, you would need to add
> Q_UNUSED() just to shut the compiler up. Besides more work, it produces
> more (boilterplate) code. There are ways to make code compact, e.g.
>
>class ActivityObserver : public Observer
>{
>public:
>void pointerEvent(const QPoint , int timestamp) override
>{
>Q_UNUSED(pos)
>Q_UNUSED(timestamp)
>notifyActivity();
>}
>
>void buttonEvent(int button, ButtonState state, int timestamp)
> override
>{
>Q_UNUSED(pos)
>Q_UNUSED(state)
>Q_UNUSED(timestamp)
>notifyActivity();
>}
>};
>
> (a) omit parameter names
>
>class ActivityObserver : public Observer
>{
>public:
>void pointerEvent(const QPoint &, int) override
>{
>notifyActivity();
>}
>
>void buttonEvent(int, ButtonState, int) override
>{
>notifyActivity();
>}
>};
>
> The advantages:
>
> * more compact code
>
> The disadvantages:
>
> * code is less readable
> * in case you need to use some parameter, you would need to look it up
> in the base class, which is not convenient
> * adds more work: you would need to copy method prototype and remove
> each argname manually
>
> (b) comment out argnames
>
>class ActivityObserver : public Observer
>{
>public:
>void pointerEvent(const QPoint &/*pos*/, int /*timestamp*/) override
>{
>notifyActivity();
>}
>
>void buttonEvent(int /*button*/, ButtonState /*state*/, int
> /*timestamp*/) override
>{
>notifyActivity();
>}
>};
>
> The advantages:
>
> * compact code
> * more readable than just removing argnames
>
> The disadvantages:
>
> * adds more work: you would need to copy method prototype and comment
> out each argname manually
>
>
> (c) disable -Wunused-parameter
>
>class ActivityObserver : public Observer
>{
>public:
>void pointerEvent(const QPoint , int timestamp) override
>{
>notifyActivity();
>}
>
>void buttonEvent(int button, ButtonState state, int timestamp)
> override
>{
>notifyActivity();
>}
>};
>
> The advantages:
>
> * compact code
> * no need to manually remove or comment out argnames
>
> The disadvantages:
>
> * ?
>
> Besides adding more work and code, it's easy to forget to remove
> Q_UNUSED() once it actually becomes readable; it litters code with false
> information. Many compilers won't print a warning if an argument is used
> but it's marked as Q_UNUSED.
>
> One could argue that the main benefit of -Wunused-parameter is that it
> makes easy to spot when an argument becomes unused and thus it can be
> removed. But I doubt that it's ever been the case. Speaking from my
> personal experience, if I see an unused argument warning, my natural
> instinct is to add a Q_UNUSED() macro without analyzing every possible
> usage of that method or function.
>
> One could also argue that -Wunused-parameter may help to catch bugs
> caused by not using some parameter. Similar to the case above, the
> likelihood of that being true is slim. If an argument is unused, it's
> more likely that it will be marked as Q_UNUSED() without doing an in
> detail review.
>
> Note that this is not about -Wunused-variable. I believe that it's still
> very useful for the purpose of keeping code clean of unused variables.
>
> So my question is - would it be okay to disable -Wunused-parameter
> throughout all Plasma projects except maybe header-only libraries if
> there are any? If not, would it be acceptable to disable
> -Wunused-parameter per project instance?
>
> Cheers,
> Vlad

Re: Monday meeting notes for 25/10/2021

[Aleix Pol]

Should we organise a call or so about wacom tablets on wayland? What
was the discussion about?

On Mon, Oct 25, 2021 at 1:07 PM Marco Martin  wrote:
>
> [discussion about problems in wayland wrt wacom tablets, may need more
> discussion with hanyoung and tyson tan]
>
> David E
> * We're seeing the usual mass of bugs come in after a .0 release
> * so we need to be more on top of that
> * I approved a bunch of things wrt fingerprints
> * There's some good stuff from Devin
> * and I'll merge my kscreenlocker side
> * it's currently "blocked" on letting someone merge their patch for
> custom prompts
> * and then I'll land the fingerprint stuff on top
>
> [David Redondo  We broke plasmashell dbus api. d_ed I saw the mrs]
>
> Nicofe
> * One big-ish thing is implementing fdo color preference support in our portal
> https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/49
> * Fixed a relevant KCM bug
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1123
> * I also added API to use it from an app:
> https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/27
> * On the PlaMo side I finally merged the ModemManager port of Spacebar
> And started working on fixing all the things
> Something that came out of that is
> https://invent.kde.org/frameworks/modemmanager-qt/-/merge_requests/7
>
> Carl
> * Fix pushDialogLayers
> https://invent.kde.org/frameworks/kirigami/-/merge_requests/405
> (merged) and ported Kalendar's OverlaySheets, Koko's share dialog and
> Neochat settings to it
> * Ported Qrca and the health certificate part of Itinerary to
> Kirigami.NavigationTabBar:
> https://invent.kde.org/plasma-mobile/qrca/-/merge_requests/45 (merged)
> and https://invent.kde.org/pim/itinerary/-/merge_requests/53 (merged)
> * Fix some issues with the new Sonnet QtQuick feature:
> https://invent.kde.org/frameworks/sonnet/-/merge_requests/33 (merged)
> * Kirigami doc improvements:
> https://invent.kde.org/frameworks/kirigami/-/merge_requests/406
> (merged), https://invent.kde.org/frameworks/kirigami/-/merge_requests/407
> * KCM doc improvements:
> https://invent.kde.org/documentation/develop-kde-org/-/merge_requests/151
> (merged)
>
> Arjen
> * I've been doing some work on touch support for plasma
> * I did a few MRs to set Qt.ImhNoPredictiveText on text fields that
> are used as search fields, without it the virtual keyboard will only
> cause the textEdited/textChanged signals to be fired on enter, which
> means things like krunner don't work properly with virtual keyboard
> * I wrote a kirigami MR to detect whether an input method/virtual
> keyboard is active
> https://invent.kde.org/frameworks/kirigami/-/merge_requests/398
> * but it's a bit stuck as the kwin api basically is insufficient
> * that said, the only property Qt.inputMethod has that is the same is
> the "visible" property
> * it doesn't have any information about whether an input method is
> enabled or what kind of input method is being used
> * the end goal of this was to prevent system settings from focusing
> the search field on startup when started with touch and a virtual
> keyboard is active
> * and be able to do the same in other places
> * last thing I'm working on is porting the plasma widget explorer away
> from DragArea so that it becomes easier to change the behaviour
> between mouse and touch
> * I have a draft mr
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/630
> * it works great with mouse
> * but touch only works sporadically
> * so far we figured out that drags are started properly, but then kwin
> doesn't seem to properly update the drags on touch motion
> [d_ed i can believe it's an untested area]
>
> Kai Uwe
> * not much from my side
> * just that p-b-i got kicked out of Mozilla store last Monday
> * fvogt did a fix and d_ed will upload it … thanks for that!
>
> Marco
> i started to port some of the code of the plasma6 prototype wrt applet
> loading i did to plasma5, as at akademy we talked about the
> possibility to have the api we liked more in plasma5alsready, so some
> plamoid could be ported in any moment..
>
>
> --
> Marco Martin

Re: KDE CI: Plasma » plasma-framework » kf5-qt5 FreeBSDQt5.15 - Build # 644 - Still Failing!

[Aleix Pol]

Does anyone know why we are having this problem all of a sudden? I cannot
reproduce on my system.
Plasma Workspace is failing the same:
https://build.kde.org/job/Plasma/job/plasma-workspace/job/kf5-qt5%20SUSEQt5.15/1800/

Aleix

On Mon, Oct 18, 2021 at 1:18 PM CI System  wrote:

> *BUILD FAILURE*
> Build URL
> https://build.kde.org/job/Plasma/job/plasma-framework/job/kf5-qt5%20FreeBSDQt5.15/644/
> Project: kf5-qt5 FreeBSDQt5.15
> Date of build: Mon, 18 Oct 2021 11:15:42 +
> Build duration: 2 min 2 sec and counting
> * CONSOLE OUTPUT *
> [...truncated 914 lines...]
> [2021-10-18T11:17:43.057Z] :162:1: note: expanded from here
> [2021-10-18T11:17:43.057Z] KSERVICE_DEPRECATED_VERSION_5
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z]
> /usr/home/jenkins/install-prefix/include/KF5/KService/kservice_export.h:380:57:
> note: expanded from macro 'KSERVICE_DEPRECATED_VERSION_5'
> [2021-10-18T11:17:43.057Z] #define KSERVICE_DEPRECATED_VERSION_5(minor,
> text) KSERVICE_DEPRECATED_VERSION_5_##minor(text)
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z] :163:1: note: expanded from here
> [2021-10-18T11:17:43.057Z] KSERVICE_DEPRECATED_VERSION_5_87
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z]
> /usr/home/jenkins/install-prefix/include/KF5/KService/kservice_export.h:376:50:
> note: expanded from macro 'KSERVICE_DEPRECATED_VERSION_5_87'
> [2021-10-18T11:17:43.057Z] # define KSERVICE_DEPRECATED_VERSION_5_87(text)
> KSERVICE_DECL_DEPRECATED_TEXT(text)
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.057Z]
> /usr/home/jenkins/install-prefix/include/KF5/KService/kservice_export.h:220:61:
> note: expanded from macro 'KSERVICE_DECL_DEPRECATED_TEXT'
> [2021-10-18T11:17:43.057Z] #define KSERVICE_DECL_DEPRECATED_TEXT(text)
> __attribute__ ((__deprecated__(text)))
> [2021-10-18T11:17:43.057Z] ^
> [2021-10-18T11:17:43.622Z] [ 68%] Linking CXX shared library
> ../../../bin/libplatformcomponentsplugin.so
> [2021-10-18T11:17:43.622Z] [ 68%] Building CXX object
> src/plasma/CMakeFiles/KF5Plasma.dir/dataengineconsumer.cpp.o
> [2021-10-18T11:17:43.622Z] [ 68%] Built target platformcomponentsplugin
> [2021-10-18T11:17:43.622Z] [ 68%] Building CXX object
> src/plasma/CMakeFiles/KF5Plasma.dir/service.cpp.o
> [2021-10-18T11:17:43.890Z]
> /usr/home/jenkins/workspace/Plasma/plasma-framework/kf5-qt5
> FreeBSDQt5.15/src/plasma/private/applet_p.cpp:184:105: error: no viable
> conversion from 'QStringList' to 'const QString'
> [2021-10-18T11:17:43.890Z] const QStringList provides =
> q->pluginMetaData().value(QStringLiteral("X-Plasma-Provides"),
> QStringList());
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:265:5:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'QChar' for 1st argument
> [2021-10-18T11:17:43.890Z] QString(QChar c);
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:273:12:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'QString &&' for 1st argument
> [2021-10-18T11:17:43.890Z] inline QString(QString && other) noexcept :
> d(other.d) { other.d = Data::sharedNull(); }
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:967:29:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'QStringDataPtr' for 1st argument
> [2021-10-18T11:17:43.890Z] Q_DECL_CONSTEXPR inline QString(QStringDataPtr
> dd) : d(dd.ptr) {}
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:973:5:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'const char *' for 1st argument
> [2021-10-18T11:17:43.890Z] QString(const char *ch);
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:974:5:
> note: candidate constructor not viable: no known conversion from
> 'QStringList' to 'const QByteArray &' for 1st argument
> [2021-10-18T11:17:43.890Z] QString(const QByteArray );
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z]
> /usr/local/include/qt5/QtCore/qstring.h:1067:17: note: candidate
> constructor not viable: no known conversion from 'QStringList' to
> 'QLatin1String' for 1st argument
> [2021-10-18T11:17:43.890Z] inline QString::QString(QLatin1String aLatin1)
> : d(fromLatin1_helper(aLatin1.latin1(), aLatin1.size()))
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z]
> /usr/local/include/qt5/QtCore/qstring.h:1093:17: note: candidate
> constructor not viable: no known conversion from 'QStringList' to 'const
> QString &' for 1st argument
> [2021-10-18T11:17:43.890Z] inline QString::QString(const QString )
> noexcept : d(other.d)
> [2021-10-18T11:17:43.890Z] ^
> [2021-10-18T11:17:43.890Z] /usr/local/include/qt5/QtCore/qstring.h:264:14:
> note: explicit constructor is not a candidate
> 

Re: Project Submission

[Aleix Pol]

Hi Farkas,
Integration is never a problem. QML is also written in C++. In fact, if
something is not possible to do with QML we generally just add it. On the
other hand it's harder to get C++ components to integrate visually without
QML/QtQuick as we use the components transparently.

Most of what you see in Plasma is QML, so if you aspire to integrate with
it, I also would recommend using the same technology. I'm not entirely sure
about what you mean with the different cases you see could be contentious
but I'm sure we'd find a way to integrate them.

You can for example look at the application dashboard plasmoid
(kickerdash), I'm sure it will help you understand how it works and
probably open the possibility to sharing code.
https://invent.kde.org/plasma/plasma-desktop/-/tree/master/applets/kicker/package/contents/ui

Aleix

On Tue, Sep 21, 2021 at 8:46 PM Farkas Máté  wrote:

> Hi Nate,
>
> Thank you for your interest. Following our brief exchange on Reddit where
> I initially announced the project, I have indeed considered rewriting
> things in QML. There are three reasons I stuck with C++ however, but I
> might have been naîve. First, in the long run I would like to allow the
> user to add plasmoids to the dashboard, eliminating the overall need for
> classical menus (as they are the only way to access the power buttons).
> With other words, I think it might be an interesting feature if the user
> could create a menu similar to those on iOS and Android devices containing
> both icons and widgets.
>
> Second, I have heard (from an unreliable source) that touchpad gestures
> are coming to Plasma. From the user's perspective, I believe it would be a
> nice touch to Rocket, if it had an appearance/disappearance animation
> synced to a pre-defined gesture (similar to what Launchpad in MacOS has). I
> am not an expert, but I thought the implementation of these features above
> would be easier in C++. Third, I also played with the idea of using KRunner
> as a backend, which is purely written in C++ as far as I know.
>
> Lastly (this does not really count as a reason), I wanted to accomplish
> something usable in a reasonable timeframe in order to play around with the
> idea a bit, and to see whether there would be any interest at all. Since
> QML still looks weird and annoyingly nonlinear to me (I initially took a
> look at Kickoff's code, and I could barely follow what was going on), I
> stayed with C++, which I am more familiar with; apart from that, I had the
> impression, that some functions in the Plasma libraries are C++-exclusive.
>
> Would you still propose going for QML given in this situation?
>
> Regards,
> Mate
>
> Le mar. 21 sept. 2021 à 18:01, Nate Graham  a écrit :
>
>> Hello Farkas,
>>
>> Have you considered making this a Plasma widget using QML? Plasma has an
>> existing infrastructure for installing, deleting, adding, and removing
>> widgets, and allowing users to see alternatives. Since this is basically
>> an alternative launcher, it would make sense for it to appear in the
>> "Alternatives" popup that shows existing installed alternative widgets.
>> We already have a full screen launcher widget ("Application Dastboard"),
>> so it's conceptually possible to do something like what you've done in
>> QML. However that widget is fairly old and un-loved, and would be a good
>> candidate for being overhauled or replaced with your launcher, if it
>> used the common technical infrastructure for widgets.
>>
>> Nate
>>
>>
>> On 9/16/21 16:09, Farkas Máté wrote:
>> > Dear KDE Team,
>> >
>> > hereby I would like to submit a project I have been working on in the
>> > last months with the aim of incubating it within the KDE project, as I
>> > believe it could contribute to the user experience on touch-capable
>> > devices (such as Microsoft Surface-like hybrid laptops, tablet users,
>> > Wacom-tablet users, etc.).
>> >
>> > It is an application launcher aiming for ease of use on the above
>> > mentioned devices. I believe Kicker is a simple and powerful launcher,
>> > but it still uses a classical old-style approach (i.e.
>> > menu-submenu-sub-submenu-navigation) to help the user to find the app
>> > he/she wants to launch. Using a pen or an equivalent device, this
>> > procedure (with misclicks and spending time looking for the right
>> > category, subcategory, etc.) could unnecessarily worsen the user
>> > experience, which motivated me to implement a launcher similar to those
>> > seen on smart devices and other modern desktop operating systems.
>> >
>> > The launcher (which I have named Rocket) places the user's applications
>> > in a grid and allows him/her to categorize them by making folders. It
>> > supports searching, so opening the launcher with a shortcut and typing
>> > the desired program's name into the already focused search field
>> already
>> > yields results to keep a fluent workflow for keyboard-oriented
>> > power-users too. It aims to be customizable and uses the KF5 framework
>> > 

Re: Project Submission

[Aleix Pol]

Hi Farkas,
Looking good! Including the Plasma mailing list as it seems mostly
related to the shell.
Also I'd suggest you talk to the KDE Visual Design Group, they may be
interested in working with you on it.

Cheers!
Aleix

On Fri, Sep 17, 2021 at 11:18 AM Farkas Máté  wrote:
>
> Dear KDE Team,
>
> hereby I would like to submit a project I have been working on in the last 
> months with the aim of incubating it within the KDE project, as I believe it 
> could contribute to the user experience on touch-capable devices (such as 
> Microsoft Surface-like hybrid laptops, tablet users, Wacom-tablet users, 
> etc.).
>
> It is an application launcher aiming for ease of use on the above mentioned 
> devices. I believe Kicker is a simple and powerful launcher, but it still 
> uses a classical old-style approach (i.e. 
> menu-submenu-sub-submenu-navigation) to help the user to find the app he/she 
> wants to launch. Using a pen or an equivalent device, this procedure (with 
> misclicks and spending time looking for the right category, subcategory, 
> etc.) could unnecessarily worsen the user experience, which motivated me to 
> implement a launcher similar to those seen on smart devices and other modern 
> desktop operating systems.
>
> The launcher (which I have named Rocket) places the user's applications in a 
> grid and allows him/her to categorize them by making folders. It supports 
> searching, so opening the launcher with a shortcut and typing the desired 
> program's name into the already focused search field already yields results 
> to keep a fluent workflow for keyboard-oriented power-users too. It aims to 
> be customizable and uses the KF5 framework to communicate with the 
> environment.
>
> Having reached an inflection point in the project (where all the features I 
> need have already been implemented with some bugs and inconsistencies still 
> being present), I am asking you whether you have any interest in 
> incorporating it in Plasma. If you have, I would be more than happy to 
> continue the development while focusing on the needs of other users and 
> improving on the codebase; if not, I would continue only improving things for 
> myself only. In case of interest, I am also ready to comply with the 
> standards required by the community.
>
> Things which need care include improving the customizability options, fixing 
> some graphical glitches, improving support for multi-touch input (including 
> double-finger trackpad scrolling which I – due to my hardware restrictions – 
> did not manage to implement as flawlessly as desired) and some "complex usage 
> cases" (i.e. cases where the user does a lot of things while dragging and 
> dropping an application icon). I would like to emphasize that none of these 
> things are of the kind which heavily restrict everyday use, but they still 
> force the user to make some compromises (and thus make Rocket less 
> "market-ready"); it is thus beyond the prototype/designing phase. I am also 
> sending you a video regarding the current state of development attached. 
> Regarding the future of the project, I have been thinking about adding 
> support for plasmoids (such that the user is allowed to add widgets to the 
> menu) and to allow the user to use KRunner as a backend search tool.
>
> Some months ago I posted a small video on a more primitive version of Rocket 
> in the official KDE Reddit-channel [1], which was also well-received (despite 
> not having as many customization options and not being able to create folders 
> yet). Also, the KDE store provides some less-powerful alternatives with a 
> non-negligible user base [2]. I also believe you have to know that I am not a 
> professional developer, which can be easily seen by looking into the code 
> [3]. With some help from fellow developers however, I think I can quickly 
> improve on my programming skills (which I am also happy to do).
>
> If you have any further questions, please do not hesitate to ask me. You can 
> reach me in English, German, French or in Hungarian, if the people in charge 
> or the community prefer it differently.
>
> Thank you for your consideration,
> Yours faithfully,
> Mate Farkas
>
> -
> [1]: 
> https://www.reddit.com/r/kde/comments/mq408q/i_have_developed_an_application_launcher_for_kde/
> [2]: https://store.kde.org/p/1364064/
> [3]: https://github.com/friciwolf/Rocket
> Please make sure to create the folder ~/.config/rocket if you compile the 
> code yourself (using qmake and make or Qt Designer), as this folder is 
> necessary for Rocket to launch – another small thing to be fixed for the 
> general audience. Also, please turn on the blurring effect in the system 
> settings for it to take effect (an option using the system wallpaper as 
> background is also possible, albeit yet only by recompiling the code 
> manually).

Re: Setting Look and Feels

[Aleix Pol]

On Wed, Sep 1, 2021 at 10:02 PM Tom Zander  wrote:
>
> On dinsdag 31 augustus 2021 18:45:00 CEST Nate Graham wrote:
> > Any more
> > that it would make sense to show a desktop global theme on
> > PlaMo.
>
> On dinsdag 31 augustus 2021 18:53:54 CEST Aleix Pol wrote:
> > Maybe, but then you wouldn't have it installed I guess?
>
>
> What about the usecase of a phone being connected to a full size
> screen and mouse. IIRC the pinephone has that option. I'm not
> talking about simply a screen-duplicate, but a useful, 19/6 res.
>
> For that case you want the themes installed on most phones and
> maybe you want to use that theme only on your main screen.
>
>

https://invent.kde.org/teams/plasma-mobile/issues/-/issues/54

I'd say in this case it's about adopting a different Look and Feel
entirely. As discussed in the ticket above we can:
- see to having mixed shell packages, which we currently do not
support but could eventually be a thing
- just swap the look and feel entirely for another one, which is kind
of what I'm after right now

Aleix

Re: plasma-wayland-protocols, kwayland, kwayland-server, and kwin have to recompiled

[Aleix Pol]

On Wed, Sep 1, 2021 at 10:28 AM Ben Cooksley  wrote:
>
> On Wed, Sep 1, 2021 at 9:56 AM David Edmundson  
> wrote:
>>
>> Bumping this thread to say, this (a bump of plasma-wayland-protocols)
>> has just happened again and I imagine we have two more landing this
>> week.
>>
>> This probably will result in broken CI for a few days, which is far
>> from ideal, but it's why we have our feature freeze early.
>
>
> I find the acceptance here of things being "broken" concerning, especially in 
> something that is a dependency of a Framework.
> As plasma-wayland-protocols is a dependency of KWayland (a Framework) any 
> issues with it have far greater implications than just Plasma.
>
> Breakages in Frameworks cannot be accepted for several days.

There's a bit of a misunderstanding here. Nothing should break as long
as we make sure we build against the correct version of
plasma-wayland-protocols (which is always master). We just need to
coordinate the CI builds.

Aleix

Re: Setting Look and Feels

[Aleix Pol]

On Tue, Aug 31, 2021 at 6:27 PM Aleix Pol  wrote:
>
> Hi all,
> I was looking at why we're not getting the phone shell listed along
> our different look and feels, I realised it's because the plasma phone
> shell doesn't have any defaults at the moment. You'll think "What? No
> specific phone settings?".
> This is because we have a separate repository that installs those in
> system-wide.
> https://invent.kde.org/plasma-mobile/plasma-phone-settings
>
> Most of these settings (especially those in /etc/xdg/) would be
> possible to specify as defaults.
> https://invent.kde.org/plasma/plasma-phone-components/-/merge_requests/183
>
> A problem to do that straight out is that at the moment we're
> specifying each setting separately rather than taking them at bulk,
> trusting the lnf.
> https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/lookandfeel/kcm.cpp#L354
>
> This works, provided we enable the different settings that we need,
> like this, doing it for every single configuration option could be
> tedious and error-prone:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1029
>
> Now, is this something that we would like to entertain? I'd say it's a
> good way to configure a system to use a certain Plasma experience (be
> it Plasma Phone, Big Screen, etc). On the other hand, it also might
> dilute the current use of the look and feel kcm which is more about
> Look and less about Feel.
>
> What do you think?
> Aleix

Since it seems to me we are aligned towards making it work, I've
polished a bit the MRs to that end. I think it would make sense to
just pick all the defaults rather than cherry-picking through them,
this is something we can do for the next release though.

I'd appreciate any help towards moving what's in
https://invent.kde.org/plasma-mobile/plasma-phone-settings/-/tree/master/etc/xdg
to the Look and Feel package.
I imagine something similar will be needed for Big Screen, maybe
someone could take a look as well. Is there a plasma-phone-settings
counterpart?

Aleix

Re: plasma-wayland-protocols, kwayland, kwayland-server, and kwin have to recompiled

[Aleix Pol]

In preparation I did run the dependency build for frameworks and
plasma. I did forget to run it for Plasma stable which is probably
what you saw.

Leaving some time between submitting the protocols patch, letting the
dependency build jobs finish (successfully :D) and then merging the
actual implementations makes for a much easier integration.
I'll be happy to press the right buttons if someone tells me they'd
merged to the protocols repository.

Aleix

On Tue, Aug 31, 2021 at 11:56 PM David Edmundson
 wrote:
>
> Bumping this thread to say, this (a bump of plasma-wayland-protocols)
> has just happened again and I imagine we have two more landing this
> week.
>
> This probably will result in broken CI for a few days, which is far
> from ideal, but it's why we have our feature freeze early.
>
> David

Re: Setting Look and Feels

[Aleix Pol]

On Tue, Aug 31, 2021 at 6:45 PM Nate Graham  wrote:
>
> On 8/31/21 10:41 AM, Aleix Pol wrote:
> > This is what the KCM looks like with my plasma-phone-components patch 
> > applied:
> > https://i.imgur.com/JtJ2VZ3.png
> >
> > I suggest polishing it with that use-case then see if we need to work
> > on it in an entirely different way over the 5.23 timespan.
> >
> > Aleix
>
> I would want to filter global themes by form factor, at least. There's
> no point in showing a PlaMo global theme on desktop, right? Any more
> that it would make sense to show a desktop global theme on PlaMo.
>
> Nate

Maybe, but then you wouldn't have it installed I guess?

I can see how one might want to set bigscreen on a desktop computer or
plasma phone on a tablet.

Aleix

Re: Setting Look and Feels

[Aleix Pol]

This is what the KCM looks like with my plasma-phone-components patch applied:
https://i.imgur.com/JtJ2VZ3.png

I suggest polishing it with that use-case then see if we need to work
on it in an entirely different way over the 5.23 timespan.

Aleix

On Tue, Aug 31, 2021 at 6:33 PM Nate Graham  wrote:
>
> There have been persistent calls--both in the VDG as well as by users--
> for the Global Theme/LNF system to become better at the "feel" side, as
> you put it (I like that!). I've still got
> https://phabricator.kde.org/D24223 open, which was about the feel side
> of the equation, and I still don't think it would be a bad idea to do.
>
> If we don't want to make Global Themes too much about the "feel" side,
> then I think we need to create a new "Desktop Layout" KCM that's all
> about the feels. Then we could put this sort of thing you're thinking of
> in there--as well as what I was proposing in
> https://phabricator.kde.org/D24223.
>
> Nate
>
>
> On 8/31/21 10:27 AM, Aleix Pol wrote:
> > Hi all,
> > I was looking at why we're not getting the phone shell listed along
> > our different look and feels, I realised it's because the plasma phone
> > shell doesn't have any defaults at the moment. You'll think "What? No
> > specific phone settings?".
> > This is because we have a separate repository that installs those in
> > system-wide.
> > https://invent.kde.org/plasma-mobile/plasma-phone-settings
> >
> > Most of these settings (especially those in /etc/xdg/) would be
> > possible to specify as defaults.
> > https://invent.kde.org/plasma/plasma-phone-components/-/merge_requests/183
> >
> > A problem to do that straight out is that at the moment we're
> > specifying each setting separately rather than taking them at bulk,
> > trusting the lnf.
> > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/lookandfeel/kcm.cpp#L354
> >
> > This works, provided we enable the different settings that we need,
> > like this, doing it for every single configuration option could be
> > tedious and error-prone:
> > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1029
> >
> > Now, is this something that we would like to entertain? I'd say it's a
> > good way to configure a system to use a certain Plasma experience (be
> > it Plasma Phone, Big Screen, etc). On the other hand, it also might
> > dilute the current use of the look and feel kcm which is more about
> > Look and less about Feel.
> >
> > What do you think?
> > Aleix
> >

Setting Look and Feels

[Aleix Pol]

Hi all,
I was looking at why we're not getting the phone shell listed along
our different look and feels, I realised it's because the plasma phone
shell doesn't have any defaults at the moment. You'll think "What? No
specific phone settings?".
This is because we have a separate repository that installs those in
system-wide.
https://invent.kde.org/plasma-mobile/plasma-phone-settings

Most of these settings (especially those in /etc/xdg/) would be
possible to specify as defaults.
https://invent.kde.org/plasma/plasma-phone-components/-/merge_requests/183

A problem to do that straight out is that at the moment we're
specifying each setting separately rather than taking them at bulk,
trusting the lnf.
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/lookandfeel/kcm.cpp#L354

This works, provided we enable the different settings that we need,
like this, doing it for every single configuration option could be
tedious and error-prone:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1029

Now, is this something that we would like to entertain? I'd say it's a
good way to configure a system to use a certain Plasma experience (be
it Plasma Phone, Big Screen, etc). On the other hand, it also might
dilute the current use of the look and feel kcm which is more about
Look and less about Feel.

What do you think?
Aleix

Today's call

[Aleix Pol]

Where? https://meet.kde.org/b/ale-wjk-tts
When? 2pm UTC

Suggested agenda:

* Calendaring systems
* Involved people could not make it, we'll need to re-schedule
* Modem stability and future
* Update on last week's discussion, steps forward
* Ticket dive?

Re: Maliit Keyboard and Plasma

[Aleix Pol]

I sent an e-mail to kde-distro-packag...@kde.org. Hopefully they'll
pick up on that. :)

Thanks Jonathan!


Aleix

On Thu, Jun 24, 2021 at 9:43 PM Jonathan Riddell  wrote:
>
> Great thanks.
>
> Someone should tell the distros to ship it then, unless I missed that.
>
> Jonathan
>
>
> On Thu, 24 Jun 2021 at 20:21, Nicolas Fella  wrote:
>>
>> Hi,
>>
>> On 24/06/2021 20:17, Jonathan Riddell wrote:
>> > It's unclear to me if Plasma expects or needs Maliit to be installed.
>>
>> Technically speaking it does not expect Maliit, any keyboard
>> implementing the required Wayland protocol will do. Maliit happens to be
>> the one we tend to test and it's what we ship on Plasma Mobile, so it
>> would be my default recommendation.
>>
>> >
>> > It's discussed here that "The built-in keyboard was dropped in 5.20 in
>> > favor of external virtual keyboards."
>> > https://bugs.kde.org/show_bug.cgi?id=427972
>> > 
>> >
>> > And of course users on tablet style machines
>> >
>> > So should we have maliit installed by default?
>>
>> Yes
>>
>> >   Should this be added as a cmake runtime check somewhere?
>>
>> That's a bit harder to answer since technically any compliant keyboard
>> will do
>>
>> >   Should distros be told?  It doesn't seem to be a lot of distros
>> > looking at repology
>> > https://repology.org/project/maliit-keyboard/versions
>> > 
>>
>> yes.
>>
>>  > Is this page obsolete now we have the kwin virtual keyboard
>> kcm?https://invent.kde.org/plasma/kwin/-/wikis/Virtual-Keyboard
>> 
>>
>> The information is still accurate, it's how the KCM works under the
>> hood. It's just not as relevant any more as it used to be.
>>
>> >
>> > Jonathan
>> >
>> Cheers
>>
>> Nico
>>

Maliit as Plasma's on-screen keyboard

[Aleix Pol]

Dear distros,
It's been pointed out to me that we never formally explained our
relationship with Maliit Keyboard and some are not packaging it yet.

Some time ago we switched our Plasma Wayland from using a built-in Qt
VirtualKeyboard instance to use the standard input_method_v1 protocol.
For this we have been mostly testing using the Maliit Keyboard.

https://github.com/maliit/keyboard/

We (Plasma) would recommend making it available to your users if you
support touch screen devices based on Wayland. Having it available by
default would be a nice touch.

To my knowledge, this has been used for a while now by Plasma Mobile
and it should be possible to have it packaged easily.

Thanks!
Aleix

Re: Maliit Keyboard and Plasma

[Aleix Pol]

On Thu, Jun 24, 2021 at 8:17 PM Jonathan Riddell  wrote:
>
> It's unclear to me if Plasma expects or needs Maliit to be installed.
>
> It's discussed here that "The built-in keyboard was dropped in 5.20 in favor 
> of external virtual keyboards."
> https://bugs.kde.org/show_bug.cgi?id=427972
>
> And of course users on tablet style machines
>
> So should we have maliit installed by default?  Should this be added as a 
> cmake runtime check somewhere?  Should distros be told?  It doesn't seem to 
> be a lot of distros looking at repology
> https://repology.org/project/maliit-keyboard/versions
>
> Jonathan
>

As of this merge request, maliit wasn't even installable from Discover
since it wasn't providing appstream information. It's available now
(or it will be when they release).
https://github.com/maliit/keyboard/pull/46

That said, shipping it by default would be nice.

Aleix

Re: Monday meeting notes for 14/06/2021

[Aleix Pol]

On Mon, Jun 14, 2021 at 7:02 PM David Redondo  wrote:
>
> Am Montag, 14. Juni 2021, 15:43:52 CEST schrieb Nate Graham:
> > KGlobaAccel seems somewhat fragile; I feel like every time anyone
> > touches anything about it, stuff breaks. Is it possible to improve unit
> > test coverage for it?
>
> I don't think more testing of KGlobalAccel would solve the problem.
> The problem is that not all of the behavior is clear from the API,
> and contains some gotchas, see the linked MRs. So KGlobalAccel itself as the
> shortcut daemon works, but the client side API has room for improvement.

We can have KGlobalAccel test against the daemon, no?

Aleix

Re: Akademy Plasma Bof

[Aleix Pol]

On Mon, Jun 7, 2021 at 10:43 AM Marco Martin  wrote:
>
> Hi all,
> Do we want a plasma bof at akademy?
> often we do a full day one, which may or may not be useful,
> depending on what topic we do have.
> Personally i would like to make one about plasma 6
> Any day/time preference? other topics?

We sure should have BoFs, I'd prefer if we have different topics per
slot to see whether I must be in a session or not, since it's
inevitable that we get parallel sessions.

A "State of Plasma on Wayland" session could be useful as well.

On last week's Plasma Mobile meeting we also discussed having a
"Creating Plasma Mobile apps" BoF as well. We can also include that as
Plasma. ;)

As for time, I'm planning to be around for Akademy, so it's a matter
of not colliding, but for me let's just pick a sensible time and hope
for the best.

Cheers!
Aleix

Re: About some old and hard to maintain effects

[Aleix Pol]

On Mon, May 31, 2021 at 10:54 AM Vlad Zahorodnii
 wrote:
>
> Hi,
>
> Currently, we redesign scene abstractions in kwin [1].
> https://blog.vladzahorodnii.com/2021/04/12/scene-items-in-kwin/ outlines
> the end goal and provides an explanation why the scene abstractions need
> to be reworked. But just to summarize:
>
> * kwin renders wayland surfaces differently depending on their role.
> Furthermore, it makes assumptions about what types of client buffers can
> be attached to surfaces based on their role. That is absolutely wrong!
> For example, if a video game renders the pointer cursor using graphics
> api such as Vulkan or OpenGL, kwin won't be able to display that cursor
> * with the current scene abstractions, it's very difficult to render
> wayland surfaces other than that used to represent window contents, for
> example additional drag-and-drop icons. For what it's worth, dnd icons
> are implemented with some hacks atm, which break on mobile devices :(
> * more complex animations such as cross-fade animations can't be easily
> implemented with the current scene api. Similar to dnd icons, cross-fade
> animations are implemented as a hack, which doesn't work well
> * with the desired scene design, the rendering logic will be separate
> from scene items, i.e. scene items are used only to describe the
> contents of the screen. It should make it easier adding support for
> Vulkan; we could go one step further and perform compositing on threads,
> which should result in more stable frame rates on multi-monitor setups
> on wayland
>
> Unfortunately, some of kwin's rendering abstractions are exposed in
> libkwineffects (a library that's used to make effects). That means it's
> nearly impossible to make major architectural advancements without
> breaking effects in one or another way.
>
> Over the course of the past weeks, we've been working on a replacement
> for some of the apis in libkwineffects to allow us hide some rendering
> logic and porting effects to the new apis. However, there are still a
> few problematic effects. These effects are **massive** code-wise and not
> many people fully understand how they work. Another issue with them is
> that they use QTimeLine not the way it's designed. Essentially, those
> effects have to be re-written from scratch. On the other hand, based on
> support information from various bug reports, it doesn't look like those
> effects are used widely. So, given that disadvantages of keeping those
> hard to maintain effects outweigh the advantages and limited man power
> of the kwin development team, we'd like to remove them.
>
> I believe that all the effort that could have been spent on rewriting
> the problematic effects can be redirected on more important tasks in the
> scene redesign goal and improving QtQuick integration in KWin.
>
> The effects that we would like to drop are
>
> * coverswitch
> * cube
> * cubeslide
> * flipswitch
>
> On a related note, we plan to have a BoF session at this year's Akademy
> [2] about declarative effects api. Please join us if you have thoughts
> on this matter. :)
>
> Regards,
> Vlad
>
> [1] https://invent.kde.org/plasma/kwin/-/issues/30
> [2] https://akademy.kde.org/2021

Do you think these effects could be implemented using other
non-deprecated abstractions?

I'd say it's fine to remove them for now but I'd make sure that we are
not cornering ourselves.

Aleix

Re: Plasma Mobile weekly meetings

[Aleix Pol]

On Wed, May 26, 2021 at 4:01 PM Aleix Pol  wrote:
>
> Hi,
> Since recent developments it seems like it would make sense to come up
> with a way to stay in touch and sync on a regular basis.
> https://invent.kde.org/groups/plasma-mobile/-/issues
>
> Treat this as a weekly thing so we can trust that the meeting is going
> to happen regularly rather than next week specifically.
>
> For these meetings, I'd suggest using BBB, maybe this room:
> https://meet.kde.org/b/ale-wjk-tts

Okay then, let's have the meeting next Friday 4th June at 3pm CEST
(1pm UTC). I would try to keep it under 1h.
https://meet.kde.org/b/ale-wjk-tts

Topics to discuss:
- Akademy presence, necessary BoFs
- Plan for the next meetings, ensure it's sustainable to keep having them
- Going over the issues, hopefully with certain priority:
https://invent.kde.org/groups/plasma-mobile/-/issues

Feel free to bring up more topics either now or in situ.

Cheers!
Aleix

Plasma Mobile weekly meetings

[Aleix Pol]

Hi,
Since recent developments it seems like it would make sense to come up
with a way to stay in touch and sync on a regular basis.
https://doodle.com/poll/rid3hhh5yub6eyns

Treat this as a weekly thing so we can trust that the meeting is going
to happen regularly rather than next week specifically.

For these meetings, I'd suggest using BBB, maybe this room:
https://meet.kde.org/b/ale-wjk-tts

Cheers!
Aleix

Re: Can we remove or quiet down the commit bot in the chatrooms

[Aleix Pol]

On Wed, May 19, 2021 at 8:38 PM Nate Graham  wrote:
>
> I find it rather difficult to use #plasma for chats and discussions
> because of the near-constant spam from the commit announcement bot.
>
> It's not that it's useless to have commits announced, but when it
> happens in a room where humans are interacting, it's rather disruptive
> and spammy. Maybe we could move the bot into a dedicated commit announce
> room so that the people who care about this can still see the
> announcements there?
>
> Alternatively could we change the bot so that it sends one message for
> each commit instead of like 4 or 5?

I'd say we can probably remove it entirely?

Aleix

Re: Re-purposing KWaylandServer

[Aleix Pol]

On Wed, Apr 28, 2021 at 10:27 AM Vlad Zahorodnii
 wrote:
>
> On 3/23/21 6:27 PM, Aleix Pol wrote:
> > I don't feel like there's a use-case for it.
> >
> > I also don't have the feeling that having 2 separate repositories help
> > with anything. Moving code from one side to another is cumbersome and
> > makes history tracking more complex.
> >
> > I think it would be even cool if we didn't have kwayland-server
> > altogether. From my perspective, its only reason to be is
> > kscreenlocker which needs some classes from it:
> > KWayland::Server::Display and KWayland::Server::ClientConnection.
>
> That's a fair argument. My main gripe with the current architecture is
> that the split between kwayland-server and kwin makes it more difficult
> to implement some protocols.
>
> For example, client buffers can't be implemented entirely inside
> kwayland-server because at some point we need to ask the renderer to
> provide us a texture or additional info about the buffer. At the moment,
> we work around that by adding EGLDisplay info to the Display so we can
> call eglQueryWaylandBuffer in BufferInterface or taking an additional
> Impl object as in LinuxDmabufUnstableV1Interface.
>
> I think that the wayland machinery and the rest of the compositor
> (backends, renderer, etc) need to live in the same repo, either
> kwayland-server or kwin.
>
> I do agree that things will be better off without a separate repo for
> wayland wrappers. I guess if the need for a library to write compositors
> arises, we can just refactor libkwin and make it more general purpose.
>
> My question is: why does kscreenlocker need KWayland::Server::Display?
> Can we port it to QLocalServer/QLocalSocket?

When I moved KWayland Server I took the kscreenlocker dependency for
granted, it's something I didn't question. I can't say I understand
why it needs to have a wayland server there.

+1 for unifying them and refactoring all within a product. It must
stay properly separate but it would allow us to organise the
components in ways that make sense beyond the frameworks splitting
much like you are finding right now.

Aleix

Re: Plasma5Support

[Aleix Pol]

Hi Marco,
I'm not sure I fully understand what the plan is there. Why are you
calling it plasma5support? Is it so it can be deprecated?

The second link with the port got lost in the way somehow (you added
the same URL twice). It might help understand what you have in mind.

Including the dependency of the split out code should be fine indeed.
On the other hand, the old DataEngine classes will need to stay to
maintain ABI so maybe the DataEngine classes can also just stay as
they are (?).

I know, it's a bit messy... :/

Aleix

On Mon, Apr 26, 2021 at 12:44 PM Marco Martin  wrote:
>
> Hi all,
>
> I've been working on splitting dataengines out of libplamsa, as a new library
> called plasma5supoport https://invent.kde.org/mart/plasma5support
> (if we want to throw away other pieces non dataengine we can throw away them
> there too)
>
> It fully works (and a port of the dataengines in plasma-workspace is here
> https://invent.kde.org/mart/plasma5support)
>
> It's still not perfect, as is not totally a drop in replacement yet, which may
> or may not be acceptable: you gave to port also the qml part of plasmoids
> using it by importing the plasma5support qml plugin and replacing all the uses
> of PlasmaCore.DataSource, DataModel and so on.
>
> IT would be fine for out plasmoids, but any 3rd party plasmoid from the store
> using dataengines would be broken once we ship ported plasma-workspace
> dataengines.
>
> I still think it's worth starting this port in plasma5 times in order to have
> the least amount of work to be done in the strict qt6 porting phase.
>
> the only solution i can think of though is including the standalone dataengine
> library in plasma-framework itself, so porting plasmacore.DataSource etc to
> use the new library internally, shich would be a pretty transparent migration
> (that could potentially break 3rd party plasmoids using 3rd-party dataengines,
> but do 3rd party dataengines exist anymore? unlikely..)
>
> --
> Marco Martin

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: Re-purposing KWaylandServer

[Aleix Pol]

On Tue, Mar 23, 2021 at 9:44 AM Vlad Zahorodnii  wrote:
>
> Hi,
>
> Currently, KWaylandServer library is a collection of convenience Qt
> wrappers around Wayland protocols. The issue with such a design is that
> the bulk of work needs to be still done in the compositor, for example
> it still needs to deal with importing client buffers, setting up the
> session, handling of input and drm devices, launching xwayland, etc.
>
> I believe that a better design will involve offloading all non-kwin
> features from kwin to kwaylandserver:
>
> * kwin code base will be leaner. All window management features will be
> in kwin, while low level specific bits will be well contained in
> kwaylandserver
>
> * it's a more reusable design in general; this allows writing domain
> specific wayland compositors easier, for example for tv, mobile, etc
>
> * the implementation of some wayland protocols will become a bit more
> straightforward. At the moment, due to odd split of functionality
> between kwin and kwaylandserver, it's not clear what the best way to
> implement some protocols or features is, e.g. presentation feedback,
> linux dma-buf, popup grabs, etc
>
> * it's a safer design choice in long term. Currently, things go quite
> well in kwin, but just in case something goes wrong and we decide to
> start a new Wayland compositor, we won't have to write low level
> components such as the DRM backend, input device handling, and so on
> from scratch.

I don't feel like there's a use-case for it.

I also don't have the feeling that having 2 separate repositories help
with anything. Moving code from one side to another is cumbersome and
makes history tracking more complex.

I think it would be even cool if we didn't have kwayland-server
altogether. From my perspective, its only reason to be is
kscreenlocker which needs some classes from it:
KWayland::Server::Display and KWayland::Server::ClientConnection.

That's it.
And as it is, I just realised that it was never ported to kwayland-server...

Aleix

Re: KDE CI: Plasma » plasma-phone-components » kf5-qt5 SUSEQt5.15 - Build # 209 - Failure!

[Aleix Pol]

I imagine it needs to see the new kwin? Do we need to trigger something?

On Thu, Mar 4, 2021 at 4:56 PM CI System  wrote:

> *BUILD FAILURE*
> Build URL
> https://build.kde.org/job/Plasma/job/plasma-phone-components/job/kf5-qt5%20SUSEQt5.15/209/
> Project: kf5-qt5 SUSEQt5.15
> Date of build: Thu, 04 Mar 2021 15:55:22 +
> Build duration: 45 sec and counting
> * CONSOLE OUTPUT *
> [...truncated 572 lines...]
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-RootPath"
> with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-MainScript"
> with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-ContainmentType" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-DropMimeTypes" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-DropUrlPatterns" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-NotificationArea" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-NotificationAreaCategory" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-DBusActivationService" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-KDE-ParentApp"
> with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-Provides"
> with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-PreloadWeight" with type "int"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-ConfigPlugins" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-StandAloneApp" with type "bool"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-RequiredExtensions" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition "NoDisplay" with type
> "bool"
> [2021-03-04T15:56:02.293Z] About to parse service type file
> "/home/jenkins/install-prefix/share/kservicetypes5/plasma-containment.desktop"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-ContainmentType" with type "QString"
> [2021-03-04T15:56:02.293Z] Unknown property type for key "Keywords" ->
> falling back to string
> [2021-03-04T15:56:02.293Z] Generated
> "/home/jenkins/workspace/Plasma/plasma-phone-components/kf5-qt5
> SUSEQt5.15/build/containments/taskpanel/org.kde.phone.taskpanel-plasmoids-metadata.json"
> [2021-03-04T15:56:02.293Z] About to parse service type file
> "/home/jenkins/install-prefix/share/kservicetypes5/plasma-applet.desktop"
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-API" with
> type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-RootPath"
> with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-MainScript"
> with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-ContainmentType" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-DropMimeTypes" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-DropUrlPatterns" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-NotificationArea" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-NotificationAreaCategory" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-DBusActivationService" with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-KDE-ParentApp"
> with type "QString"
> [2021-03-04T15:56:02.293Z] Found property definition "X-Plasma-Provides"
> with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-PreloadWeight" with type "int"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-ConfigPlugins" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-StandAloneApp" with type "bool"
> [2021-03-04T15:56:02.293Z] Found property definition
> "X-Plasma-RequiredExtensions" with type "QStringList"
> [2021-03-04T15:56:02.293Z] Found property definition "NoDisplay" with type
> "bool"
> [2021-03-04T15:56:02.294Z] About to parse service type file
> "/home/jenkins/install-prefix/share/kservicetypes5/plasma-containment.desktop"
> [2021-03-04T15:56:02.294Z] Found property definition
> "X-Plasma-ContainmentType" with type "QString"
> [2021-03-04T15:56:02.294Z] Unknown property type for key "Keywords" ->
> falling back to string
> [2021-03-04T15:56:02.294Z] Generated
> "/home/jenkins/workspace/Plasma/plasma-phone-components/kf5-qt5
> SUSEQt5.15/build/containments/taskpanel/metadata.json"
> [2021-03-04T15:56:02.294Z] [ 43%] Automatic MOC for target
> plasma_containment_phone_taskpanel
> [2021-03-04T15:56:02.294Z] [ 43%] Built target
> org.kde.phone.taskpanel-plasmoids-metadata-json
> [2021-03-04T15:56:02.555Z] [ 

Re: KDE CI: Plasma » kwin » kf5-qt5 SUSEQt5.15 - Build # 826 - Still Failing!

[Aleix Pol]

On Tue, Mar 2, 2021 at 1:41 PM Vlad Zahorodnii  wrote:
>
> On 3/2/21 2:23 PM, Aleix Pol wrote:
> > I saw. My patch was removing it though and it didn't fail on my
> > system. Maybe it's a different behaviour between gcc and clang. I
> > could try that...
>
> Another option is to try to remove #include "keyboard_input.h" in
> wayland_server.h somehow. As far as I can tell, it's included because of
> WaylandServer::updateKeyState(KWin::Xkb::LEDS leds).

Yes, right. But I'd still be playing pingpong with the CI as I cannot
reproduce locally.

Aleix

Re: KDE CI: Plasma » kwin » kf5-qt5 SUSEQt5.15 - Build # 826 - Still Failing!

[Aleix Pol]

I saw. My patch was removing it though and it didn't fail on my
system. Maybe it's a different behaviour between gcc and clang. I
could try that...

On Tue, Mar 2, 2021 at 8:40 AM Vlad Zahorodnii  wrote:
>
> On 3/2/21 3:15 AM, Aleix Pol wrote:
> > Just reverted my own commit.
> > https://invent.kde.org/plasma/kwin/commit/b409f523f01cad45c9b1f4068ffc9fcf9a72399b
> > <https://invent.kde.org/plasma/kwin/commit/b409f523f01cad45c9b1f4068ffc9fcf9a72399b>
> >
> > I cannot reproduce locally and we better keep a working build I guess.
>
> SceneOpenGLBackend target is not linked against libkwin target, which in
> its turn is linked against the XKB imported target, which means that
> interface include directories from XKB::XKB are not propagated.
>
> Currently, the compilation doesn't fail because the top level CMakeLists
> file has include_directories(${XKB_INCLUDE_DIR}).
>
> HTH,
> Vlad
>
> > On Tue, Mar 2, 2021 at 1:44 AM CI System  > <mailto:nore...@kde.org>> wrote:
> >
> >   *BUILD FAILURE*
> > Build URL
> > https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.15/826/
> > 
> > <https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.15/826/>
> > Project:  kf5-qt5 SUSEQt5.15
> > Date of build:Tue, 02 Mar 2021 00:43:18 +
> > Build duration:   1 min 7 sec and counting
> >
> >
> > *CONSOLE OUTPUT *
> > [...truncated 1403 lines...]
> > [2021-03-02T00:44:16.696Z] | ~~~^
> > [2021-03-02T00:44:16.696Z] [ 10%] Built target kwin_killer_helper
> > [2021-03-02T00:44:16.696Z] [ 10%] Generating rulesettings.h,
> > rulesettings.cpp
> > [2021-03-02T00:44:16.952Z] [ 10%] Generating rulebooksettingsbase.h,
> > rulebooksettingsbase.cpp
> > [2021-03-02T00:44:16.952Z] [ 10%] Linking CXX shared library
> > ../../bin/libkwinxrenderutils.so
> > [2021-03-02T00:44:17.212Z] Scanning dependencies of target
> > KWinRulesObjects
> > [2021-03-02T00:44:17.212Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwinrules/CMakeFiles/KWinRulesObjects.dir/KWinRulesObjects_autogen/mocs_compilation.cpp.o
> > [2021-03-02T00:44:17.212Z] [ 10%] Linking CXX shared library
> > ../../bin/libkwinglutils.so
> > [2021-03-02T00:44:17.469Z] [ 10%] Built target kwinxrenderutils
> > [2021-03-02T00:44:17.469Z] [ 10%] Generating ui_module.h
> > [2021-03-02T00:44:17.469Z] Scanning dependencies of target
> > kcm_kwin_scripts
> > [2021-03-02T00:44:17.470Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwindecoration/CMakeFiles/kwin-applywindowdecoration.dir/decorationmodel.cpp.o
> > [2021-03-02T00:44:17.470Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwinscripts/CMakeFiles/kcm_kwin_scripts.dir/kcm_kwin_scripts_autogen/mocs_compilation.cpp.o
> > [2021-03-02T00:44:17.725Z] [ 10%] Linking CXX shared module
> > ../../../bin/kwin_showpaint_config.so
> > [2021-03-02T00:44:17.725Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwincompositing/CMakeFiles/kwincompositing.dir/kwincompositingdata.cpp.o
> > [2021-03-02T00:44:17.725Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwincompositing/CMakeFiles/kwincompositing.dir/kwincompositing_setting.cpp.o
> > [2021-03-02T00:44:17.981Z] [ 10%] Built target kwinglutils
> > [2021-03-02T00:44:17.981Z] Scanning dependencies of target
> > SceneQPainterBackend
> > [2021-03-02T00:44:18.237Z] [ 10%] Building CXX object
> > 
> > src/platformsupport/scenes/qpainter/CMakeFiles/SceneQPainterBackend.dir/SceneQPainterBackend_autogen/mocs_compilation.cpp.o
> > [2021-03-02T00:44:18.237Z] [ 10%] Built target kwin_showpaint_config
> > [2021-03-02T00:44:18.237Z] [ 10%] Building CXX object
> > 
> > src/platformsupport/scenes/qpainter/CMakeFiles/SceneQPainterBackend.dir/qpainterbackend.cpp.o
> > [2021-03-02T00:44:18.237Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwincompositing/CMakeFiles/kwincompositing.dir/kwin_compositing_interface.cpp.o
> > [2021-03-02T00:44:18.502Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwindecoration/CMakeFiles/kwin-applywindowdecoration.dir/utils.cpp.o
> > [2021-03-02T00:44:19.063Z] [ 10%] Linking CXX shared module
> > ../../bin/kcm_kwin4_genericscripted.so
> > [2021-03-02T00:44:19.629Z] [ 10%] Building CXX object
> > 
> > src/kcmkwin/kwindecoration/CMakeFiles/kwin-applywindowdecoration.dir/kwindecorationsettings.cpp.o
> > [2021-03-02T

Re: KDE CI: Plasma » kwin » kf5-qt5 SUSEQt5.15 - Build # 826 - Still Failing!

[Aleix Pol]

Just reverted my own commit.
https://invent.kde.org/plasma/kwin/commit/b409f523f01cad45c9b1f4068ffc9fcf9a72399b

I cannot reproduce locally and we better keep a working build I guess.

On Tue, Mar 2, 2021 at 1:44 AM CI System  wrote:

> *BUILD FAILURE*
> Build URL
> https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.15/826/
> Project: kf5-qt5 SUSEQt5.15
> Date of build: Tue, 02 Mar 2021 00:43:18 +
> Build duration: 1 min 7 sec and counting
> * CONSOLE OUTPUT *
> [...truncated 1403 lines...]
> [2021-03-02T00:44:16.696Z] | ~~~^
> [2021-03-02T00:44:16.696Z] [ 10%] Built target kwin_killer_helper
> [2021-03-02T00:44:16.696Z] [ 10%] Generating rulesettings.h,
> rulesettings.cpp
> [2021-03-02T00:44:16.952Z] [ 10%] Generating rulebooksettingsbase.h,
> rulebooksettingsbase.cpp
> [2021-03-02T00:44:16.952Z] [ 10%] Linking CXX shared library
> ../../bin/libkwinxrenderutils.so
> [2021-03-02T00:44:17.212Z] Scanning dependencies of target KWinRulesObjects
> [2021-03-02T00:44:17.212Z] [ 10%] Building CXX object
> src/kcmkwin/kwinrules/CMakeFiles/KWinRulesObjects.dir/KWinRulesObjects_autogen/mocs_compilation.cpp.o
> [2021-03-02T00:44:17.212Z] [ 10%] Linking CXX shared library
> ../../bin/libkwinglutils.so
> [2021-03-02T00:44:17.469Z] [ 10%] Built target kwinxrenderutils
> [2021-03-02T00:44:17.469Z] [ 10%] Generating ui_module.h
> [2021-03-02T00:44:17.469Z] Scanning dependencies of target kcm_kwin_scripts
> [2021-03-02T00:44:17.470Z] [ 10%] Building CXX object
> src/kcmkwin/kwindecoration/CMakeFiles/kwin-applywindowdecoration.dir/decorationmodel.cpp.o
> [2021-03-02T00:44:17.470Z] [ 10%] Building CXX object
> src/kcmkwin/kwinscripts/CMakeFiles/kcm_kwin_scripts.dir/kcm_kwin_scripts_autogen/mocs_compilation.cpp.o
> [2021-03-02T00:44:17.725Z] [ 10%] Linking CXX shared module
> ../../../bin/kwin_showpaint_config.so
> [2021-03-02T00:44:17.725Z] [ 10%] Building CXX object
> src/kcmkwin/kwincompositing/CMakeFiles/kwincompositing.dir/kwincompositingdata.cpp.o
> [2021-03-02T00:44:17.725Z] [ 10%] Building CXX object
> src/kcmkwin/kwincompositing/CMakeFiles/kwincompositing.dir/kwincompositing_setting.cpp.o
> [2021-03-02T00:44:17.981Z] [ 10%] Built target kwinglutils
> [2021-03-02T00:44:17.981Z] Scanning dependencies of target
> SceneQPainterBackend
> [2021-03-02T00:44:18.237Z] [ 10%] Building CXX object
> src/platformsupport/scenes/qpainter/CMakeFiles/SceneQPainterBackend.dir/SceneQPainterBackend_autogen/mocs_compilation.cpp.o
> [2021-03-02T00:44:18.237Z] [ 10%] Built target kwin_showpaint_config
> [2021-03-02T00:44:18.237Z] [ 10%] Building CXX object
> src/platformsupport/scenes/qpainter/CMakeFiles/SceneQPainterBackend.dir/qpainterbackend.cpp.o
> [2021-03-02T00:44:18.237Z] [ 10%] Building CXX object
> src/kcmkwin/kwincompositing/CMakeFiles/kwincompositing.dir/kwin_compositing_interface.cpp.o
> [2021-03-02T00:44:18.502Z] [ 10%] Building CXX object
> src/kcmkwin/kwindecoration/CMakeFiles/kwin-applywindowdecoration.dir/utils.cpp.o
> [2021-03-02T00:44:19.063Z] [ 10%] Linking CXX shared module
> ../../bin/kcm_kwin4_genericscripted.so
> [2021-03-02T00:44:19.629Z] [ 10%] Building CXX object
> src/kcmkwin/kwindecoration/CMakeFiles/kwin-applywindowdecoration.dir/kwindecorationsettings.cpp.o
> [2021-03-02T00:44:19.629Z] [ 10%] Building CXX object
> src/platformsupport/scenes/qpainter/CMakeFiles/SceneQPainterBackend.dir/logging.cpp.o
> [2021-03-02T00:44:19.629Z] [ 10%] Building CXX object
> src/kcmkwin/kwinscripts/CMakeFiles/kcm_kwin_scripts.dir/main.cpp.o
> [2021-03-02T00:44:19.629Z] [ 10%] Built target kcm_kwin4_genericscripted
> [2021-03-02T00:44:19.886Z] Scanning dependencies of target
> SceneOpenGLBackend
> [2021-03-02T00:44:19.886Z] [ 10%] Building CXX object
> src/platformsupport/scenes/opengl/CMakeFiles/SceneOpenGLBackend.dir/SceneOpenGLBackend_autogen/mocs_compilation.cpp.o
> [2021-03-02T00:44:19.886Z] Scanning dependencies of target VsyncSupport
> [2021-03-02T00:44:19.886Z] [ 10%] Building CXX object
> src/platformsupport/vsyncconvenience/CMakeFiles/VsyncSupport.dir/VsyncSupport_autogen/mocs_compilation.cpp.o
> [2021-03-02T00:44:19.886Z] [ 10%] Building CXX object
> src/kcmkwin/kwindecoration/declarative-plugin/CMakeFiles/kdecorationprivatedeclarative.dir/previewbutton.cpp.o
> [2021-03-02T00:44:20.144Z] [ 10%] Building CXX object
> src/kcmkwin/kwindecoration/declarative-plugin/CMakeFiles/kdecorationprivatedeclarative.dir/previewbridge.cpp.o
> [2021-03-02T00:44:20.144Z] [ 11%] Building CXX object
> src/kcmkwin/kwindecoration/CMakeFiles/kcm_kwindecoration.dir/declarative-plugin/buttonsmodel.cpp.o
> [2021-03-02T00:44:20.401Z] [ 11%] Building CXX object
> src/kcmkwin/kwindecoration/CMakeFiles/kcm_kwindecoration.dir/decorationmodel.cpp.o
> [2021-03-02T00:44:20.715Z] [ 11%] Building CXX object
> src/kcmkwin/kwindecoration/CMakeFiles/kcm_kwindecoration.dir/kcm.cpp.o
> [2021-03-02T00:44:20.715Z] [ 11%] Linking CXX static library
> ../../../../lib/libSceneQPainterBackend.a
> [2021-03-02T00:44:20.971Z] 

Re: releaseme license clarifications

[Aleix Pol]

El dc., 24 de febr. 2021, 13:29, Harald Sitter  va escriure:

> Yo!
>
> If you are in the CC list please respond whether you are ok with the
> licenses or not.
>
> I'm in the process of moving releaseme to reuse compliance and need
> y'all to approve the following clarifications on the plasma extensions
> inside releaseme.
>
> They are all following the general guidelines we have for licensing
> That is: all random data and configs are CC0-1.0. All programs/scripts
> are our GPL triplet.
>
> The plan would also relicense 4 files: plasma-changelog,
> plasma-update-versions, plasma-update-versions-kf5 and
> plasma-xenon-download.
> All of these are presently marked public domain but since that isn't a
> license and altogether unclear vis a vis legal meaning in a global
> context I propose they be relicensed to the GPL triplet instead.
>
> List of files with proposed license and applicable authors, as per git:
>
> .gitignore
> CC0-1.0
> Jonathan, Harald
>
> README.md
> CC0-1.0
> Jonathan, Thomas, Harald
>
> lib/releaseme/data/release_help.txt.erb
> CC0-1.0
> Aleix, Harald
>
> lib/releaseme/data/ticket_description.txt.erb
> CC0-1.0
> Jonathan, Harald
>
> plasma/Gemfile
> CC0-1.0
> Jonathan
>
> plasma/README
> CC0-1.0
> Jonathan, David, Harald
>
> plasma/VERSIONS-lts.inc
> CC0-1.0
> Jonathan, David, Carl
>
> plasma/VERSIONS-normal.inc
> CC0-1.0
> Jonathan, Harald, Bhushan, Carl
>
> plasma/create_log.py
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Albert, Jonathan, David, Bhushan, Carl
>
> plasma/create_sources_inc
> CC0-1.0
> Jonathan, Harald
>
> plasma/git-repositories-for-release
> CC0-1.0
> Jonathan, David, Bhushan
>
> plasma/git-repositories-for-release-lts
> CC0-1.0
> Jonathan, David
>
> plasma/git-repositories-for-release-normal
> CC0-1.0
> Jonathan, David
>
> plasma/lib/plasma-tag-test.rb
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/plasma-branch
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/plasma-changelog
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Bhushan, Harald
>
> plasma/plasma-dot-story
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, David
>
> plasma/plasma-release
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Carl, Bhushan
>
> plasma/plasma-branch-webpages
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/plasma-tag
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/plasma-tag-test
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/plasma-tars
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Harald
>
> plasma/plasma-update-1-tar
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/plasma-update-versions
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Harald, Bhushan
>
> plasma/plasma-update-versions-kf5
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Harald, Bhushan
>
> plasma/plasma-xenon-download
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> plasma/templates/plasma-changelog.md
> CC0-1.0
> Carl
>
> plasma/templates/plasma_announce_template.md.erb
> CC0-1.0
> Carl, Jonathan
>
> plasma/templates/plasma_info_template.md.erb
> CC0-1.0
> Carl, Jonathan
>
> plasma/update-web-svn
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Carl
>
> projects/kdeedu-data.yml
> CC0-1.0
> Jonathan
>
> projects/plasma-mediacenter.yml
> CC0-1.0
> Jonathan
>
> projects/plasma.yml
> CC0-1.0
> Jonathan
>
> test/plasma-tag-test-test.rb
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan
>
> test/translationunit_test.rb
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Harald
>
> test/plasma-webpages_test.rb
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Jonathan, Harald, Bhushan, Carl
>
> plasma/plasma-webpages
> GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
> Harald, Jonathan, Carl
>

>
I am fine with this.

Aleix

Using your Qt layer shell code

[Aleix Pol]

Hi Drew,
Hope all's going well on your end.

We're looking into using layer shell to integrate some components in
Plasma. To do it, we started using your code and we need a licence for
it. Would you be able to +1 LGPLv3 (which I see you approve in
SourceHut)?
https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20

Thank you very much!

Cheers!
Aleix

Re: Consistent CMake requirements in Plasma

[Aleix Pol]

On Tue, Feb 9, 2021 at 7:32 PM Nicolas Fella  wrote:
>
> Hi,
>
> while I was doing some cmake cleanup in Plasma I noticed that our stated
> minimum cmake versions are both somewhat inconsistent and super old.
> Most Plasma projects state that either 2.8 (released in 2009) or 3.0
> (released in 2014) are the minimum. That's obviously unrealistic.
>
> Newer cmake versions offer some nice stuff such as imported targets for
> common libs (e.g. used in
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336). For
> the sake of consistency I propose that we standardize Plasma on
> something recent-ish.
>
> My candidate for this would be cmake 3.16. It's the version shipped by
> Ubuntu 20.04 and thus Neon. This would exclude Debian stable which ships
> 3.13 (which does not have the feature relevant for
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336).

+1

Debian stable ships 5.11 (yay stability!!!) so it's sadly not like
anyone will develop Plasma 5.22 there :/.

Aleix

Re: Is it time to fork qtwaylandscanner?

[Aleix Pol]

On Wed, Jan 6, 2021 at 12:26 PM David Edmundson
 wrote:
>
> I no longer have my initial objections. Especially as it is only a few
> hundred lines.
> We can solve the global_remove problem too.
>
> For now I would say let's build it inside kwayland-server as a purely
> internal tool and not install the binary. It makes life easier.

While I agree that it makes sense to do so, I find it unlikely that
we'll go the next few months without a release of Qt 5.15.

Much like your change got stuck there, I'm sure many others did too
including the bugfixes to come. I don't think qtwaylandscanner is
special in this regard.

Aleix

Re: Synchronized release schedule for Plasma

[Aleix Pol]

On Thu, Nov 26, 2020 at 10:38 PM Neal Gompa  wrote:
>
> On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol  wrote:
> >
> > On Tue, Nov 24, 2020 at 5:10 PM David Edmundson 
> >  wrote:
> >>>
> >>> As distribution package maintainers, we would like Plasma developers to 
> >>> slightly alter the release schedule to align releases with a more 
> >>> distribution friendly cycle. You could consider shortening one release 
> >>> cycle (and then keep the 6 month schedule) to align releases.
> >>
> >>
> >> We have in the past shuffled things slightly to line up things up with 
> >> distros on request, particularly LTS releases. We can certainly explore 
> >> that on a one-off basis.
> >>
> >> >With this schedule in place, we would also benefit from more beta 
> >> >releases over a slightly longer period. They would be packaged into the 
> >> >beta and RC releases of those distributions thus enabling more 
> >> >pre-release testing.
> >>
> >> We did have 6 month release cycles in the past.
> >>
> >> The rationale for moving at the time was twofold:
> >>  - people rushed in changes towards the feature freeze as otherwise it 
> >> would be aages till their changes reached users
> >>  - the more changes we have in a release, the more testing and inevitable 
> >> regression fixes we need to do, spreading that out should result in things 
> >> being more stable
> >>
> >> Initially we did every 3 months (which arguably still aligns) then it 
> >> slowly slipped to 4.
> >>
> >> My personal impression is that releases have gotten better as a result of 
> >> those changes, so I'm hesitant about reverting that decision.
> >>
> >
> >
> > Makes sense. With Qt being less of a moving target though, it could make 
> > sense to reevaluate our cadence though, both because we might start looking 
> > into the future and because the system we support should not be changing as 
> > much.
> >
>
> If we don't want to move to 6 months, pulling back from 4 months to 3
> months would make it easier for us to not miss Plasma releases.
>
> That being said, with Qt6 now being a thing, wouldn't that mean Qt is
> more of a moving target again?

It will take some time to be able to put together a release that's
fully tested against Qt 6.

Aleix

Re: Synchronized release schedule for Plasma

[Aleix Pol]

On Tue, Nov 24, 2020 at 5:10 PM David Edmundson 
wrote:

> As distribution package maintainers, we would like Plasma developers to
>> slightly alter the release schedule to align releases with a more
>> distribution friendly cycle. You could consider shortening one release
>> cycle (and then keep the 6 month schedule) to align releases.
>>
>
> We have in the past shuffled things slightly to line up things up with
> distros on request, particularly LTS releases. We can certainly explore
> that on a one-off basis.
>
> >With this schedule in place, we would also benefit from more beta
> releases over a slightly longer period. They would be packaged into the
> beta and RC releases of those distributions thus enabling more pre-release
> testing.
>
> We did have 6 month release cycles in the past.
>
> The rationale for moving at the time was twofold:
>  - people rushed in changes towards the feature freeze as otherwise it
> would be aages till their changes reached users
>  - the more changes we have in a release, the more testing and inevitable
> regression fixes we need to do, spreading that out should result in things
> being more stable
>
> Initially we did every 3 months (which arguably still aligns) then it
> slowly slipped to 4.
>
> My personal impression is that releases have gotten better as a result of
> those changes, so I'm hesitant about reverting that decision.
>
>

Makes sense. With Qt being less of a moving target though, it could make
sense to reevaluate our cadence though, both because we might start looking
into the future and because the system we support should not be changing as
much.

Aleix

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-devel@kde.org instead of
> kde-core-de...@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-devel@kde.org for a wider audience.

Aleix

Re: Fix 'Connections' warnings in QML

[Aleix Pol]

Hi Konrad,
It's okay to fix them in Plasma. Most of the ones we still have though
are in frameworks that still depend on Qt 5.12 and it's not trivial to
address this problem over there.

Aleix

On Mon, Nov 9, 2020 at 10:25 AM Konrad Materka  wrote:
>
> Hi,
>
> With Qt 5.15 we have tons of warnings like:
> QML Connections: Implicitly defined onFoo properties in Connections are 
> deprecated.
>
> Qt 5.15 is now a minimum requirement for Plasma Workspace, so nothing is 
> blokcking to migrate to new syntax.
>
> Is it OK to fix them in one massive MR or better to do that one by one (I 
> mean one applet/module at a time)?
>
> --
> Regards:
> Konrad Materka

Re: Plasma and a bachelor thesis

[Aleix Pol]

On Thu, Oct 22, 2020 at 5:57 AM Christoph Feck  wrote:
>
> On 10/16/20 15:26, Ilya Bizyaev wrote:
> > I've had a wild idea of doing a KDE-related engineering project
>
> Thank you for your interest in helping the KDE community!
>
> If you exclude anything reported to bugs.kde.org (which does not only
> list bugs, but also has ideas for new features), you could also use
> these for inspirations:
>
> - Brainstorm in KDE Forums: https://forum.kde.org/viewforum.php?f=83
>
> -
> https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html
>
> On a more personal note, see https://bugs.kde.org/show_bug.cgi?id=252353

This reminds me how we're in constant need of work on the
accessibility front. Handwriting would be useful, and so would any
advancement in that realm.

If you're into image recognition, having some sort of AI savvy app for
Plasma Mobile will be necessary too eventually ;).

Aleix

Re: Plasma and a bachelor thesis

[Aleix Pol]

On Fri, Oct 16, 2020 at 3:26 PM Ilya Bizyaev  wrote:
>
> Hello!
>
> I'm currently in my last year of bachelor studies, and I'm now looking for a 
> topic for my bachelor thesis. I've had a wild idea of doing a KDE-related 
> engineering project since it sounds fun, would give me a good occasion to 
> help advance open source software that I use and love, and appears to be an 
> acceptable way of doing the thesis from my university's side.
>
> Since it would have to be a big project, "scratching my own itch" with 
> bugfixes won't work. It would also require a sensible degree of novelty, so 
> doing something-that-GNOME-has-but-in-Qt is also not an option. Finally, for 
> a successful project I would need to prove its relevance, so that would have 
> to be something actually useful and releasable as part of our products.
>
> That's why I decided to write an email to this mailing list and ask if 
> someone with more insight into Plasma's development direction has some ideas 
> for such a project.
>
> As for me, you may have seen me around KDE for a while :) I study applied 
> mathematics and computer science at ITMO University in St Petersburg, so have 
> a background in mathematics, algorithms and data structures, and other 
> relevant subjects. I primarily code in C++ and have some insight into Qt/KDE 
> software, and I've worked on Chrome OS in the past. There are some topics 
> suggested by the university (mostly around machine learning), and there will 
> likely be some more from its partner companies, but I am curious if I can 
> also complete a well-defined and meaningful project for KDE.
>
> Best regards,
> Ilya Bizyaev 
>

Hi Ilya,
Have you thought about what you would like to do? Would you have some
ideas about something you would like to see developed?

I also did my master thesis on KDE software and I think it worked
well, I'd love to help you do it too.

Aleix

Re: Integration of layer-shell in plasma

[Aleix Pol]

On Mon, Aug 24, 2020 at 4:20 PM Vlad Zahorodnii  wrote:
>
> Howdy,
>
> As you probably know, surfaces created by plasmashell need to be treated
> specially by the compositor. For example, notification windows must be
> always on top, panels may go above and below normal windows. That's why
> we use a proprietary protocol called plasma-shell for creating shell
> surfaces that provide the functionality required by plasmashell.
>
> Unfortunately, there are technical issues with the plasma-shell protocol
> that can be fixed only by rewriting the protocol from scratch. Luckily
> for us, the sway community came up with a protocol called layer-shell
> that a desktop environment could use in order to build components such
> as panels, notifications, etc. The layer-shell protocol doesn't suffer
> from the problems that we have with the plasma-shell protocol.
>
> The cool thing about is that with the layer-shell protocol it will be
> possible to make applications such as latte-dock run across desktop
> environments.
>
> Over the last a couple of weeks, I've been working on a layer-shell
> protocol implementation in kwin. With the compositor side being almost
> complete (it's still under code review), it's a good time to focus on
> the client side.
>
> The biggest difference between the layer-shell protocol and the
> plasma-shell protocol is that positioning is done in relative terms in
> the former protocol. For example, instead of saying "please place me at
> the specified position (x, y)," a client must say "please place me 10px
> away from the left screen edge." Which brings us to the first problem:
> we need to ditch specifying absolute window coordinates and transition
> to relative positioning. Unfortunately, we cannot do it all at once, so
> we need some way to smoothly transition between the two approaches. I
> see several options:
>
> * Mimic absolute positioning via relative positioning. It's good as a
> short-term solution, but imho, we need something better
> * Introduce a Plasma::Dialog with relative positioning and start
> gradually porting all plasma components to it
>
> The second problem is that we need to integrate the layer-shell protocol
> in Qt in some way. Since plasmashell creates both normal windows and
> special-purpose windows, we need to use **both** the xdg-shell and the
> layer-shell protocol. It's not really clear how it can be achieved.
>
> The most ideal case is where Qt provides native support for the
> layer-shell protocol out of the box. API-wise, plasmashell needs to set
> the layer, the namespace, the margins, etc. Alternatively, we could fork
> QtWayland QPA and extend it with features we need. Either way, we need
> some changes in Qt in order to be able to use several shell surface
> protocols simultaneously.
>
> Any ideas or thoughts on what the best way to integrate the layer-shell
> protocol in plasma and Qt is?
>
> Cheers,
> Vlad

I guess one way is by levarging QT_WAYLAND_SHELL_INTEGRATION plugin
system, like maliit does. I don't know how this could be done
per-window instead of per-process.

The shell integration plugin could be implemented in Qt together with
xdg-shell and ivi (see qtwayland/src/plugins/shellintegration).

HTH,
Aleix

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Aleix Pol]

On Fri, Aug 7, 2020 at 7:04 PM Nate Graham  wrote:
>
> [Gardening team hat on]
>
> Klipper bugs currently live in the Klipper product, not as a product
> inside the Plasmashell component like other first-party
> shipped-by-default applets. As a result these bugs seem to have been
> overlooked by bug triaging efforts, because the product currently has
> 159 bugs which like they're in desperate need of triaging, marking
> dupes, etc. Also users seem to file bugs in both places which further
> confuses the situation.
>
> I would like to propose moving the applet-specific Klipper bugs into a
> new Plasmashell | Clipboard product.
>
> Any objections?

Sounds good to me. Nowadays klipper being separate from plasma is
mostly an implementation detail as it's maintained by the same team.

Aleix

Re: Plasma related BoFs at Akademy 2020

[Aleix Pol]

On Tue, Aug 4, 2020 at 8:48 AM David Redondo  wrote:
>
> Hi Aleix,
>
> Am Montag, 3. August 2020, 16:40:21 CEST schrieb Aleix Pol:
> > We do have several Plasma BoF. I see at least Plasma Discover and
> > Plasma Mobile. ;)
> Seems like I should have used ctrl+f instead of scrolling over the page and
> looking manually. ;)
> > Hardware collaborations should also be related to Plasma IMHO.
> >
> > Maybe it would make sense to have one about "Getting started to
> > collaborate with Plasma"?
>
> I think that would be a great topic. Do you imagine it as a session that would
> be useful for people who want to start collaborating?

Yes, and maybe meet and ask the developers. I haven't thought it through.

Re: Plasma related BoFs at Akademy 2020

[Aleix Pol]

Hi David,
We do have several Plasma BoF. I see at least Plasma Discover and
Plasma Mobile. ;)
Hardware collaborations should also be related to Plasma IMHO.

Maybe it would make sense to have one about "Getting started to
collaborate with Plasma"?

Aleix

On Mon, Aug 3, 2020 at 3:52 PM David Redondo  wrote:
>
> Hi,
>
> currently I see no Plasma related BoFs at https://community.kde.org/Akademy/
> 2020/AllBoF . Do you think we should have some specific BoFs and/or a general
> Plasma one? Or maybe you already have a subject that you feel warrants a BoF?
> Then feel free to tell us and add it to the wiki.
>
> Regards,
> David
>
>

Re: Gitlab and plasma dev

[Aleix Pol]

On Thu, Jul 23, 2020 at 4:40 PM David Edmundson
 wrote:
>
> Gitlab has a new "approve" feature. I think it naturally makes sense to use 
> this instead of the labels as our official workflow.
>
> One thing to note is that (like labels) the approve button does not send any 
> emails to the recipient.

I definitely think it makes sense to use it.

I wonder about the etiquette WRT merging other people's MRs.
I think in most cases it just integrates a bit earlier and I don't
think we win much by having the original author merge it.

Aleix

Re: KDE CI: Plasma » kwayland-server » kf5-qt5 FreeBSDQt5.15 - Build # 22 - Failure!

[Aleix Pol]

We need newer plasma-wayland-protocols, retriggered the dependency build.

Aleix

On Thu, Jul 23, 2020 at 2:58 PM CI System  wrote:

> *BUILD FAILURE*
> Build URL
> https://build.kde.org/job/Plasma/job/kwayland-server/job/kf5-qt5%20FreeBSDQt5.15/22/
> Project: kf5-qt5 FreeBSDQt5.15
> Date of build: Thu, 23 Jul 2020 12:57:41 +
> Build duration: 25 sec and counting
> * CONSOLE OUTPUT *
> [...truncated 258 lines...]
> [2020-07-23T12:58:00.106Z] -- The following REQUIRED packages have been
> found:
> [2020-07-23T12:58:00.106Z]
> [2020-07-23T12:58:00.106Z] * ECM (required version >= 5.70.0)
> [2020-07-23T12:58:00.106Z] * Qt5Concurrent
> [2020-07-23T12:58:00.106Z] * Qt5WaylandClient
> [2020-07-23T12:58:00.106Z] * Qt5Gui (required version >= 5.12.0)
> [2020-07-23T12:58:00.106Z] * KF5Wayland (required version >= 5.70.0)
> [2020-07-23T12:58:00.106Z] * PlasmaWaylandProtocols
> [2020-07-23T12:58:00.106Z] * QtWaylandScanner, Executable that converts
> XML protocol files to C++ code, 
> [2020-07-23T12:58:00.106Z] * Wayland (required version >= 1.15), C library
> implementation of the Wayland protocol: a protocol for a compositor to talk
> to its clients, 
> [2020-07-23T12:58:00.106Z] * WaylandProtocols (required version >= 1.15),
> Specifications of extended Wayland protocols, <
> https://wayland.freedesktop.org/>
> [2020-07-23T12:58:00.106Z] * EGL, A platform-agnostic mechanism for
> creating rendering surfaces for use with other graphics libraries, such as
> OpenGL|ES and OpenVG., 
> [2020-07-23T12:58:00.106Z] * Qt5Test
> [2020-07-23T12:58:00.106Z] * Qt5
> [2020-07-23T12:58:00.106Z] * WaylandScanner, Executable that converts XML
> protocol files to C code, 
> [2020-07-23T12:58:00.106Z]
> [2020-07-23T12:58:00.106Z] -- The following features have been disabled:
> [2020-07-23T12:58:00.106Z]
> [2020-07-23T12:58:00.106Z] * QCH, API documentation in QCH format (for
> e.g. Qt Assistant, Qt Creator & KDevelop)
> [2020-07-23T12:58:00.106Z]
> [2020-07-23T12:58:00.106Z] -- Configuring done
> [2020-07-23T12:58:00.377Z] -- Generating done
> [2020-07-23T12:58:00.377Z] -- Build files have been written to:
> /usr/home/jenkins/workspace/Plasma/kwayland-server/kf5-qt5
> FreeBSDQt5.15/build
> [Pipeline] }
> [Pipeline] // stage
> [Pipeline] stage
> [Pipeline] { (Compiling)
> [Pipeline] sh
> [2020-07-23T12:58:01.696Z] + python3 -u
> ci-tooling/helpers/compile-build.py --product Plasma --project
> kwayland-server --branchGroup kf5-qt5 --platform FreeBSDQt5.15
> --usingInstall /home/jenkins/install-prefix/
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target
> plasmasurface-test_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target
> shadowTest_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target xdg-test_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target
> copyClient_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target
> xdgforeign-test_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target
> pasteClient_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target
> KWaylandServer_autogen
> [2020-07-23T12:58:01.697Z] Scanning dependencies of target dpmsTest_autogen
> [2020-07-23T12:58:01.697Z] [ 2%] Automatic MOC for target
> plasmasurface-test
> [2020-07-23T12:58:01.697Z] [ 2%] Automatic MOC for target xdg-test
> [2020-07-23T12:58:01.697Z] [ 3%] Automatic MOC for target xdgforeign-test
> [2020-07-23T12:58:01.697Z] [ 3%] Automatic MOC for target shadowTest
> [2020-07-23T12:58:01.697Z] [ 3%] Automatic MOC for target pasteClient
> [2020-07-23T12:58:01.697Z] [ 3%] Automatic MOC for target copyClient
> [2020-07-23T12:58:01.697Z] [ 4%] Automatic MOC for target dpmsTest
> [2020-07-23T12:58:01.697Z] [ 4%] Automatic MOC for target KWaylandServer
> [2020-07-23T12:58:01.954Z] [ 4%] Built target dpmsTest_autogen
> [2020-07-23T12:58:01.954Z] Scanning dependencies of target dpmsTest
> [2020-07-23T12:58:01.954Z] [ 4%] Building CXX object
> tests/CMakeFiles/dpmsTest.dir/dpmsTest_autogen/mocs_compilation.cpp.o
> [2020-07-23T12:58:02.212Z] [ 4%] Building CXX object
> tests/CMakeFiles/dpmsTest.dir/dpmstest.cpp.o
> [2020-07-23T12:58:02.778Z] [ 4%] Built target xdg-test_autogen
> [2020-07-23T12:58:02.778Z] [ 4%] Built target xdgforeign-test_autogen
> [2020-07-23T12:58:02.778Z] Scanning dependencies of target xdg-test
> [2020-07-23T12:58:02.778Z] [ 4%] Built target copyClient_autogen
> [2020-07-23T12:58:03.037Z] [ 4%] Building CXX object
> tests/CMakeFiles/xdg-test.dir/xdg-test_autogen/mocs_compilation.cpp.o
> [2020-07-23T12:58:03.037Z] [ 4%] Built target shadowTest_autogen
> [2020-07-23T12:58:03.037Z] [ 4%] Building CXX object
> tests/CMakeFiles/xdg-test.dir/xdgtest.cpp.o
> [2020-07-23T12:58:03.037Z] [ 4%] Built target plasmasurface-test_autogen
> [2020-07-23T12:58:03.037Z] Scanning dependencies of target copyClient
> [2020-07-23T12:58:03.037Z] [ 

Re: KDE CI: Plasma » kwin » kf5-qt5 FreeBSDQt5.15 - Build # 57 - Still Failing!

[Aleix Pol]

*shakes head at the little demon in disappointment*


On Wed, Jul 22, 2020 at 12:49 AM David Edmundson
 wrote:
>
>
> Investigated, kwin is just failing as BSD is missing some frameworks changes. 
> All good from a Plasma POV.

Re: Gitlab merge workflow: reverse it?

[Aleix Pol]

On Thu, Jun 25, 2020 at 7:49 PM David Edmundson
 wrote:
>> You have this button from commit page, not merge request page.
>>
>> https://i.imgur.com/9kgdpVy.png
>
>
> Found it, that's perfect thanks.
>
> That's also a useful feature in the current workflow.
> Seems you can cherry-pick a commit in a work/branch to a new merge request.
>
>>
>> If you use git cherry-pick with -x option, git automatically adds this
>> message in commit.
>
>
> That's handy. Clearly it's a common workflow then.
>
>>
>> >   - without making people commit locally into stable, could it encourage
>> > people to not test as much?
>>
>> I did not actually suggest using Web UI but using the git operation
>> locally. And in fairness either way we do end up with one bit where
>> thing is untested,
>
>
> It was the use of the web UI that I thought might encourage it, as then 
> you're not even changing branches locally to test things.
> You're right that changing the workflow doesn't necessarily mean changing 
> that.
>
> And yes, it's a problem already, which is why I don't want it getting worse!
>
> There's another advantage in this pattern we've not discussed yet. We can 
> commit something to master, test for a few days and only then decide to 
> cherry-pick to stable, that could potentially improve some things.

That last point is very important. Provided that it will compile for sure...

When Qt suggested doing this, it felt a bit weird but I guess it was
more fear of the unknown than anything else.

I'd say let's do this and see what happens.

The biggest con I find is that it will be harder to track where fixes
are. I do "git tag --contains commitid" quite often, but this will
replicate the commits to the different places so it will be less
useful. A small price to pay I guess.

Aleix

Sprint schedule

[Aleix Pol]

Hi,
To make it easier for everyone to join the different discussions we
figured it would make sense to set some time for different discussions
so people can participate in the conversations they care about. Here's
what we have so far:

# Friday

- 12pm Plasma 5.20 kickoff including release schedule (jonathan,
almost everyone)

- 3pm Convertible and mobile (bshah, nico, aleix, marco)

- 4pm wallpapers (nate)!
Wallpaper cache: https://phabricator.kde.org/T10495
Wallpaper KCM: https://phabricator.kde.org/T12622 (nate, marco)

- 5pm Come to some consensus on new Panel/Task Manager defaults
(nate): https://phabricator.kde.org/T12441 (there are two options;
should we do one of them? None of them?)

# Saturday

- 11am KF6 - architectural plans for Plasma (david, arjen, marco,
nico, aleix, kbroulik)

- 12pm KF6 - QQC2 desktop themes, plans, goals, styling and how to
move forward (carl, davidl, arjen, aleix, kbroulik,marco)
https://phabricator.kde.org/T13256
https://phabricator.kde.org/T11558

- 2pm Wayland (David Edmundson, aleix,marco)

- 3pm KirigamiAddons, what needs to be done, get it actually out
(nico, d_ed, marco, carl, kbroulik, bshah, nate)

- 4pm vhi priority bugs (d_ed, marco, nate)

- 5pm manage some of the not-too-old reviews still lingering on phab



# Sunday

- 12pm Notifications (sound, lockscreen, kdeconnect etc) (Kai, Bhushan, nico)

- 2pm Brainstorm new powerdevil KCM (nico, bshah, kai?)

- 3pm Discussion on how we can improve getting new contributors
(bshah, carl, nico, aleix)

- 4pm Workflow with Gitlab and workboard (bshah, carl, david, kbroulik)

Re: KEmoticons, emoticons kcm

[Aleix Pol]

On Sun, May 24, 2020 at 3:09 AM Sandro Knauß  wrote:

> Hi,
>
> > Now while I know why this exists, it feels like it's more of a thing
> > of the past from when people wrote :) instead of .
>
> Okay now I feeling old :-) -  I don't even know how to create a unicode
> smiley, that's why I always create these :-) smileys.
>
> hefee
>

If you use any stable Plasma you'll get the emoji selector by pressing
meta+.(dot).

Aleix

KEmoticons, emoticons kcm

[Aleix Pol]

Hi,
I was looking through some Plasma code and I saw that we have some
fairly old emoticons KCM using KF5Emoticons.

Now while I know why this exists, it feels like it's more of a thing
of the past from when people wrote :) instead of . While keeping it
around for the few apps that might still use it (ktp? kopete?) could
make sense, I'm afraid it's probably making it confusing for the users
who expect this to actually allow them to customise their  but
won't.

Do you think it would make sense to deprecate the framework and remove the KCM?

If some application still uses it, they can integrate the kcm
temporarily until their users come to terms that  is the new :).

Aleix

D27555: Add a category for kde-only and gnome-only apps

[Aleix Pol Gonzalez]

apol abandoned this revision.
apol added a comment.


  I don't feel like the world needs this.

REPOSITORY
  R134 Discover Software Store

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

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

D28884: screencasting: Adoption of the org_kde_plasma_video_streaming protocol

[Aleix Pol Gonzalez]

apol added a comment.


  This is on 
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/1 now.

REPOSITORY
  R838 Flatpak Support: KDE Portal for XDG Desktop

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

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

D28884: screencasting: Adoption of the org_kde_plasma_video_streaming protocol

[Aleix Pol Gonzalez]

This revision was automatically updated to reflect the committed changes.
Closed by commit R838:0d2bd657963c: screencasting: Adoption of the 
org_kde_plasma_video_streaming protocol (authored by apol).

REPOSITORY
  R838 Flatpak Support: KDE Portal for XDG Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28884?vs=82302=83050

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

AFFECTED FILES
  CMakeLists.txt
  cmake/modules/FindEpoxy.cmake
  cmake/modules/FindGBM.cmake
  cmake/modules/FindPipeWire.cmake
  data/CMakeLists.txt
  data/kde-no-pipewire.portal
  data/org.freedesktop.impl.portal.desktop.kde.desktop.in
  src/CMakeLists.txt
  src/desktopportal.cpp
  src/desktopportal.h
  src/remotedesktop.cpp
  src/screencast.cpp
  src/screencast.h
  src/screencasting.cpp
  src/screencasting.h
  src/screencaststream.cpp
  src/screencaststream.h
  src/screenchooserdialog.cpp
  src/screenchooserdialog.h
  src/screenchooserdialog.ui
  src/waylandintegration.cpp
  src/waylandintegration.h
  src/waylandintegration_p.h

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

D29784: Hardcode fewer colorSets

[Aleix Pol Gonzalez]

apol closed this revision.

REPOSITORY
  R134 Discover Software Store

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

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

D29785: Always use Window colorset for AbstractApplicationHeader

[Aleix Pol Gonzalez]

apol added a comment.


  I wonder if this should be specified in ToolBarApplicationHeader instead.

REPOSITORY
  R169 Kirigami

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

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

D29784: Hardcode fewer colorSets

[Aleix Pol Gonzalez]

apol added a comment.


  addressed

REPOSITORY
  R134 Discover Software Store

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

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

D29784: Hardcode fewer colorSets

[Aleix Pol Gonzalez]

apol updated this revision to Diff 83035.
apol marked an inline comment as done.
apol added a comment.


  Address comment

REPOSITORY
  R134 Discover Software Store

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29784?vs=82964=83035

BRANCH
  Plasma/5.19

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

AFFECTED FILES
  discover/qml/ApplicationsListPage.qml
  discover/qml/BrowsingPage.qml
  discover/qml/SourcesPage.qml
  discover/qml/UpdatesPage.qml

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

D29784: Hardcode less colorSets

[Aleix Pol Gonzalez]

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

REVISION SUMMARY
  We were overriding them on the background only and it would play weird with 
the
  feature where the toolbar looks the same as the page.
  
  BUG: 421571

TEST PLAN
  Still feels a bit random that it keeps changing but at least it looks 
consistent.

REPOSITORY
  R134 Discover Software Store

BRANCH
  Plasma/5.19

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

AFFECTED FILES
  discover/qml/ApplicationsListPage.qml
  discover/qml/BrowsingPage.qml
  discover/qml/SourcesPage.qml
  discover/qml/UpdatesPage.qml

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