Re: Plasma 6.2.0 tars available for packagers

[Jonathan Riddell]

A second update to plasma-workspace tar today to fix a crash when the
current activity changes
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4788
plasma-workspace;Plasma/6.2;ba67ab37fca0ddc1f61b1a06ff748449e6cf3f5b;plasma-workspace-6.2.0.tar.xz;2d4268cbae757631be57d69d34fc02c8d0204762515370c9679ecb2aa2afdf33


On Fri, 4 Oct 2024 at 09:51, Jonathan Riddell  wrote:

> This morning we have tar updates to plasma-workspace to fix an issue in
> klipper
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4785 and
> spacebar and plasma-dialer got rerolled to remove the old version numbers
> from the Appstream files which confused some distro's tooling.
>
> http://embra.edinburghlinux.co.uk/~jr/tmp/plasma-6.2.0-release-data
>
> plasma-workspace;Plasma/6.2;5319e8edfed25fb0a42cfee188745bb4f650a4b4;plasma-workspace-6.2.0.tar.xz;1deeccee5db3daf36701fe1f3aa11460806f278b28ab78f1c688803f4a8204db
>
> plasma-dialer;Plasma/6.2;23cee63abde3d1cda8fc0d45f9ec550aefd73279;plasma-dialer-6.2.0.tar.xz;ef6247d02db10322521e52e71e9c94291f07abddaf16f084613c8dd36f7caace
> spacebar;Plasma/6.2;6cf6ac3da7031d5b50650b78d9599644b7f1c5d3;spacebar-6.2.0.tar.xz;427a29e9eb2a79e9059d8af69bb56b5d472e13421dc872d0a59358b8307a986e
>
>
>

Re: Plasma 6.2.0 tars available for packagers

[Jonathan Riddell]

This morning we have tar updates to plasma-workspace to fix an issue in
klipper https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4785
and spacebar and plasma-dialer got rerolled to remove the old version
numbers from the Appstream files which confused some distro's tooling.

http://embra.edinburghlinux.co.uk/~jr/tmp/plasma-6.2.0-release-data

plasma-workspace;Plasma/6.2;5319e8edfed25fb0a42cfee188745bb4f650a4b4;plasma-workspace-6.2.0.tar.xz;1deeccee5db3daf36701fe1f3aa11460806f278b28ab78f1c688803f4a8204db

plasma-dialer;Plasma/6.2;23cee63abde3d1cda8fc0d45f9ec550aefd73279;plasma-dialer-6.2.0.tar.xz;ef6247d02db10322521e52e71e9c94291f07abddaf16f084613c8dd36f7caace
spacebar;Plasma/6.2;6cf6ac3da7031d5b50650b78d9599644b7f1c5d3;spacebar-6.2.0.tar.xz;427a29e9eb2a79e9059d8af69bb56b5d472e13421dc872d0a59358b8307a986e

Re: GTK apps integration in Plasma Wayland and Distribution Packaging

[Vlad Zahorodnii]

Hello,

On 9/30/24 4:01 PM, Nate Graham wrote:
FWIW, my understanding is that the font rendering issue requiring the 
GTK portal to fix it should be resolved as of 
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7748.


It appears that the GTK portal is needed for more than that. Without the 
GTK portal, GTK apps use wrong icon theme, theme, and so on.


Vlad

Re: GTK apps integration in Plasma Wayland and Distribution Packaging

[Nate Graham]

FWIW, my understanding is that the font rendering issue requiring the 
GTK portal to fix it should be resolved as of 
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7748.


If that's indeed the case, we should be able to stop requiring or 
recommending that the package be included.


Nate



On 9/30/24 4:49 AM, Vlad Zahorodnii wrote:

Hi,

A common pitfall with packaging the Plasma Wayland session is omitting 
important dependencies that are a cornerstone for proper integration of 
GTK applications and also some flatpak applications. These dependencies 
include:


- xsettingsd
- and, xdg-desktop-portal-gtk

While xsettings is marked properly as a runtime dependency in kde-gtk- 
config, we have a history of kde-gtk-config packages not pulling 
xsettings on some distros. Furthermore, neither kde-gtk-config nor 
plasma-workspace mark xdg-desktop-portal-gtk as a runtime dependency, so 
if you install the plasma wayland session on some distros, it's not 
guaranteed that the GTK XDG portal will be installed too. Diagnosing 
integration issues with GTK applications can be challenging, and, 
ideally, it should require no manual user intervention. So, I've been 
wondering how we could communicate to distributions more clearly that 
these packages need to be installed (even though they are runtime 
dependencies), so the users don't experience integration issues with GTK 
apps?


Vlad

Re: Move Plasma Dialer and Spacebar to Plasma release

[Jonathan Riddell]

Nicolas is right there's no dependency on libplasma from Spacebar just my
mistake.

But we discussed it in the Plasma room just now and decided they both
should be released together and since Plasma Dialer depends on Plasmay
things it would be best to release it with Plasma, so I'll include it in
Plasma 6.2.

Jonathan

Re: Move Plasma Dialer and Spacebar to Plasma release

[Nicolas Fella]

On 22.08.24 13:29, Jonathan Riddell wrote:

Plasma Dialer depends on KWin and Plasma Wayland Protocols, Spacebar
(SMS messaging app) similarly depends on libplasma, so it would seem
sensible to have these as part of Plasma releases.


Where does Spacebar depend on libplasma?




Repo freeze is in 7 days time on 29th August.

We can ask at the Plasma meeting next Monday.

They're not the most active of projects but they are maintained.

Jonathan

Re: Move Plasma Dialer and Spacebar to Plasma release

[Jonathan Riddell]

Plasma Dialer depends on KWin and Plasma Wayland Protocols, Spacebar (SMS
messaging app) similarly depends on libplasma, so it would seem sensible to
have these as part of Plasma releases.

Repo freeze is in 7 days time on 29th August.

We can ask at the Plasma meeting next Monday.

They're not the most active of projects but they are maintained.

Jonathan

Re: Move Plasma Dialer and Spacebar to Plasma release

[Ben Cooksley]

On Thu, Aug 22, 2024 at 10:57 AM Albert Astals Cid  wrote:

> El dijous, 15 d’agost del 2024, a les 10:41:53 (CEST), Carl Schwan va
> escriure:
> > Hi,
> >
> > Me again, this time to ask to move Plasma Dialer and Spacebar to the
> Plasma
> > release cycle (or gear release cycle).
> >
> > I did the two last releases 23.01 and 24.08 for dialer and 23.01 and
> 24.05
> > for spacebar, and as you might guess from the version numbers, the
> > frequency of the release as been quite bad. Moving to a release service
> > would help a lot.
> >
> > This could either go in the plasma release because both applications are
> > core component of Plasma Mobile and additional Dialer has an optional
> > dependency on plasma wayland protocols. Or in Gear because that's where
> > most plasma mobile apps are. I don't really have a preference.
>

Given the dependencies sounding like it would be a better fit within Plasma?


>
> I don't have a preference either.
>
> We can do KDE Gear I guess if no one disagrees.
>
> Cheers,
>   Albert
>
> >
> > Cheers,
> > Carl
>
>
>
Cheers,
Ben

Re: Move Plasma Dialer and Spacebar to Plasma release

[Albert Astals Cid]

El dijous, 15 d’agost del 2024, a les 10:41:53 (CEST), Carl Schwan va 
escriure:
> Hi,
> 
> Me again, this time to ask to move Plasma Dialer and Spacebar to the Plasma
> release cycle (or gear release cycle).
> 
> I did the two last releases 23.01 and 24.08 for dialer and 23.01 and 24.05
> for spacebar, and as you might guess from the version numbers, the
> frequency of the release as been quite bad. Moving to a release service
> would help a lot.
> 
> This could either go in the plasma release because both applications are
> core component of Plasma Mobile and additional Dialer has an optional
> dependency on plasma wayland protocols. Or in Gear because that's where
> most plasma mobile apps are. I don't really have a preference.

I don't have a preference either.

We can do KDE Gear I guess if no one disagrees.

Cheers,
  Albert

> 
> Cheers,
> Carl

Re: QtWayland 6.7.2 packaging recommendation

[Nicolas Fella]

On 09.07.24 11:14, Vlad Zahorodnii wrote:

Hello,

QtWayland 6.7.2 contains a regression with regards to initializing the
popup parent, which can result in the plasmashell process getting
killed in some circumstances (e.g.
https://bugs.kde.org/show_bug.cgi?id=489259). The regression has been
fixed in 6.7.3, but according to the Qt release schedule, 6.7.3 is
going to be released in about two months.

In meanwhile, could distros that ship the Plasma Wayland session
include
https://invent.kde.org/qt/qt/qtwayland/-/commit/92bcb8f6b7a852c7a5d662fc34de561692a7a454
to fix plasmashell crashing until 6.7.3 is finally released?


Hi,

there's more QtWayland patches worth backporting:

-
https://invent.kde.org/qt/qt/qtwayland/-/commit/406995207eae8d644b6e5262aa716a48c7e471a8

-
https://invent.kde.org/qt/qt/qtwayland/-/commit/632127d7f1d86cba4dd17361f24f9fd70a0ae44c

These fix a number of crashes we observe.

Cheers

Nico

Re: QtWayland 6.7.2 packaging recommendation

[Vlad Zahorodnii]

On 7/9/24 2:38 PM, Scarlett Moore wrote:

To be clear, this only affects 6.7.2, correct?


Yes, that's correct.

Vlad



Scarlett

On 7/9/24 02:14, Vlad Zahorodnii wrote:

Hello,

QtWayland 6.7.2 contains a regression with regards to initializing 
the popup parent, which can result in the plasmashell process getting 
killed in some circumstances (e.g. 
https://bugs.kde.org/show_bug.cgi?id=489259). The regression has been 
fixed in 6.7.3, but according to the Qt release schedule, 6.7.3 is 
going to be released in about two months.


In meanwhile, could distros that ship the Plasma Wayland session 
include 
https://invent.kde.org/qt/qt/qtwayland/-/commit/92bcb8f6b7a852c7a5d662fc34de561692a7a454 
to fix plasmashell crashing until 6.7.3 is finally released?


Regards,
Vlad

Re: QtWayland 6.7.2 packaging recommendation

[Scarlett Moore]

To be clear, this only affects 6.7.2, correct?

Scarlett

On 7/9/24 02:14, Vlad Zahorodnii wrote:

Hello,

QtWayland 6.7.2 contains a regression with regards to initializing the 
popup parent, which can result in the plasmashell process getting 
killed in some circumstances (e.g. 
https://bugs.kde.org/show_bug.cgi?id=489259). The regression has been 
fixed in 6.7.3, but according to the Qt release schedule, 6.7.3 is 
going to be released in about two months.


In meanwhile, could distros that ship the Plasma Wayland session 
include 
https://invent.kde.org/qt/qt/qtwayland/-/commit/92bcb8f6b7a852c7a5d662fc34de561692a7a454 
to fix plasmashell crashing until 6.7.3 is finally released?


Regards,
Vlad

Re: QtVirtualKeyboard on Plasma Wayland

[Gerd Fleischer]

Hi,

this is great news for my 2in1-Laptop!

Thanks


Am Freitag, 21. Juni 2024, 02:52:59 MESZ schrieb Aleix Pol:
> Hi,
> In recent years, we've relied heavily on Maliit as our primary virtual
> keyboard. However, I thought it would be beneficial to develop an
> alternative using QtVirtualKeyboard.
>
> https://invent.kde.org/apol/qvk
>
> Consider this a PoC, I think it can be useful to make sure we're
> compatible with a number of different keyboards. It's also a good way
> to explore such an important but ignored part of our UX. :)
>
> If you find it useful, tell me either here or in the repo's issues and
> we'll see what needs to be done to make it properly useful for
> everyone.
>
> Cheers!
> Aleix

Re: QtVirtualKeyboard on Plasma Wayland

[Justin Zobel]

There is an existing maliit plugin that's VERY old that has the 
functionality. I'll see if I can find it from my history.


On 24/6/24 17:01, Marco Martin wrote:

On Sunday, 23 June 2024 02.19.52 CEST Aleix Pol wrote:

To be honest, I'm not sure we'll be able to add many features without
adding them upstream, that's a good thing in that we'll get to create
a good product together with Qt, but we'll also need to coordinate.
That said, there does indeed seem to be good traction in QtVK so
before we need to add new features we can also try playing with the
ones they have, like handwriting (!).

yeah, swipe typing is something that should really be in there upstream,
tough if that proves to be very difficult i guess it *might* be possible to
putan item that filters events on top of the rest, then if is possible somehow
to query what key is under a certain coordinate, swiping can be implemented
there

--
Marco Martin

Re: QtVirtualKeyboard on Plasma Wayland

[Marco Martin]

On Sunday, 23 June 2024 02.19.52 CEST Aleix Pol wrote:
> To be honest, I'm not sure we'll be able to add many features without
> adding them upstream, that's a good thing in that we'll get to create
> a good product together with Qt, but we'll also need to coordinate.
> That said, there does indeed seem to be good traction in QtVK so
> before we need to add new features we can also try playing with the
> ones they have, like handwriting (!).

yeah, swipe typing is something that should really be in there upstream,
tough if that proves to be very difficult i guess it *might* be possible to 
putan item that filters events on top of the rest, then if is possible somehow 
to query what key is under a certain coordinate, swiping can be implemented 
there

--
Marco Martin

Re: QtVirtualKeyboard on Plasma Wayland

[Aleix Pol]

I've created a flatpak manifest that seems to work. There's some issue
with the SDK we have in our CI but it should be addressed easily with
a rebuild.
https://invent.kde.org/apol/qvk/-/merge_requests/1

Meaning that hunspell issues shouldn't be a big issue (I guess it's
part of the freedesktop SDK). Actually, I find it quite nice that the
input method can live in a container and can be easily  developed and
shipped. It even lists itself on the kcm.

Aleix

On Sun, Jun 23, 2024 at 12:24 AM David Edmundson
 wrote:
>
> For anyone else testing:
>  - you need to set KWIN_IM_SHOW_ALWAYS=1 or have a touchscreen (or mod kwin)
>  - you need the right hunspell dictionary installed or it just doesn't
> send anything
>
> It kinda feels we've gone full circle, Kwin used to do the Qt VK in process.
>
> It's too early to say anything for definite but I do think it's a good
> direction to explore.
> Maliit doesn't seem very alive whereas Qt VK somewhat is and the way
> you've split this we are in full control of bridging any wayland
> oddities which is a win-win.
>
> David

Re: QtVirtualKeyboard on Plasma Wayland

[Aleix Pol]

To be honest, I'm not sure we'll be able to add many features without
adding them upstream, that's a good thing in that we'll get to create
a good product together with Qt, but we'll also need to coordinate.
That said, there does indeed seem to be good traction in QtVK so
before we need to add new features we can also try playing with the
ones they have, like handwriting (!).

Aleix

On Fri, Jun 21, 2024 at 3:42 PM Devin  wrote:
>
> Hey Aleix,
>
> I think this is a very good idea! It could also help isolate any issues that 
> are specific to the keyboard and not to KWin. Maliit has been pretty slow 
> moving so it can also be worth trying out some new ideas here (ex. swipe to 
> type).
>
> Thanks,
> Devin
> 
> From: Plasma-devel  on behalf of Aleix Pol 
> 
> Sent: Thursday, June 20, 2024 8:52:59 PM
> To: plasma-devel@kde.org ; Devin ; 
> Aditya Mehra 
> Subject: QtVirtualKeyboard on Plasma Wayland
>
> Hi,
> In recent years, we've relied heavily on Maliit as our primary virtual
> keyboard. However, I thought it would be beneficial to develop an
> alternative using QtVirtualKeyboard.
>
> https://invent.kde.org/apol/qvk
>
> Consider this a PoC, I think it can be useful to make sure we're
> compatible with a number of different keyboards. It's also a good way
> to explore such an important but ignored part of our UX. :)
>
> If you find it useful, tell me either here or in the repo's issues and
> we'll see what needs to be done to make it properly useful for
> everyone.
>
> Cheers!
> Aleix

Re: QtVirtualKeyboard on Plasma Wayland

[David Edmundson]

For anyone else testing:
 - you need to set KWIN_IM_SHOW_ALWAYS=1 or have a touchscreen (or mod kwin)
 - you need the right hunspell dictionary installed or it just doesn't
send anything

It kinda feels we've gone full circle, Kwin used to do the Qt VK in process.

It's too early to say anything for definite but I do think it's a good
direction to explore.
Maliit doesn't seem very alive whereas Qt VK somewhat is and the way
you've split this we are in full control of bridging any wayland
oddities which is a win-win.

David

Re: QtVirtualKeyboard on Plasma Wayland

[Justin Zobel]

Swipe to type would be an absolutely amazing feature to get. I struggle 
to want to use my Linux phone because of this reason. I've checked out 
this repo and compiled it and will provide feedback in the coming days.


On 21/6/24 23:12, Devin wrote:

Hey Aleix,

I think this is a very good idea! It could also help isolate any 
issues that are specific to the keyboard and not to KWin. Maliit has 
been pretty slow moving so it can also be worth trying out some new 
ideas here (ex. swipe to type).


Thanks,
Devin

*From:* Plasma-devel  on behalf of Aleix 
Pol 

*Sent:* Thursday, June 20, 2024 8:52:59 PM
*To:* plasma-devel@kde.org ; Devin 
; Aditya Mehra 

*Subject:* QtVirtualKeyboard on Plasma Wayland
Hi,
In recent years, we've relied heavily on Maliit as our primary virtual
keyboard. However, I thought it would be beneficial to develop an
alternative using QtVirtualKeyboard.

https://invent.kde.org/apol/qvk

Consider this a PoC, I think it can be useful to make sure we're
compatible with a number of different keyboards. It's also a good way
to explore such an important but ignored part of our UX. :)

If you find it useful, tell me either here or in the repo's issues and
we'll see what needs to be done to make it properly useful for
everyone.

Cheers!
Aleix

Re: QtVirtualKeyboard on Plasma Wayland

[Devin]

Hey Aleix,

I think this is a very good idea! It could also help isolate any issues that 
are specific to the keyboard and not to KWin. Maliit has been pretty slow 
moving so it can also be worth trying out some new ideas here (ex. swipe to 
type).

Thanks,
Devin

From: Plasma-devel  on behalf of Aleix Pol 

Sent: Thursday, June 20, 2024 8:52:59 PM
To: plasma-devel@kde.org ; Devin ; Aditya 
Mehra 
Subject: QtVirtualKeyboard on Plasma Wayland

Hi,
In recent years, we've relied heavily on Maliit as our primary virtual
keyboard. However, I thought it would be beneficial to develop an
alternative using QtVirtualKeyboard.

https://invent.kde.org/apol/qvk

Consider this a PoC, I think it can be useful to make sure we're
compatible with a number of different keyboards. It's also a good way
to explore such an important but ignored part of our UX. :)

If you find it useful, tell me either here or in the repo's issues and
we'll see what needs to be done to make it properly useful for
everyone.

Cheers!
Aleix

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[David Edmundson]

We had a chat with some distro maintainers, there was a mixed set of results.

Ultimately we need to make an executive decision, and after a chat I'm
stating we're not going to change the wallpaper in 6.1.x.
It will be the same as 6.0 throughout. The new wallpaper can be used for 6.2.

Sorry

David

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[Marco Martin]

On Tuesday, 18 June 2024 11.12.01 CEST Marco Martin wrote:
> my main issue is that to me it would look really unprofessional the only
> message for that wallpaper will be seen as "we didn't manage to chose a
> wallpaper in time"
> back in 5.x there was only one wallpaper each 2 releases, so if 6.1 won't
> have a new one won't be that surprising.

ok, i stand corrected it was on every release, my point still stand tough


-- 
Marco Martin

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[Niccolò Ve]

Note that it wouldn't mean redoing a bunch of material, but rather it would
mean having the wrong wallpaper in the announcement, videos, and previous
promo material. Some of it has been published already, and the rest cannot
be re-done before the announcement.

~ Niccolò

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[Marco Martin]

On Tuesday, 18 June 2024 00.40.56 CEST Paul Brown wrote:
> > By the time 6.1.1 it'll be forgotten we'll restart a discussion that
> > would have otherwise completely faded away and mess users about in the
> > process.
> 
> 6.1.1 is only a week in the future. It is not so far off that we can assume
> everyone will forget. And, anyway, one thing Promo does well is remind our
> users of stuff.

my main issue is that to me it would look really unprofessional the only 
message for that wallpaper will be seen as "we didn't manage to chose a 
wallpaper in time" 
back in 5.x there was only one wallpaper each 2 releases, so if 6.1 won't have 
a new one won't be that surprising.

I know it will mean redoing a bung of material, but i don't think we can make 
an exception

-- 
Marco Martin

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[Kai Uwe Broulik]

fwiw Plasma 5.1 also had the same wallpaper as 5.0 ;)

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[Kai Uwe Broulik]

Indeed SUSE will probably not be very amused when their openQA tests 
start failing in a patch release because the default wallpaper changed.


Am 18.06.24 um 08:43 schrieb David Edmundson:


What is the problem of delivering the wallpaper with 6.1.1?


It's a behavioural change in a patch release. Patch releases should be
bugfixes only.

David

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[David Edmundson]

>
> What is the problem of delivering the wallpaper with 6.1.1?

It's a behavioural change in a patch release. Patch releases should be
bugfixes only.

David

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[Paul Brown]

On Tuesday 18 June 2024 00:27:56 CEST David Edmundson wrote:
> I'm not convinced it has a net benefit.
> 
> People who update on the day will be already surprised. People who
> update later will have forgotten all about the background of a
> webpage/tweets they already saw.
> 
> By the time 6.1.1 it'll be forgotten we'll restart a discussion that
> would have otherwise completely faded away and mess users about in the
> process.

6.1.1 is only a week in the future. It is not so far off that we can assume 
everyone will forget. And, anyway, one thing Promo does well is remind our 
users of stuff.

> Someone on chat proposed putting a link to the wallpaper in the
> announcement, that would look the most deliberate.
> 
> "Our page today featured the artwork of our contest winner blah blah
> blah, with Plasma you can make your desktop your way blah blah blah,
> download their wallpaper here.".

What is the problem of delivering the wallpaper with 6.1.1?

Cheers

Paul
-- 
Promotion & Communication

www: https://kde.org
Mastodon: https://floss.social/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde

Re: Shipping Plasma 6.1 wallpaper in Plasma 6.1.1

[David Edmundson]

I'm not convinced it has a net benefit.

People who update on the day will be already surprised. People who
update later will have forgotten all about the background of a
webpage/tweets they already saw.

By the time 6.1.1 it'll be forgotten we'll restart a discussion that
would have otherwise completely faded away and mess users about in the
process.

---

Someone on chat proposed putting a link to the wallpaper in the
announcement, that would look the most deliberate.

"Our page today featured the artwork of our contest winner blah blah
blah, with Plasma you can make your desktop your way blah blah blah,
download their wallpaper here.".

David

Re: Plasma 6.1 tars are up for packaging

[David Edmundson]

Unfortunately there was a last minute respin of plasma-workspace under
the same name.
It addresses a config migration so couldn't  wait till 6.1.1 unfortunately.

David

Re: Plasma 6.1 and 6.2 release schedule proposal

[Marco Martin]

On Friday, 7 June 2024 21.11.07 CEST Jonathan Riddell wrote:
> The main action happens around September, pic attached. We have repo
> and soft feature freeze 29 August, 6.2 beta 12 september, 6.2 Tars on
> 3 October to be released 8 October.  That means 6.1.5 and 6.2 beta
> happen during Akademy.
> 
> Yay or nay?

To me seemsto make sense, +1. other opinions?

-- 
Marco Martin

Re: String/Feature freeze exception request

[Zayed Al-Saidi]

No objection from the Arabic team.

On Tue, May 28, 2024 at 2:18 AM Ismael Asensio  wrote:

> Hello dear devs and translation teams!
>
> I'd like to request a string freeze exception to cherry-pick this MR into
> 6.1:
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589
>
> The MR adds a new placeholder item (and therefore 3 new strings) to
> the weather applet, in case we fail to retrieve the forecast report due to
> server errors in the provider.
>
> Otherwise, the applet will look broken, giving many users a suboptimal
> experience.
>
> This just transpired now due to some recent changes in the US Weather
> Service provider (noaa), which may make it fail. It was a very bad timing
> that it just happend the first weekend after the 6.1 beta freeze.
>
> The full fix will require bigger changes to port our provider to use their
> new API.
>
> Nate Graham already gave a +1 to the exception on the plasma size
> (
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589#note_951996
> )
> As I am not subscribed to the i18n mailing list, please use "Reply All"
> rather than "Reply List".
>
> Thanks!
>
> -
> P.S. Please, excuse the double post on plasma-devel, I didn't set the
> right address for the i18n mailing list
>

Re: Fwd: String/Feature freeze exception request

[Freek de Kruijf]

Op maandag 27 mei 2024 23:02:02 CEST schreef Ismael Asensio:
> Hello dear devs and translation teams!
> 
> I'd like to request a string freeze exception to cherry-pick this MR into
> 6.1:
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589
> 
> The MR adds a new placeholder item (and therefore 3 new strings) to
> the weather applet, in case we fail to retrieve the forecast report due to
> server errors in the provider.
> 
> Otherwise, the applet will look broken, giving many users a suboptimal
> experience.
> 
> This just transpired now due to some recent changes in the US Weather
> Service provider (noaa), which may make it fail. It was a very bad timing
> that it just happend the first weekend after the 6.1 beta freeze.
> 
> The full fix will require bigger changes to port our provider to use their
> new API.
> 
> Nate Graham already gave a +1 to the exception on the plasma size
> (
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589#note_951
> 996 )
> As I am not subscribed to the i18n mailing list, please use "Reply All"
> rather than "Reply List".
> 
> Thanks!
> 
> -
> P.S. Please, excuse the double post on plasma-devel, I didn't set the right
> address for the i18n mailing list

No objections from the Dutch team.

-- 

vr.gr.

Freek de Kruijf
vertaler/coördinator van KDE

Re: Fwd: String/Feature freeze exception request

[Ismael Asensio]

The commit is now merged to the 6.1 branch.

https://invent.kde.org/plasma/kdeplasma-addons/-/commit/0da7655b42890d620a0012ffe0097cec24fc75f4

Thank you all! Bedankt, Дякую, gràcies!

El mar, 28 may 2024 a las 13:08, Josep M. Ferrer ()
escribió:

> El 27/5/24 a les 23:02, Ismael Asensio ha escrit:
>
> Hello dear devs and translation teams!
>
> I'd like to request a string freeze exception to cherry-pick this MR into
> 6.1:
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589
>
> The MR adds a new placeholder item (and therefore 3 new strings) to
> the weather applet, in case we fail to retrieve the forecast report due to
> server errors in the provider.
>
> Otherwise, the applet will look broken, giving many users a suboptimal
> experience.
>
> This just transpired now due to some recent changes in the US Weather
> Service provider (noaa), which may make it fail. It was a very bad timing
> that it just happend the first weekend after the 6.1 beta freeze.
>
> The full fix will require bigger changes to port our provider to use their
> new API.
>
> Nate Graham already gave a +1 to the exception on the plasma size
> (
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589#note_951996
> )
> As I am not subscribed to the i18n mailing list, please use "Reply All"
> rather than "Reply List".
>
> Thanks!
>
> -
> P.S. Please, excuse the double post on plasma-devel, I didn't set the
> right address for the i18n mailing list
>
> No problem from Catalan team.
>
> Thanks for solving this issue.
>
> Josep M. Ferrer
>

Re: Fwd: String/Feature freeze exception request

[Yuri Chornoivan]

вівторок, 28 травня 2024 р. 00:02:02 EEST Ismael Asensio написано:
> Hello dear devs and translation teams!
> 
> I'd like to request a string freeze exception to cherry-pick this MR into
> 6.1:
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589
> 
> The MR adds a new placeholder item (and therefore 3 new strings) to
> the weather applet, in case we fail to retrieve the forecast report due to
> server errors in the provider.
> 
> Otherwise, the applet will look broken, giving many users a suboptimal
> experience.
> 
> This just transpired now due to some recent changes in the US Weather
> Service provider (noaa), which may make it fail. It was a very bad timing
> that it just happend the first weekend after the 6.1 beta freeze.
> 
> The full fix will require bigger changes to port our provider to use their
> new API.
> 
> Nate Graham already gave a +1 to the exception on the plasma size
> (
> https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/589#note_951
> 996 )
> As I am not subscribed to the i18n mailing list, please use "Reply All"
> rather than "Reply List".
> 
> Thanks!
> 
> -
> P.S. Please, excuse the double post on plasma-devel, I didn't set the right
> address for the i18n mailing list


Hi,

No objections from Ukrainian team.

Best regards,
Yuri

Re: Plasma 6.1 announcement

[Akseli Lahtinen]

On Friday 24 May 2024 17:35:39 GMT+3 Paul Brown wrote:
> On Friday 24 May 2024 00:51:07 CEST Carl Schwan wrote:
> > Hi,
> > 
> > I won't be able to work on the Plasma 6.1 announcement. I am too exhausted
> > from the recent gear announcement and working on other KDE  stuffs and
> > also
> > I will also be traveling the weeks before the release, so even if I was
> > not
> > too exhausted, I can't really help.
> > 
> > It would be great if someone from the Plasma team could take care of
> > collecting all the new important changes from that release, write the
> > announcement text and put this into a web page (there is a bunch of
> > examples in the kde-org repository). I should be available to answer some
> > questions but not much more.
> > 
> > Cheers,
> > Carl
> 
> That's fine. Promo will grab the 6.0 web stuff and use it as a template. For
> the content, at least we have Nate's blog we can go throguh. If any dev
> would like to help out, that would be great, of course.
> 
> Cheers
> 
> Paul

Hi, one more thing to the list of content: We have now Remote Desktop
settings and people can use it, for example, from Windows PC's to connect to 
their Plasma PC.

https://invent.kde.org/plasma/krdp

(Sidenote, that settings image needs an update!)

Thanks,
Akseli

Re: Plasma 6.1 announcement

[Paul Brown]

On Friday 24 May 2024 00:51:07 CEST Carl Schwan wrote:
> Hi,
> 
> I won't be able to work on the Plasma 6.1 announcement. I am too exhausted
> from the recent gear announcement and working on other KDE  stuffs and also
> I will also be traveling the weeks before the release, so even if I was not
> too exhausted, I can't really help.
> 
> It would be great if someone from the Plasma team could take care of
> collecting all the new important changes from that release, write the
> announcement text and put this into a web page (there is a bunch of examples
> in the kde-org repository). I should be available to answer some questions
> but not much more.
> 
> Cheers,
> Carl

That's fine. Promo will grab the 6.0 web stuff and use it as a template. For 
the 
content, at least we have Nate's blog we can go throguh. If any dev would like 
to help out, that would be great, of course.

Cheers

Paul
-- 
Promotion & Communication

www: https://kde.org
Mastodon: https://floss.social/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde

Re: Plasma 6.0.5

[Jonathan Riddell]

Bluedevil now has 6.0.5.1 update, the old tar was missing some files
https://kde.org/info/plasma-6.0.5/

On Tue, 21 May 2024 at 19:14, Jonathan Riddell  wrote:
>
> Plasma 6.0.5 is available for packaging and shipping
> https://kde.org/announcements/plasma/6/6.0.5/

Re: KDE Review Request: KRDP

[Akseli Lahtinen]

Hi, the review period is over for KRDP and we'd like to officially include 
KRDP in 6.1. 

Here's the review request issue https://invent.kde.org/plasma/krdp/-/issues/17

Thanks!
- Akseli Lahtinen

On Friday 3 May 2024 21:07:55 GMT+3 Akseli Lahtinen wrote:
> Hi!
> 
> Arjen Hiemstra and me have been working on a RDP server called KRDP.
> This allows remote desktop connections over RDP protocol. Arjen
> did the heavy lifting with the streaming side and the actual protocol side.
> 
> https://invent.kde.org/plasma/krdp
> 
> I have done the KCM side of things, which is a system settings menu where
> one can toggle the server on and off and change various other settings like
> quality of the stream and such.
> 
> You can test it with for example Remmina client, more info here:
> https://invent.kde.org/plasma/krdp#known-working-and-not-working-clients
> 
> Here is the review request issue:
> https://invent.kde.org/plasma/krdp/-/issues/17
> 
> I'd like to get some reviews in and so on so we can get this in good shape.
> :)
> 
> Thank you!
> - Akseli Lahtinen
> 
> PS. My first review request, do tell me if I missed something!
> I followed this documentation for it
> https://develop.kde.org/docs/getting-started/add-project/#kde-review

Re: CI moved to Qt 6.7 for Linux builds

[Kai Uwe Broulik]

Hi,

This doesn't look terribly active to me / something receiving much in 
the way of release activity?


Plasma 5.27.11 was released two months ago, so that’s not that far ago. 
And I think I haven’t merged most of my cherry-picks because of failing 
pipelines because of appstream.


Cheers
Kai Uwe

Re: CI moved to Qt 6.7 for Linux builds

[Ben Cooksley]

On Wed, May 8, 2024 at 11:22 PM Kai Uwe Broulik 
wrote:

> Hi,
>

HI Kai,


>
> (only posting to plasma-devel only below is about Plasma)
>
>  > i'd also like to schedule removing CI support for [...] Plasma/5.27
>
> Plasma 5.27 is our LTS release and we’ve just had Kubuntu 24.04 ship
> with it. I’m also aware of at least one other major deployment that’s
> also on 5.27 for the forseeable time.
>
> I think we need to keep this around for at least another year, maybe
> longer, so we can still backport important fixes and do a few more 5.27
> releases. One year of support isn’t exactly “LTS” imho particularly with
> a major version jump. Think of how long Qt 5.15 has been around and
> still will be in the industry.
>

The problem I see with this is that if you head to
https://invent.kde.org/teams/ci-artifacts/suse-qt5.15/-/packages? you will
find that the Plasma packages were last rebuilt 5-6 months ago by and large.

This doesn't look terribly active to me / something receiving much in the
way of release activity?


>
> Cheers
> Kai Uwe
>
> PS: Though we should probably disable this stupid appstream test on 5.27
>

Yes, that test drives many of us crazy.

Cheers,
Ben

Re: CI moved to Qt 6.7 for Linux builds

[Kai Uwe Broulik]

Hi,

(only posting to plasma-devel only below is about Plasma)

> i'd also like to schedule removing CI support for [...] Plasma/5.27

Plasma 5.27 is our LTS release and we’ve just had Kubuntu 24.04 ship 
with it. I’m also aware of at least one other major deployment that’s 
also on 5.27 for the forseeable time.


I think we need to keep this around for at least another year, maybe 
longer, so we can still backport important fixes and do a few more 5.27 
releases. One year of support isn’t exactly “LTS” imho particularly with 
a major version jump. Think of how long Qt 5.15 has been around and 
still will be in the industry.


Cheers
Kai Uwe

PS: Though we should probably disable this stupid appstream test on 5.27

Re: about Plasmoid KICKOFF

[Justin Zobel]

This mailing list is for development of KDE Plasma. For support see 
https://kde.org/support/


On 19/4/24 14:55, N Nekto wrote:
Hello dear dude! Tell me how to remove letter numbering in the Kikof 
widget? I want it to be like before: namely, there was no letter 
numbering in the lists of installed applications!

Re: CI moved to Qt 6.7 for Linux builds

[Michael Reeves]

kdiff3 will make one or two releases but needs only frameworks. This support 
will end in three months. master is qt6 only now.

Apr 20, 2024 8:35:40 PM Ben Cooksley :

> Hi all,
> 
> I have just flipped the switch that has moved the CI system over to using Qt 
> 6.7 for Linux builds on our SUSE images.
> 
> Should you see any issues with builds failing as a result of packages being 
> missing in the registry then please submit a merge request to 
> sysadmin/ci-management to ensure that build dependency is added to our seed 
> jobs.
> 
> I'll leave the Qt 6.6 package registry and container images in place for 
> another week or so then will schedule them for removal.
> 
> As part of this I have also updated the list of projects with Qt 6 only 
> master branches. Any residual Qt 5 build artifacts the CI system was holding 
> for those projects have now been purged, which may impact downstream projects 
> that depend on those projects that are still on Qt 5.
> 
> On an adjacent note, i'd also like to schedule removing CI support for 
> release/23.08 and Plasma/5.27 builds (by purging all their binaries we 
> currently hold) for the Qt 5.15 series. 
> 
> While checking however I note that several projects still have activity on 
> those branches. Can we please confirm whether any further releases are 
> expected, as i'd prefer to remove anything that isn't being properly 
> maintained anymore.
> 
> Thanks,
> Ben


signature.asc
Description: PGP signature

Re: Improving Tiling Window Support in KDE Plasma

[Aakarsh MJ]

> The script could keep a copy of every window-tile association and
> reassign everything on every desktop switch but would be
> kinda error prone and have too much complexity on javascript side.
> What really needsto happen here is an internal support of tiles
> per-visrtualdesktop on kwin side (ideally the cartesian product of
> screen,virtualdesktop and activities)  but it will be a significant
refactor.

I see, can you link the files that need the refactor?

What I can suggest is I can take a look at those files and prepare a design
document incorporating the changes that the community can take a look at
provided the community is onboard with the refactor although It will take
some time to prepare the document depending on the complexity and size of
the issue.

Sincerely,
Aakarsh MJ



On Mon, Apr 15, 2024 at 1:18 PM Marco Martin  wrote:

> On Thu, Mar 28, 2024 at 1:43 PM Aakarsh MJ  wrote:
> > > there are already 3rd party scripts that attempt to do that, like one
> > > called polonium https://github.com/zeroxoneafour/polonium tough is
> > > still quite buggy
> >
> > I have checked polonium before, unfortunately for me it was way too
> buggy to use it on a daily basis.
>
> yeah, for now i', not sure polonium "can" be much bettergiven the
> underlying features.
> A significant thing missing that i seen is virtual desktops support,
> as tiles are at the moment per-screen and not (yet)
> per-virtualdesktop, so even just switching desktop it kinda breaks the
> layout.
> The script could keep a copy of every window-tile association and
> reassign everything on every desktop switch but would be
> kinda error prone and have too much complexity on javascript side.
>
> What really needsto happen here is an internal support of tiles
> per-visrtualdesktop on kwin side (ideally the cartesian product of
> screen,virtualdesktop and activities)  but it will be a significant
> refactor
>
>
> --
> Marco Martin
>

Re: Improving Tiling Window Support in KDE Plasma

[Marco Martin]

On Thu, Mar 28, 2024 at 1:43 PM Aakarsh MJ  wrote:
> > there are already 3rd party scripts that attempt to do that, like one
> > called polonium https://github.com/zeroxoneafour/polonium tough is
> > still quite buggy
>
> I have checked polonium before, unfortunately for me it was way too buggy to 
> use it on a daily basis.

yeah, for now i', not sure polonium "can" be much bettergiven the
underlying features.
A significant thing missing that i seen is virtual desktops support,
as tiles are at the moment per-screen and not (yet)
per-virtualdesktop, so even just switching desktop it kinda breaks the
layout.
The script could keep a copy of every window-tile association and
reassign everything on every desktop switch but would be
kinda error prone and have too much complexity on javascript side.

What really needsto happen here is an internal support of tiles
per-visrtualdesktop on kwin side (ideally the cartesian product of
screen,virtualdesktop and activities)  but it will be a significant refactor


-- 
Marco Martin

Re: Meeting on store content distribution after Monday's Plasma meeting

[Nate Graham]

Quick update:


On 3/25/24 10:59, David Edmundson wrote:

Meeting was quite productive, we had some overall discussion and have
some action items as follows:


Short term:

 Add key in knsrc files to let content get marked as dangerous so


David did this in 
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/309




 Review all ksnrc files to set the flag.
This will be done as two indepdendent teams and see if we ge the same
result. Then we land merge-requests.


David and I have done this across many MRs. Two are still unmerged, to 
be merged soon.




 Change the text in KNS to reflect this key. Nate will do a MR when
the key is in.
We are past frameworks freeze for 6.1, this will be frameworks 6.2.
This also allows ksnrc files to get releases.


I've submitted 
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/310 for this.




 Change our default sorting in KNS to most downloaded or highest
rated (https://invent.kde.org/frameworks/knewstuff/-/merge_requests/308)


Ismael did this in 
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/308




- Propose deleting KNS browsing from discover, maybe updating too?

 Extend the Global Themes KCM's "what do you want to apply?" dialog
to be more warny about dangerous stuff, like widgets
Target is Plasma 6.1. We can uplift the UI from krunner plugins. Maybe
making that even more generic.

 Remove the "Use" button from installed Global Themes grid items in
the KNS dialog (this bypasses the dialog in the KCM)

 Change the name "Global Themes" to include the word "plugin,"
"extension," "mod," or something else to make people understand that
it's not a benign connection of assets
Target is Plasma 6.1



Mid term:

 Remove QML code from Global Themes. Lockscreen and alike.


Marco is in the process of doing this across various MRs.



 If zero ratings, show "no ratings" rather than half (needs
Pling/OCS changes)

 Revisit how ratings are done on the Pling side

 Could pling ratings be changed thumbs up or thumbs down?

 Find out with Pling if review before being visible is feasible



These will appear as merge requests for any further discussion.

David



Everything else here is TBD; feel free to help out if this sparks 
anyone's fancy!


Nate

Re: Plasma Sprint 2024

[Nate Graham]

I'm most likely not going to be able to attend this year's Plasma sprint 
unfortunately, but choosing a venue that's an hour by car away from an 
airport strikes me as inviting logistical challenges. It would also be 
nice if we can get the venue for free. :) If it's to be in Spain, how 
about hitting up the Slimbook folks again?


Nate



On 4/2/24 07:29, Jonathan Riddell wrote:

I also enquired about iSlow Coliving in Galicia (North West Spain).
This is about 1 hour drive from A Coruna and Vigo airports so it would
need a car hired for shuttle runs.  It's a very pleasant large house
with a room for computer work and a big kitchen and bedroom with
private bathrooms.  They can host 12 people (13 with a shared bed)
throughout June but we'd need to book soon.

June 2024 - iSlow Rooms:
* 2 triple rooms - 40€/person/night (6 people)
* 1 double twins  - 50€ /person/night  (2 people)
* 1 double big bed - 1 person (or two if a couple) 63€/1 person/night
(85€/night/ 2 people).
TOTAL: 9 people at iSlow - 2821 euros

September 2024 - iSlow Rooms:
Same as in June + 1 single - 57€/person/night - 1 person
TOTAL: 10 people at iSlow - 3220 euros

3 additional people staying nearby in a flat in Laxe or rural house in
the village - 50€ per person per night single room, shared bathroom.
TOTAL: 3 people - 55/person/night.

Re: Plasma Sprint 2024

[Jonathan Riddell]

I also enquired about iSlow Coliving in Galicia (North West Spain).
This is about 1 hour drive from A Coruna and Vigo airports so it would
need a car hired for shuttle runs.  It's a very pleasant large house
with a room for computer work and a big kitchen and bedroom with
private bathrooms.  They can host 12 people (13 with a shared bed)
throughout June but we'd need to book soon.

June 2024 - iSlow Rooms:
* 2 triple rooms - 40€/person/night (6 people)
* 1 double twins  - 50€ /person/night  (2 people)
* 1 double big bed - 1 person (or two if a couple) 63€/1 person/night
(85€/night/ 2 people).
TOTAL: 9 people at iSlow - 2821 euros

September 2024 - iSlow Rooms:
Same as in June + 1 single - 57€/person/night - 1 person
TOTAL: 10 people at iSlow - 3220 euros

3 additional people staying nearby in a flat in Laxe or rural house in
the village - 50€ per person per night single room, shared bathroom.
TOTAL: 3 people - 55/person/night.

Re: Improving Tiling Window Support in KDE Plasma

[Aakarsh MJ]

> I suggest to move this discussion to the mailing list plasma-devel@kde.org
I have added the ML as recipient.

> So, the tiling system is aimed to be very basic, and more akin Windows
> "Fancy zones" than a complete tiling window manager (we are thinking
> about renaming the effect to be more clear)

I see, that would definitely avoid the confusion.

> That said, I still want it to be possible to build a full tiling
> window manager on top of it, and for that, using the javascript
> scripting bindings.
> there are already 3rd party scripts that attempt to do that, like one
> called polonium https://github.com/zeroxoneafour/polonium tough is
> still quite buggy

I have checked polonium before, unfortunately for me it was way too buggy
to use it on a daily basis.

> because the base system and api that exposes trough
> JS is still not complete enough (the per-desktop layout for instance
> is something really broken because it should really be managed in the
> base system)

If it's okay I'd like to contribute more to that front. If you can go into
detail what needs to be implemented, I'll be happy to look into that :)

Sincerely,
Aakarsh MJ

On Wed, Mar 27, 2024 at 2:52 PM Marco Martin  wrote:

> Hi,
> sorry if you didn't get any answer on the matrix channel, we should
> definitely improve on that.
> So, the tiling system is aimed to be very basic, and more akin Windows
> "Fancy zones" than a complete tiling window manager (we are thinking
> about renaming the effect to be more clear)
>
> That said, i still want it to be possible to build a full tiling
> window manager on top of it, and for that, using the javascript
> scripting bindings.
> there are already 3rd party scripts that attempt to do that, like one
> called polonium https://github.com/zeroxoneafour/polonium tough is
> still quite buggy because the base system and api that exposes trough
> JS is still not complete enough (the per-desktop layout for instance
> is something really broken because it should really be managed in the
> base system)
>
> I suggest to move this discussion to the mailing list plasma-devel@kde.org
>
>
> On Wed, Mar 27, 2024 at 7:58 AM Aakarsh MJ  wrote:
> >
> > Hi Marco,
> > My name is Aakarsh MJ, I am a kde contributor from India contributing
> mostly to Merkuro and KDE Eco. Last year, I did GSoC with KDE working on
> the merkuro(formerly Kalendar) mail integrations and Season of KDE this
> year working on integrating remote measurement lab into okular's pipeline.
> I was looking to contribute to plasma and on the matrix channel I was told
> to start with something that I'd like to see improved.
> >
> > I am sorry if this is not the right place to ask this. I had tried
> asking this on the matrix channel but I didn't get any response and since
> you contributed this feature I thought It would be best if I contact you
> regarding this, I hope it is okay. So the new tiling system is something I
> really like. It has definitely far improved my workflow than before but I
> feel it can do with some more improvements. I am not sure how much of it is
> currently possible but I'll list some of them so that I can get an input if
> it's possible to do and if it is, then I can work on it.
> >
> > 1. Auto tiling on changing the layout.
> > 2. Supporting separate tiling layouts for different virtual desktops.
> > 3. Moving windows to different positions inside the layout through
> key combinations.
> > 4. Possibility of defining padding for Single window configurations.
> >
> > I understand it's not meant to be window tiling replacement from what I
> read from Nate's blog but if any of these are possible to achieve and okay
> with the current goals I'd like to work on it.
> >
> > Additionally, I have built Plasma 6 from source and have helped a tiny
> bit in bug triaging before.
> >
> > Thanks for your time and consideration.
> >
> > Sincerely,
> > Aakarsh MJ
>
> --
> Marco Martin
>

Re: kwin 6.0.3 respin

[Justin Zobel]

On 27/3/24 10:25, Vlad Zahorodnii wrote:

Hello,

Is it possible to respin kwin 6.0.3 so it includes the following two 
commits


- 
https://invent.kde.org/plasma/kwin/-/commit/74060343a0286bf9d8054cbe67cb019d07455db3
- 
https://invent.kde.org/plasma/kwin/-/commit/13e31baca828c912152b8a201224e9f04ec9bea1


We originally wanted to get them in 6.0.3 but due to unfortunate 
circumstances, those two slipped through and we've noticed that they 
haven't gotten to 6.0.3 tars only now.


These two patches should help to address a kwin crash that happens 
when running kwin with tiling scripts (like polonium), which affects 
quite a few people.


Regards,
Vlad

I'd like to see this done as a 6.0.3.1 instead as many distros have 
already started builds and are using the existing 6.0.3 tarball checksums.

Re: Meeting on store content distribution after Monday's Plasma meeting

[David Edmundson]

Meeting was quite productive, we had some overall discussion and have
some action items as follows:


Short term:

Add key in knsrc files to let content get marked as dangerous so
that we can show a different warning in the dialog  (d_ed)
This will be done immediately and backported

Review all ksnrc files to set the flag.
This will be done as two indepdendent teams and see if we ge the same
result. Then we land merge-requests.

Change the text in KNS to reflect this key. Nate will do a MR when
the key is in.
We are past frameworks freeze for 6.1, this will be frameworks 6.2.
This also allows ksnrc files to get releases.

Change our default sorting in KNS to most downloaded or highest
rated (https://invent.kde.org/frameworks/knewstuff/-/merge_requests/308)
- Propose deleting KNS browsing from discover, maybe updating too?

Extend the Global Themes KCM's "what do you want to apply?" dialog
to be more warny about dangerous stuff, like widgets
Target is Plasma 6.1. We can uplift the UI from krunner plugins. Maybe
making that even more generic.

Remove the "Use" button from installed Global Themes grid items in
the KNS dialog (this bypasses the dialog in the KCM)

Change the name "Global Themes" to include the word "plugin,"
"extension," "mod," or something else to make people understand that
it's not a benign connection of assets
Target is Plasma 6.1



Mid term:

Remove QML code from Global Themes. Lockscreen and alike.

If zero ratings, show "no ratings" rather than half (needs
Pling/OCS changes)

Revisit how ratings are done on the Pling side

Could pling ratings be changed thumbs up or thumbs down?

Find out with Pling if review before being visible is feasible



These will appear as merge requests for any further discussion.

David

Re: Meeting on store content distribution after Monday's Plasma meeting

[Carl Schwan]

On Thursday, March 21, 2024 3:46:47 PM CET Nate Graham wrote:
> 
> For the purpose of stimulating ideas and discussion in the meeting, let
> me note down a few complementary routes that I could see us going down:
> 
> # Moderation
> have trusted experts filter out dangerous or broken content so it
> doesn't get distributed to unsuspecting users in the first place.
> Example: the distro packaging model.
> 
> This would have to be done on pling.com. It would look like a
> fundamentally different upload process involving new content being
> checked automatically against templates of allowed files and folder
> structures, and humans manually reviewing and verifying everything.
> **Feasible now, but doesn't scale well, or at all (as evidenced by the
> lack of anyone volunteering to do it during the time it's been known
> that this was an issue)**

It's a bit of a chicken and egg problem. Currently there is no way to review 
new package being uploaded before they are published, so no one can do it even 
if they wanted. Another issue is that the package is directly uploaded by the 
user, instead of doing it a bit like distros and requiring to provide an url + 
checksum which would at least ensure that the content in store is the same as 
in the linked repository.

Flathub has a manual review process to submit a new package and they are 
currently improving it so that updating the permissions also require another 
manual review (in addition to be sandboxed). I think not even from a security 
point of view, but having some quality requirement before allowing users to 
upload a package would be a good thing.

This whole discussion make me want to restart my work on an alternative store 
implementation ;)

> # Restriction
> Limit the damage that dangerous or broken content on the user's system
> can cause. Here are some examples of what could be done on the KDE side:
> 
> 1. Only allow the executable data engine to be run by widgets, not any
> other kind of QML code (e.g. logout greeters and OSDs). **Probably
> feasible**

I'm not sure it is feasible to exclude a specific data engine for non-widgets 
QML but it is also not the solution for this particular problem. If I 
understood correctly, the script was executed in this particular case by a 
widget. One thing that make plasma widgets powerful is the capability to run 
scripts, so instead of disallowing executing scripts completely, I think a 
plasmoid should declare in their metadata the script they can execute (with a 
list of regex) and if the widget tries to execute a script outside of the 
things they are allowed to, the script is simply not executed and a warning 
could be displayed. This also makes it easier for a manual review to know what 
type of script the widget will execute.

We should also do the same for HTTP request.

> 2. Because it's so security-sensitive, prevent Plasma from loading
> custom lockscreen QML code in Global Themes (as we did for custom
> KRunner QML in Plasma 5 times). **Feasible but would disable themed
> lockscreens until we roll out a new no-code theming engine**

We already have a no-code theming engine for the lockscreen which is the 
plasma style. The more advanced QML style is only really helpful when doing 
custom layouts (e.g. plasma mobile) which a no-code theming engine won't be 
able to do. The custom layout thing is only really useful for plasma mobile 
and custom shells and the idea from this MR to move this to the shell package 
makes sense to me.
https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/482

> 3. Run all 3rd-party widgets in a Flatpak-like sandboxed process and
> make them use portals to interact with various parts the system **Maybe
> feasible and would only break some widgets?**

This is unfortunately from a performance point of view not possible. Maybe we 
could run instead only run the Script DataEngine in a sandboxed container? So 
instead of runing QProcess directly, do more fancy stuff with bubblewrap.

> 3. Change the `ConfigFile()` feature of Plasma scripting so that it's
> only able to touch an allow-listed set of config files in Plasma and
> maybe other KDE software, not arbitrary ones on the system. **Maybe
> feasible and would only break some Global Themes**

I don't think this would make a difference as soon as the user is able to 
inject a QML file it's game over.

> 4. Remove or disable the executable data engine and force widgets to use
> Plasma and KWin scripting APIs, or else prompt for confirmation every
> time it's used. **Probably unfeasible as it would break most 3rd-party
> widgets and/or be super annoying to users**
>
> 
> 
> # Segregation
> This would also be done on the KDE side and look like any of these:
> 
> 1. Show a much more scary warning for content that can run arbitrary
> code, such as QML Widgets and Dolphin servicemenu entries. **Feasible now**

We also need to keep in mind that saying to the user: "don't use it, it's 
dangerous" while also keeping the feature

Re: feature freeze exception

[David Redondo]

Am Donnerstag, 21. März 2024, 16:51:00 CET schrieb Mike Noe:
> Hello fellow developers!
> 
> I'd like to request a feature freeze exception for 
> https://invent.kde.org/plasma/print-manager/-/merge_requests/116. I feel 
> that this is important to get into the next release because we've had a 
> couple of reports of users getting stuck when their printer is not 
> auto-discovered and adding it manually is not available, creating 
> confusion with the current System Settings. There are, however, 2 
> work-arounds, one involving the CUPS web interface and the other using 
> the older version of the "add printer" wizard.
> 
> As I am not subscribed to this mailing list, please use "Reply All" 
> rather than "Reply List".
> Thanks!
> 
> Mike
> 
> 
We are right now not in a feature freeze period.
If your patch fixes a bug, it's a bug fix :)
However it introduces new strings which is problematic.

David

Re: Meeting on store content distribution after Monday's Plasma meeting

[Nate Graham]

On 3/21/24 04:50, David Edmundson wrote:

The topic of store content has come up repeatedly throughout last
year. It's clear what we're showing to users now doesn't meet modern
expectations and our messaging is not the clearest. It's in the
spotlight currently, we can use that energy to do something
productive.

Lets discuss this in a video call on Monday after the normal Plasma
meeting (which is at 4pm CET) and see what initial steps we want to
take for 6.1.

David



Good idea.

For background information, what happened was that a user used the "Get 
New [thing]" integration for pling.com in System Setting to download a 
global theme that they didn't reasonably expect would run executable 
code, and it did via the executable data engine in a bundled widget, and 
it broke in the worst possible way.



For the purpose of stimulating ideas and discussion in the meeting, let 
me note down a few complementary routes that I could see us going down:




# Moderation
have trusted experts filter out dangerous or broken content so it 
doesn't get distributed to unsuspecting users in the first place. 
Example: the distro packaging model.


This would have to be done on pling.com. It would look like a 
fundamentally different upload process involving new content being 
checked automatically against templates of allowed files and folder 
structures, and humans manually reviewing and verifying everything. 
**Feasible now, but doesn't scale well, or at all (as evidenced by the 
lack of anyone volunteering to do it during the time it's been known 
that this was an issue)**




# Restriction
Limit the damage that dangerous or broken content on the user's system 
can cause. Here are some examples of what could be done on the KDE side:


1. Only allow the executable data engine to be run by widgets, not any 
other kind of QML code (e.g. logout greeters and OSDs). **Probably 
feasible**
2. Because it's so security-sensitive, prevent Plasma from loading 
custom lockscreen QML code in Global Themes (as we did for custom 
KRunner QML in Plasma 5 times). **Feasible but would disable themed 
lockscreens until we roll out a new no-code theming engine**
3. Run all 3rd-party widgets in a Flatpak-like sandboxed process and 
make them use portals to interact with various parts the system **Maybe 
feasible and would only break some widgets?**
3. Change the `ConfigFile()` feature of Plasma scripting so that it's 
only able to touch an allow-listed set of config files in Plasma and 
maybe other KDE software, not arbitrary ones on the system. **Maybe 
feasible and would only break some Global Themes**
4. Remove or disable the executable data engine and force widgets to use 
Plasma and KWin scripting APIs, or else prompt for confirmation every 
time it's used. **Probably unfeasible as it would break most 3rd-party 
widgets and/or be super annoying to users**




# Segregation
This would also be done on the KDE side and look like any of these:

1. Show a much more scary warning for content that can run arbitrary 
code, such as QML Widgets and Dolphin servicemenu entries. **Feasible now**

2. Show a less scary warning for content that can't. **Feasible now**
3. When Global Themes include widgets, notify the user about this and 
show the "can run arbitrary code" scary warning. Prompt them to either 
acknowledge the potential danger and explicitly proceed, or filter out 
the widgets. **Feasible now**




# Remove unneeded themability
An example is splash screens, 99.99% of which could be a static or 
animated image, or maybe one overlaid on top of a fixed background. If 
we let the user choose their own image, then we could remove splash 
screen themability entirely. We could also just leave SDDM visible until 
Plasma is ready and do an animated transition there, deleting the 
concept of the Plasma splash screen.




Nate

Re: Meeting on store content distribution after Monday's Plasma meeting

[Justin Zobel]

On 21/3/24 21:20, David Edmundson wrote:

The topic of store content has come up repeatedly throughout last
year. It's clear what we're showing to users now doesn't meet modern
expectations and our messaging is not the clearest. It's in the
spotlight currently, we can use that energy to do something
productive.

Lets discuss this in a video call on Monday after the normal Plasma
meeting (which is at 4pm CET) and see what initial steps we want to
take for 6.1.

David
I won't be around at this time (1:30am for me). If someone can please 
take notes that would be appreciated.

Re: Plasm 6.1 Kickoff Meeting notes

[Justin Zobel]

On 14/3/24 09:19, Nate Graham wrote:

On 3/11/24 10:31, Nicolas Fella wrote:

## 6.1 release planning

Idea: Keep the megarelese?


I think there's something to it. Releasing everything at once was good 
for branding and user perception, and it seems for distros too.


One thing I'd like to change is to further unify the release 
schedules. Plasma's fibonacci bugfix releases have ensured we didn't 
need to tell distros to urgently patch a ton of things because the 
next bugfix release was less than a week away, but Frameworks and 
Gear's longer release cycles didn't have that luxury. I'd like to see 
that kind of bugfix schedule at least extended to Gear.


Nate
Agreed, the Fibonacci bug fix release schedule does work well, it is 
fast initially to capture those bugs that got missed in the initial 
release and eases off towards the next feature release. Also good for 
the distros that like to wait for the .1 or .2 release to make sure they 
get a nice clean release.

Re: Plasm 6.1 Kickoff Meeting notes

[Carl Schwan]

On Wednesday, March 13, 2024 11:49:45 PM CET Nate Graham wrote:
> On 3/11/24 10:31, Nicolas Fella wrote:
> > ## 6.1 release planning
> > 
> > Idea: Keep the megarelese?
> 
> I think there's something to it. Releasing everything at once was good
> for branding and user perception, and it seems for distros too.

Agree and after talking with some journalists they told me it is also easier 
for them to write an article about the megarelease as it contains more content 
and it's less frequent. It's also less work for me and the promo team to work 
on one announcement every 4 months than having alterning a gear and a plasma 
release every 2 months.

> 
> One thing I'd like to change is to further unify the release schedules.
> Plasma's fibonacci bugfix releases have ensured we didn't need to tell
> distros to urgently patch a ton of things because the next bugfix
> release was less than a week away, but Frameworks and Gear's longer
> release cycles didn't have that luxury. I'd like to see that kind of
> bugfix schedule at least extended to Gear.

+1 the first minor release for gear is today and we already had two bugfixes 
release for Plasma.

Carl

> Nate

Re: Plasm 6.1 Kickoff Meeting notes

[Nate Graham]

On 3/11/24 10:31, Nicolas Fella wrote:

## 6.1 release planning

Idea: Keep the megarelese?


I think there's something to it. Releasing everything at once was good 
for branding and user perception, and it seems for distros too.


One thing I'd like to change is to further unify the release schedules. 
Plasma's fibonacci bugfix releases have ensured we didn't need to tell 
distros to urgently patch a ton of things because the next bugfix 
release was less than a week away, but Frameworks and Gear's longer 
release cycles didn't have that luxury. I'd like to see that kind of 
bugfix schedule at least extended to Gear.


Nate

Re: Plasm 6.1 Kickoff Meeting notes

[Jakob Petsovits]

On Tue, Mar 12, 2024, at 9:57 PM, Neal Gompa wrote:
> On Mon, Mar 11, 2024 at 9:32 AM Nicolas Fella  wrote:
>> Tentative idea:
>>   - 6.1 in June
>>   - Two Betas
>>   - Slightly extend support window for the release to avoid gap between
>> 6.1 ending and distros picking up 6.2
>>   - Needs coordination with distros before finalizing
>>
>
> I know we've discussed this in a few avenues before, but I'll continue
> to suggest January/July to have the beta releases and February/August
> for the final releases. This lines up with Fedora, Kubuntu, and
> openSUSE cutoffs in their release schedules.
>
> (And while I think we shouldn't do Plasma LTS releases, since we are,
> I think those should be done in the "spring" Plasma releases to align
> with Kubuntu LTS and openSUSE Leap schedules.)
>

If the Plasma team is set on kicking off the 6.x cycle with a June release, we 
could theoretically keep up the 4-month cycle for two more releases, October 
and (early to mid rather than late) February. Then switch to the 6-month cycle 
that's been previously considered.

Knowing that the October release will miss most users that aren't on a rolling 
distro, and 6.1 for semi-annual upgraders will be missing out on two months of 
development that we could get from an August release.

- Jakob

Re: Plasm 6.1 Kickoff Meeting notes

[Neal Gompa]

On Mon, Mar 11, 2024 at 9:32 AM Nicolas Fella  wrote:
>
> # Plasma 6.1 kickoff meeting notes
>

Hey sorry folks, I wasn't able to make it because I'm in California
this week and that resulted in it being too early for me.

> ## 6.0 retrospective
>
> Generally well received# Plasma 6.1 kickoff meeting notes
>
> ## 6.0 retrospective
>
> Generally well received
>
> Problems:
> - Neon's rollout was/still is bumpy. Needs retrospective from Neon
> developers on what happend
> - Nvidia:
>  - Missing configuration to enable modesetting (downstream issue)

At least in RPM Fusion (for Fedora), the driver package patches the
defaults to enable modesetting by default:
http://pkgs.rpmfusion.org/cgit/nonfree/nvidia-kmod.git/tree/make_modeset_default.patch

Maybe this needs to be recommended to distributors that offer the NVIDIA driver.

>  - Missing implicit sync makes XWayland glitchy (upstream issue).
> Potentially backportable patches exist
>  - Resume from suspend broken. Some kernel-level thing exists
> (NVreg_PreserveVideoMemoryAllocations), needs research/documentation
>
> ## 6.1 release planning
>
> Idea: Keep the megarelese? No strong benefit, unless there was a unified
> LTS release
>

The MegaRelease has been incredibly valuable from the Fedora
perspective because it gives us a collection of things that we can
reasonably expect to qualify and coordinate with upstream on. I would
personally like to see this continue for feature releases.

> Goals for the release planning:
>   - Keep time to next feature release short to allow for gaps in
> (Wayland) feature set to close quickly
>   - Align with fall/October releases of distros
>   - More extensive beta releases
>
> Tentative idea:
>   - 6.1 in June
>   - Two Betas
>   - Slightly extend support window for the release to avoid gap between
> 6.1 ending and distros picking up 6.2
>   - Needs coordination with distros before finalizing
>

I know we've discussed this in a few avenues before, but I'll continue
to suggest January/July to have the beta releases and February/August
for the final releases. This lines up with Fedora, Kubuntu, and
openSUSE cutoffs in their release schedules.

(And while I think we shouldn't do Plasma LTS releases, since we are,
I think those should be done in the "spring" Plasma releases to align
with Kubuntu LTS and openSUSE Leap schedules.)

> Dependencies (business as usual):
>   - Qt 6.7
>   - Frameworks as of Beta date
>
> Feature/work item ideas:
>   - David R: Emulated Input integration
>   - Marco: Work on tiling features, folderview refactoring
>   - Nico: Wayland a11y and graphics tablet work, QML tooling
>   - Kai: New Fonts KCM/tools
>   - Vlad: Work on Rendering in KWin
>   - Jakob: Mouse gestures, per-monitor brightness
>   - Niccolo: Floating dialogs, icons, 2D gestures
>

This is all very exciting stuff! I think Xaver mentioned that he's
looking at getting the xdg-color-management protocol implemented, and
David E had talked to me about session management stuff. Are those
still in the cards for 6.1?

> # Sprint
>
> We want a sprint sometime soon. There's a megasprint planned for April,
> avoid doing something too close to it to avoid travel overload.
>
> Summer might be a better time.
>
> Needs someone to volounteer organizing
>

Thanks for the minutes on this meeting. :)



--
真実はいつも一つ！/ Always, there's only one truth!

Re: Plasma 5.27.11

[Jonathan Riddell]

An update to plasma-sdk fixes compilation for duplicate translations
http://download.kde.org/stable/plasma/5.27.11/plasma-sdk-5.27.11.1.tar.xz
sha256: 90a2a18b699a374362f870b22685d4ed3d5e00fe7fa27b768fd2e626361e0744

Re: Plasma 6.0.1

[Jonathan Riddell]

Three respins to fix incorrect version dependencies

23ca96601cc9bff00434f7fbfe3901fbcb92362d1751a31c08520fb4c1124610
breeze-gtk-6.0.1.1.tar.xz
5e4fde9c7b55e24c0ae229cf4ab72ddf88359ef7b0bd2ae715bb87e1e0f1f782
breeze-plymouth-6.0.1.1.tar.xz
1902f3949052ff1ab5da79c6309586f3e11a29c7c04a044f73b3f6ac98251c4a
kpipewire-6.0.1.1.tar.xz

Re: Plasma 6.0.1

[Fabian Vogt]

Hi,

Am Mittwoch, 6. März 2024, 00:38:54 CET schrieb Jonathan Riddell:
> Plasma 6.0.1 is out now for packaging and distributing
> https://kde.org/announcements/plasma/6.0.1/

URL is broken, it's https://kde.org/announcements/plasma/6/6.0.1/.

Also, kpipewire fails to build because there's a syntax error in the version
bump. Heiko fixed that in
https://invent.kde.org/plasma/kpipewire/-/commit/df052bfa3c66d24109f40f18266ee057d1838b9b

How can that even happen? Version bumps should be scripted and ideally the CI
should run before tags are pushed.

Cheers,
Fabian

Re: Plasma 6.0.0 tars

[Jonathan Riddell]

respin of plasma-nm is up
http://embra.edinburghlinux.co.uk/~jr/tmp/plasma-nm-6.0.0-changes_report.html

   http://download.kde.org/stable/plasma/6.0.0/plasma-nm-6.0.0.tar.xz";>plasma-nm-6.0.0

   1.1MB
-
  
5f238f2c2c00f94c62c19fa958fe7f23fceb835f761422f610492675569b7ae3
+
  
52cf96738ceeafce65f183a3457325aeb5b1f18a4336ceede5a226556e6e9eb4



On Fri, 23 Feb 2024 at 20:17, Jonathan Riddell  wrote:

> plasma-workspace got a respin
>http://download.kde.org/stable/plasma/6.0.0/plasma-workspace-6.0.0.tar.xz";>plasma-workspace-6.0.0
>
>19MB
> -
>   
> b1c32a3bc33168559626f6a398c31dbc2023ae2550dbe9db1d0e20549050f0b4
> +
>   
> 47dd87b4c0e09c1bcb34162b7aae3e5a3b9a4aaba1b9fed0f4d681bb3f9febba
>
>
> http://embra.edinburghlinux.co.uk/~jr/tmp/plasma-workspace-6.0.0-changes_report.html
>
> git commit
>
> 69fca2e696633570cdb248ab33d13103fc54eaad
>
> Jonathan
>
>

Re: Plasma 6.0.0 tars

[Jonathan Riddell]

plasma-workspace got a respin
   http://download.kde.org/stable/plasma/6.0.0/plasma-workspace-6.0.0.tar.xz";>plasma-workspace-6.0.0

   19MB
-
  
b1c32a3bc33168559626f6a398c31dbc2023ae2550dbe9db1d0e20549050f0b4
+
  
47dd87b4c0e09c1bcb34162b7aae3e5a3b9a4aaba1b9fed0f4d681bb3f9febba

http://embra.edinburghlinux.co.uk/~jr/tmp/plasma-workspace-6.0.0-changes_report.html

git commit

69fca2e696633570cdb248ab33d13103fc54eaad

Jonathan

Re: Plasma 6.0.0 tars

[Jonathan Riddell]

plasma-workspace respin done
http://embra.edinburghlinux.co.uk/~jr/tmp/plasma-workspace-6.0.0-changes_report.html

  http://download.kde.org/stable/plasma/6.0.0/plasma-workspace-6.0.0.tar.xz";>plasma-workspace-6.0.0

   19MB
-
  
734ffa213bdc206f1374048dd7cc15580f8dc1ba567cbeaedbf03070e5ea0713
+
  
b1c32a3bc33168559626f6a398c31dbc2023ae2550dbe9db1d0e20549050f0b4



On Wed, 21 Feb 2024 at 16:02, Jonathan Riddell  wrote:

> Plasma 6.0.0 tars are available to packagers for packaging
>
> Release next Wednesday
>
> Please review https://community.kde.org/Plasma/Plasma_6.0_Release_notes
>
>

Re: kwin respin request

[Jonathan Riddell]

http://embra.edinburghlinux.co.uk/~jr/tmp/kwin-6.0.0-changes_report.html

   http://download.kde.org/stable/plasma/6.0.0/kwin-6.0.0.tar.xz";>kwin-6.0.0

   8.4MB
-
  
f05b9c2299fb169509311617ebe36223bb0f00c92b02866c1840ff887f402fd2
+
  
b1947c2b44de6190908462c81e8ac89ff9c7326a87641feb65e6ccd85262a4db



On Thu, 22 Feb 2024 at 08:06, Vlad Zahorodnii 
wrote:

> Hi,
>
> I'd like to request a respin of kwin with
>
> https://invent.kde.org/plasma/kwin/-/commit/961a2d70417fe4cb9e053f1348e703fb611065f4
> included. That commit fixes a pretty severe issue where the screen may
> freeze for a second.
>
> Cheers,
> Vlad
>
>

Re: Fedora 39 KDE spin - Wayland session improvements - thanks and info on current experience

[Nate Graham]

Thanks for the kind words, Amir! Yes, please do submit bug reports for 
those issues.


Nate



On 2/19/24 04:29, Amir Khan wrote:

Dear KWin / Plasma Development team,

I have been triaging bugs for KDE for some weeks, but as I have 
development experience in C++, C and other languages, I'm keen to get up 
to speed to be able to submit bugfixes too, in time. I've been using 
Fedora 39 KDE spin for learning Kirigami/QML and plan to move to KDE 
Frameworks with Qt this week or next week.


As I'm not in a paid contract currently and don't have any hardware 
spare, nor the option to purchase, I'm running Fedora 39 KDE spin in a 
VM, namely under Boxes on Ubuntu 22.04, and Virtualbox on Win11. Prior 
to updating today, including kwin updates, Plasma under Wayland was 
unusable. The mouse pointer wasn't accurately placing, e.g. it seemed a 
bit off from where the output of typing was appearing, when running 
Kate, as the only app running, or when trying to click on a hyperlink or 
the address bar when running Firefox only. *The update I applied today 
has vastly improved my experience of Plasma under Wayland, and it is now 
usable. This is a huge relief because I understand Fedora 40 won't have 
an X11 session option at all. Huge thanks from me for all your hard work!*


I was curious to see how far I needed to push Wayland before it might 
start misbehaving. It was pretty far lol!
When I ran four apps, all tiled under Plasma, namely Firefox playing a 
YouTube video, Kate, Konsole and Java running Freeplane as a flatpak, I 
started to get weird mouse behaviour again: pointer disappearing, 
pointer changing based on its expected function, lagging from where it 
actually was on the screen. Also, I was getting some flickering on the 
bottom panel, though not making the panel unusable. I'm sending this for 
information's sake, and will happily submit bugs to Bugzilla under kwin, 
tagged with wayland, if I am able to replicate something specific and 
easily testable.


Meantime, many thanks again, and have a great day :)
Amir.

Re: More 5.27 Releases

[Jonathan Riddell]

We discussed it at today's Plasma meeting and decided on Wednesday 6 March
for Plasma 5.27.11

Jonathan

Re: More 5.27 Releases

[Valorie Zimmerman]

These replies about a certain amount of bug-fix releases make me very happy
as a Kubuntu user.

Our next LTS will be released in March 2024, and thus can't be based on
Qt6, but we really look forward to the October 2024 release based on a
stable Qt6-based Plasma, Frameworks and apps release. Many of our users
rely on the LTS for even more stability, so we support that for 3 years.

It feels really good to see the Plasma devels having our backs! Autocorrect
made "devels" into devils! 😃

Valorie, Kubuntu Councillor

On Mon, Feb 12, 2024 at 5:44 PM Nate Graham  wrote:

> Agreed, I think it makes sense. Also maybe we should have a policy of
> "don't avoid backporting just because no more releases are planned" as a
> sufficient number of backported patched can indicate that we should do
> another release.
>
> Nate
>
>
>
> On 2/12/24 03:53, David Edmundson wrote:
> > Plasma 5.27 is not getting any more regular timed releases. However in
> > the past for LTS releases we have said that we would just make them
> > on-demand if there's enough stuff.
> >
> > I've seen enough patches over the last month that warrant putting into
> > 5.27 with people not cherry-picking some major fixes because "there's
> > not going to be another release". I want to request that we do at
> > least one more spin some time in the next few months.
> >
> > David
>


-- 
she/her. "Dwell on the beauty of life. Watch the stars, and see yourself
running with them." - Marcus Aurelius

Re: More 5.27 Releases

[Nate Graham]

Agreed, I think it makes sense. Also maybe we should have a policy of 
"don't avoid backporting just because no more releases are planned" as a 
sufficient number of backported patched can indicate that we should do 
another release.


Nate



On 2/12/24 03:53, David Edmundson wrote:

Plasma 5.27 is not getting any more regular timed releases. However in
the past for LTS releases we have said that we would just make them
on-demand if there's enough stuff.

I've seen enough patches over the last month that warrant putting into
5.27 with people not cherry-picking some major fixes because "there's
not going to be another release". I want to request that we do at
least one more spin some time in the next few months.

David

Re: More 5.27 Releases

[Justin Zobel]

On 12/2/24 21:34, Kai Uwe Broulik wrote:

Agreed.

I also think it’s a bad mindset to have “there won’t be any 5.27 
release”. We should for now treat backporting as if there will be 
another one, given 6.0 isn’t even out yet.


Cheers
Kai Uwe

Am 12.02.24 um 11:53 schrieb David Edmundson:

Plasma 5.27 is not getting any more regular timed releases. However in
the past for LTS releases we have said that we would just make them
on-demand if there's enough stuff.

I've seen enough patches over the last month that warrant putting into
5.27 with people not cherry-picking some major fixes because "there's
not going to be another release". I want to request that we do at
least one more spin some time in the next few months.

David
I agree, while Plasma 6 is right around the corner, many distros won't 
adapt it for some time. Major bugfixes and security fixes should 
definitely continue being applied until such time that most major 
distros have updated to 6.


Justin

Re: More 5.27 Releases

[Marco Martin]

I agree,
but as discussed in the meeting today, if we want to do a 5.27
release, we should backport the ci adaptations and make ci actually
work there

On Mon, Feb 12, 2024 at 11:53 AM David Edmundson
 wrote:
>
> Plasma 5.27 is not getting any more regular timed releases. However in
> the past for LTS releases we have said that we would just make them
> on-demand if there's enough stuff.
>
> I've seen enough patches over the last month that warrant putting into
> 5.27 with people not cherry-picking some major fixes because "there's
> not going to be another release". I want to request that we do at
> least one more spin some time in the next few months.
>
> David

Re: More 5.27 Releases

[Kai Uwe Broulik]

Agreed.

I also think it’s a bad mindset to have “there won’t be any 5.27 
release”. We should for now treat backporting as if there will be 
another one, given 6.0 isn’t even out yet.


Cheers
Kai Uwe

Am 12.02.24 um 11:53 schrieb David Edmundson:

Plasma 5.27 is not getting any more regular timed releases. However in
the past for LTS releases we have said that we would just make them
on-demand if there's enough stuff.

I've seen enough patches over the last month that warrant putting into
5.27 with people not cherry-picking some major fixes because "there's
not going to be another release". I want to request that we do at
least one more spin some time in the next few months.

David

Re: Wayland Nvidia situation for initial Plasma 6 release

[David Redondo]

Am Mittwoch, 7. Februar 2024, 10:37:13 CET schrieb Kai Uwe Broulik:
> Hi,
> 
> plasma-integration already (which I am NOT happy about!) creates a GL 
> context to check whether to use software rendering, there we could also 
> check the GL_VENDOR and set basic render loop.
> 
Yes we did that in 5 as well.
https://invent.kde.org/plasma/plasma-integration/-/merge_requests/119 now 
contains such a
check. 

Let's hope it's fixed properly in Qt 6.7!

David

Re: Wayland Nvidia situation for initial Plasma 6 release

[Kai Uwe Broulik]

Hi,

plasma-integration already (which I am NOT happy about!) creates a GL 
context to check whether to use software rendering, there we could also 
check the GL_VENDOR and set basic render loop.


But backporting won’t hurt either way I’d say.

Cheers
Kai Uwe

Am 07.02.24 um 10:13 schrieb David Redondo:

Hi,

when using Wayland on Nvidia there is a significant problem that QtQuick
windows freeze when resized, this can also manifest in plasma popups sometimes
not showing up.
ref. https://bugreports.qt.io/browse/QTBUG-95817
This can be worked around with using the basic render loop instead of the
threaded one.
With https://codereview.qt-project.org/c/qt/qtwayland/+/536040 Qt will now
disable threaded rendering on NVidia. However this patch missed 6.6.2 and will
be released with 6.6.3. Given that 6.6.2 is the latest patch version released
for Plasma 6.0 and the Wayland session is the new default we need to do
something. Options that I can think of are

- tell distros to include this patch in their QtWayland builds
- disable threaded rendering in plasma-integration on Nvidia and running
anything less than Qt 6.6.3

Thoughts?

David

Re: Major CI changes - FreeBSD and Linux

[Gleb Popov]

On Mon, Jan 22, 2024 at 12:09 PM Ben Cooksley  wrote:
>
> Hi all,
>
> Over the past few weeks significant work has been undertaken to develop the 
> ability to make use of containerised builds for FreeBSD.

This is great news! Thank you for all the work done on that front.

Re: Stale MRs

[Scarlett Moore]

Hi,
Some of those are mine and I am back now to merge them myself ( all
are snapcraft only merges ), unfortunately I am held up by a mess up
on my part and I cannot currently login to invent.kde.org due to 2fa
and new phone.
As soon as it is resolved I will knock them out and shorten that list for you.
Thanks,
Scarlett

On Wed, Jan 24, 2024 at 5:26 AM Carl Schwan  wrote:
>
> Hello,
>
> Friendly reminder that the following repository will give you a list of
> stalled merge requests without review and is updated every week,
>
> https://invent.kde.org/teams/gardening/gitlab/-/issues
>
> It would be nice if some more devs would subscribe to this repo and try to
> unblock some of the pending MRs. In particular the Non-Dev MRs category where
> we should try to give new contributors feedback in a timely manner.
>
> Cheers,
> Carl
>
>
>

Re: Plasma Bigscreen

[Jonathan Riddell]

I can't see why not

Jonathan

Re: Plasma Bigscreen

[Paul Brown]

On Tuesday, 30 January 2024 13:59:15 CET Jonathan Riddell wrote:
> Adita tells me that Plasma Bigscreen is ready Qt 6 and KF6 happiness. I've
> not tried it yet and and he's still working on the apps.  It was released
> as part of Plasma for the later 5 releases, but it's too late to add it
> into the Plasma 6 release so I'll get it working in neon unstable and if
> all is well then I'll make a standalone release alongside Plasm 6.0.
> 
> Jonathan


Nice!

Will it be released on the same day as Plasma 6.0? Will we be able to work it 
into the Promo stuff, like the announcement and social media blasts do you 
think?

Paul
-- 
Promotion & Communication

www: https://kde.org
Mastodon: https://floss.social/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity
LinkedIn: https://www.linkedin.com/company/kde

Re: Major CI changes - FreeBSD and Linux

[Ben Cooksley]

On Mon, Jan 22, 2024 at 10:08 PM Ben Cooksley  wrote:

> Hi all,
>
> Over the past few weeks significant work has been undertaken to develop
> the ability to make use of containerised builds for FreeBSD.
>
> Over the weekend i'm happy to report that this has now been rolled out and
> is now in use across all 5 CI workers that support invent.kde.org. This
> means going forward that we should no longer experience issues with running
> out of disk space on our FreeBSD CI jobs anymore, and we will have the
> ability to ensure others can easily reproduce our setup on their local
> system.
>
> The FreeBSD images for Qt 5.15 and Qt 6.6 that are in use can be found at
> https://invent.kde.org/sysadmin/ci-images along with the other images we
> publish. For those curious about how to set up their own builder,
> instructions can be found in the gitlab-templates/ folder of
> sysadmin/ci-utilities (instructions are also present there for Linux and
> Windows).
>
> Alongside this, we've also transitioned from using Docker on the Linux
> side of the CI workers to using rootless (unprivileged) Podman containers.
> This change was necessitated by changes to Bubblewrap, which is the
> underlying container technology used by flatpak-builder, that made it
> incompatible with the workarounds we previously had in place to run it
> under Docker.
>
> For most projects, this should not pose any issues however due to a last
> minute issue that was discovered during the rollout the DRM virtual gem
> devices while present won't be accessible. To my knowledge this only
> impacts KWin.
> It is possible other projects that were doing actions in their tests that
> need some form of privilege (such as invoking a debugger) may also be
> affected, however in theory there should not be much difference between the
> two container implementations.
>
> This change has also come along with a switch to Debian Bookworm (and the
> 6.1.0 kernel that comes with it) which depending on your tests could also
> have an impact.
>
> The underlying operating system in use within our Linux CI images is not
> changed and continues to be OpenSUSE for desktop Linux, and Ubuntu 22.04
> for Android mobile builds.
>
> At this time the setup for building of Linux images has yet to be adapted,
> so that capability is temporarily unavailable. It is expected to be
> restored in the coming days.
> Until that is completed, we will be unable to rebuild any of our Linux
> images.
>

This has now been corrected and should be functional again.


>
> Thanks,
> Ben
>

Cheers,
Ben

Re: KDE Gear features list

[Carl Schwan]

On Monday, November 27, 2023 10:49:04???PM CET Carl Schwan wrote:
> Hello,
> 
> I started working on the announcement for the the megarelease. For Plasma,
> Nate collected all the new user facing changes here:
> https://community.kde.org/Plasma/Plasma_6#User-facing_changes
> 
> I would appreciate if gear app maintainers and contributors could do the
> same for KDE gear: https://community.kde.org/Gear/Gear_24.02 I just need a
> link to commit, MR or bug report and a few words about the change.
> 
> I'm also working on a sliglty tweeaked format for the announcement which
> would allow to mention both the big major changes as well as more minor
> improvements than previously. So don't mind also adding more minor changes
> to the wiki page, but I can't promise I will manage to mention everything.
> 
> If you posted your progress already on a blog post (like we do in KDE PIM) a
> link to that is also great.

Thanks to all who contributed so far to the wiki page and a gentle ping to 
those who didn't yet.

Preview of the announcement is available here:
https://api.carlschwan.eu/announcements/megarelease/6/
(user: kde, password: kde)

If you think I missed something important or there are some incorrect details, 
the corresponding merge request is here ;)
https://invent.kde.org/websites/kde-org/-/merge_requests/244

Note that the screenshots are far from being the final and I will retake most 
if not all of them in the coming weeks.

Cheers,
Carl

Re: How Plasma/Kickoff app launcher always opening aligned horizontally to the center of the screen

[Nate Graham]

Hi Konstantin,

Are you asking how to program the feature, or how to configure the 
system to do it from a user perspective? Because at the moment there is 
no way to configure the system to do it; it's simply not implemented 
right now.


Nate



On 12/22/23 13:42, Konstantin Makarov wrote:

Hello,

How can I make the Plasma/Kickoff app launcher always opening aligned 
horizontally to the center of the screen?


I know that if I place the app launcher icon (button) on a center 
aligned panel, the app launcher opens in the center position of the 
screen. But if the app launcher icon has moved to the left (for example, 
when started app icons pushing the app launcher's icon to the left) and 
app launcher's icon position going lefter of left border of the app 
launcher, then the app launcher is jump to the left from screen center 
and centered by app launcher's icon (is not in the center of the screen).

Re: Merge Service still in use?

[Dmitry Kazakov]

The main problem for me is that I want to have the patch merged asap, to be
able to test/resolve issues of some other patches in combination with this
one. That's why I just merge that without rebase-pipeline completion.

Speaking truly, I'm not very happy with our 'always fast-forward merge'
policy [0], but given GitLab doesn't provide an option to switch policy
on-the-fly, it should be fine for now.

[0] - this policy is good for small patches, but for bigger patchset I
would prefer to see an explicit merge commit

On Tue, Dec 19, 2023 at 10:25 AM Ben Cooksley  wrote:

> On Tue, Dec 19, 2023 at 10:16 PM Dmitry Kazakov 
> wrote:
>
>> Hi, Ben!
>>
>> I think we have kind of forgotten about that. I usually build the MRs
>> locally or check if the pipeline has succeeded for the current revision,
>> then I just "rebase without pipeline" and do the merge. It might be that I
>> should use the merge service for that, I'm not sure...
>>
>
> That is fine. Given it doesn't seem to be too well loved i'm going to
> decommission the service.
>
> The initial issues we had with it's reliability had been resolved however
> I think that happened not too long before people stopped using it.
>
> Cheers,
> Ben
>
>
>>
>> On Sat, Dec 16, 2023 at 2:41 AM Ben Cooksley  wrote:
>>
>>> Hi all,
>>>
>>> I've just been reviewing services we're looking after and while doing so
>>> have noticed that Marge Bot (invent.kde.org/merge-service) doesn't seem
>>> to have done anything for 4 months.
>>>
>>> As the two projects with it enabled, is this something you're still
>>> using as it doesn't look like it.
>>>
>>> Thanks,
>>> Ben
>>>
>>
>>
>> --
>> Dmitry Kazakov
>>
>

-- 
Dmitry Kazakov

Re: Merge Service still in use?

[Dmitry Kazakov]

Hi, Ben!

I think we have kind of forgotten about that. I usually build the MRs
locally or check if the pipeline has succeeded for the current revision,
then I just "rebase without pipeline" and do the merge. It might be that I
should use the merge service for that, I'm not sure...


On Sat, Dec 16, 2023 at 2:41 AM Ben Cooksley  wrote:

> Hi all,
>
> I've just been reviewing services we're looking after and while doing so
> have noticed that Marge Bot (invent.kde.org/merge-service) doesn't seem
> to have done anything for 4 months.
>
> As the two projects with it enabled, is this something you're still using
> as it doesn't look like it.
>
> Thanks,
> Ben
>


-- 
Dmitry Kazakov

Re: more betas / shorter windows?

[Neal Gompa]

On Mon, Dec 18, 2023 at 2:22 PM Nate Graham  wrote:
>
> Yeah, it's long been a problem that bugs reported towards the end of a
> beta release were often fixed weeks ago, which wastes everyone's time.
> Shorter betas would also help our most effective volunteer QA people who
> close their bug reports once they're fixed by us (like Patrick Silva and
> some others) do so at a more rapid pace.
>
> I'd support one-week betas, or if we think that's too aggressive and too
> much work for everyone, then two weeks.
>

It takes, on average, about a week for us in Fedora to get everything
in and validated. I suspect other distributions are similar. Making it
too short risks making it too hard for us to keep up.




--
真実はいつも一つ！/ Always, there's only one truth!

Re: Merge Service still in use?

[Ben Cooksley]

On Tue, Dec 19, 2023 at 10:47 PM Dmitry Kazakov  wrote:

> The main problem for me is that I want to have the patch merged asap, to
> be able to test/resolve issues of some other patches in combination with
> this one. That's why I just merge that without rebase-pipeline completion.
>
> Speaking truly, I'm not very happy with our 'always fast-forward merge'
> policy [0], but given GitLab doesn't provide an option to switch policy
> on-the-fly, it should be fine for now.
>

That global policy is in place for good reason - and not only because
people want a clean history.
It is also there because merge commits cannot be easily reverted and you do
not want to try reverting a merge commit (it ends very very badly - we've
had to force push repositories out of that mess before)

Cheers,
Ben


>
> [0] - this policy is good for small patches, but for bigger patchset I
> would prefer to see an explicit merge commit
>
> On Tue, Dec 19, 2023 at 10:25 AM Ben Cooksley  wrote:
>
>> On Tue, Dec 19, 2023 at 10:16 PM Dmitry Kazakov 
>> wrote:
>>
>>> Hi, Ben!
>>>
>>> I think we have kind of forgotten about that. I usually build the MRs
>>> locally or check if the pipeline has succeeded for the current revision,
>>> then I just "rebase without pipeline" and do the merge. It might be that I
>>> should use the merge service for that, I'm not sure...
>>>
>>
>> That is fine. Given it doesn't seem to be too well loved i'm going to
>> decommission the service.
>>
>> The initial issues we had with it's reliability had been resolved however
>> I think that happened not too long before people stopped using it.
>>
>> Cheers,
>> Ben
>>
>>
>>>
>>> On Sat, Dec 16, 2023 at 2:41 AM Ben Cooksley  wrote:
>>>
 Hi all,

 I've just been reviewing services we're looking after and while doing
 so have noticed that Marge Bot (invent.kde.org/merge-service) doesn't
 seem to have done anything for 4 months.

 As the two projects with it enabled, is this something you're still
 using as it doesn't look like it.

 Thanks,
 Ben

>>>
>>>
>>> --
>>> Dmitry Kazakov
>>>
>>
>
> --
> Dmitry Kazakov
>

Re: Merge Service still in use?

[Ben Cooksley]

On Tue, Dec 19, 2023 at 10:16 PM Dmitry Kazakov  wrote:

> Hi, Ben!
>
> I think we have kind of forgotten about that. I usually build the MRs
> locally or check if the pipeline has succeeded for the current revision,
> then I just "rebase without pipeline" and do the merge. It might be that I
> should use the merge service for that, I'm not sure...
>

That is fine. Given it doesn't seem to be too well loved i'm going to
decommission the service.

The initial issues we had with it's reliability had been resolved however I
think that happened not too long before people stopped using it.

Cheers,
Ben


>
> On Sat, Dec 16, 2023 at 2:41 AM Ben Cooksley  wrote:
>
>> Hi all,
>>
>> I've just been reviewing services we're looking after and while doing so
>> have noticed that Marge Bot (invent.kde.org/merge-service) doesn't seem
>> to have done anything for 4 months.
>>
>> As the two projects with it enabled, is this something you're still using
>> as it doesn't look like it.
>>
>> Thanks,
>> Ben
>>
>
>
> --
> Dmitry Kazakov
>

Re: Merge Service still in use?

[Vlad Zahorodnii]

On 12/18/23 19:25, Ben Cooksley wrote:

Just out of curiosity - why?


It broke down a while ago and, unfortunately, it covers only some of 
ours needs, not all. So it was not a big loss for us and we simply moved 
on with merging patches manually.


Cheers,
Vlad

Re: more betas / shorter windows?

[Nate Graham]

Yeah, it's long been a problem that bugs reported towards the end of a 
beta release were often fixed weeks ago, which wastes everyone's time. 
Shorter betas would also help our most effective volunteer QA people who 
close their bug reports once they're fixed by us (like Patrick Silva and 
some others) do so at a more rapid pace.


I'd support one-week betas, or if we think that's too aggressive and too 
much work for everyone, then two weeks.


Nate



On 12/18/23 10:42, Harald Sitter wrote:

With the second p6 beta sneaking up on us I've been pondering the beta
experience...

I can't help but think that the windows we've chosen were too long. At
least from a crash tracking POV most of the crash reports we get from
!neon are either of unreasonably low quality (because of improvements
made to drkonqi in the meantime), or already fixed.

I'd like to propose that we push out more betas with shorter windows
in the future.

2 weeks maybe? 1 perhaps even if distros can cope? Or maybe something fibonacci?

Food for thought.

HS

Re: more betas / shorter windows?

[Harald Sitter]

6.x onwards

On Mon, Dec 18, 2023 at 6:59 PM Nicolas Fella  wrote:
>
> On 12/18/23 18:42, Harald Sitter wrote:
> > With the second p6 beta sneaking up on us I've been pondering the beta
> > experience...
> >
> > I can't help but think that the windows we've chosen were too long. At
> > least from a crash tracking POV most of the crash reports we get from
> > !neon are either of unreasonably low quality (because of improvements
> > made to drkonqi in the meantime), or already fixed.
> >
> > I'd like to propose that we push out more betas with shorter windows
> > in the future.
> >
> > 2 weeks maybe? 1 perhaps even if distros can cope? Or maybe something 
> > fibonacci?
> >
> > Food for thought.
> >
> > HS
> By "in the future" you mean for the 6.0 release or the 6.x releases? In
> the past we only had one beta release for the 5.x releases, but I guess
> having more than one again could be up for debate

Re: more betas / shorter windows?

[Nicolas Fella]

On 12/18/23 18:42, Harald Sitter wrote:

With the second p6 beta sneaking up on us I've been pondering the beta
experience...

I can't help but think that the windows we've chosen were too long. At
least from a crash tracking POV most of the crash reports we get from
!neon are either of unreasonably low quality (because of improvements
made to drkonqi in the meantime), or already fixed.

I'd like to propose that we push out more betas with shorter windows
in the future.

2 weeks maybe? 1 perhaps even if distros can cope? Or maybe something fibonacci?

Food for thought.

HS

By "in the future" you mean for the 6.0 release or the 6.x releases? In
the past we only had one beta release for the 5.x releases, but I guess
having more than one again could be up for debate

Re: Merge Service still in use?

[Ben Cooksley]

On Tue, Dec 19, 2023 at 2:36 AM Vlad Zahorodnii 
wrote:

> On 12/16/23 03:41, Ben Cooksley wrote:
> > Hi all,
> >
> > I've just been reviewing services we're looking after and while doing
> > so have noticed that Marge Bot (invent.kde.org/merge-service
> > ) doesn't seem to have done
> > anything for 4 months.
> >
> > As the two projects with it enabled, is this something you're still
> > using as it doesn't look like it.
>
> Hi,
>
> We stopped using it in kwin.
>

Thanks for that update.

Just out of curiosity - why?


>
> Regards,
> Vlad
>
>
Cheers,
Ben

Re: Merge Service still in use?

[Vlad Zahorodnii]

On 12/16/23 03:41, Ben Cooksley wrote:

Hi all,

I've just been reviewing services we're looking after and while doing 
so have noticed that Marge Bot (invent.kde.org/merge-service 
) doesn't seem to have done 
anything for 4 months.


As the two projects with it enabled, is this something you're still 
using as it doesn't look like it.


Hi,

We stopped using it in kwin.

Regards,
Vlad

Re: Feature freeze exception (or not) for "Advanced Power Settings" QML port

[David Edmundson]

I don't want to set a precedent for many others.
I would have rejected this if the MR was only just opened, or if this
wasn't a KCM section that's specifically titled "Advanced settings" or
we were having this discussion later.

But given it closes some bugs, I think it's reasonable to go ahead.
Wait one more day for another ack (or nack!) then ship it.

David

Re: Unified internal communications channel

[Volker Krause]

On Donnerstag, 7. Dezember 2023 18:04:24 CET Carl Schwan wrote:
> On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote:
> > What I'm proposing is some kind of place that *only* has internal
> > announcements and is very log signal-to-noise such that we can
> > fearlessly recommend that *everybody* subscribe to it. In addition,
> > ideally those who want to subscribe via mailing list could do so, but
> > its content would automatically appear in other places too, such as
> > discuss.kde.org and an invent.kde.org project. That way people can
> > subscribe by whatever means is most comfortable to them.
> > 
> > Thoughts?
> 
> I fear this will just create a new source of information instead of unifying
> the source of information. We already have the following channels for
> announcements:
> 
> - planet.kde.org: contains release announcements, gear release schedule
> announcement from Albert as well as random development updates
> - kde-code-de...@kde.org: contains mostly news about new apps and modules
> - kde-de...@kde.org: contains the gear release schedule announcements and
> other technical announcements
> - plasma-devel@kde.org: contains important for plasma developers and the
> meeting notes of the monday chat meeting.
> - kde-commun...@kde.org contains general community (non technical)
> announcements
> 
> Adding a new channel that is either a mailing list, rss feed or a forum
> category won't help and will probably only makes it worse. It's also very
> difficult to defines that is an important internal news for the whole
> community is as it will be different for every subproject in KDE. The
> plasma logo discussion would have not been very relevant for any app
> developers. Similarly discussion about the new default database backend for
> Akonadi won't be interesting for Plasma developers but might be interesting
> for KMyMoney and other non-PIM apps using Akonadi.

Technically we do have a low-traffic channel for everyone even, kde-cvs-
announce. That one is even mandatory for people with contributor accounts 
AFAIK, you get added to that by default. However that is really only for 
things relevant for everyone, such as important infrastructure changes.

A topic like the one that triggered this discussion obviously doesn't qualify 
for that, that was mostly relevant for people involved in Plasma. So we'd need 
to clarify who we mean by "everybody" here, and I suspect that will be a 
subset of people varying from topic to topic. If so, one more channel is 
unlikely to magically fix things I think.

> Something that might help is merging the kde-core-devel and kde-devel
> mailing lists as those are very similar and should hopefully not be too
> complicated to do.

And/or kde-frameworks-devel, yes, we probably don't need all three of those 
anymore. While it might help a bit in finding appropriate channels to address 
the subset of people you want/need to reach it's somewhat orthogonal to Nate's 
proposal and would not have made any difference for the Plasma logo discussion 
I think.

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

Re: Unified internal communications channel

[Carl Schwan]

On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote:
> Hello everyone,
> 
> There have been a couple instances of drama this week caused by
> decisions being made without some of the relevant stakeholders knowing
> about them. In all cases, the decisions were announced, but either not
> announced in the places where all the stakeholders saw it, or not all
> stakeholders were able to notice the announcement in a place where they
> do generally pay attention.

The drama could have been avoided if the promo folks would have followed my 
recommandation to contact the relevant stakeholders in the plasma-
de...@kde.org mailing list or attend the Plasma chat meeting hapenning every 
Monday at 4 PM in the Plasma matrix/irc channel. I tried to bring this up many 
times and it was dismissed every time i brough it up and I was told that I 
didn't understood the proposed idea and that should re-read the previous 
messages. It is unfortunately a recurring pattern in the promo channel and I 
decided for now to leave the kde-promo matrix channel as I feel like I'm 
wasting my time there.

> It makes me think that maybe the KDE development community has grown so
> large that we can't reasonably expect everyone to be paying attention to
> everything, or for everyone with something to announce to know exactly
> where the people who need to know it expect to find those messages.
> 
> So perhaps this could be addressed at the source by creating a single
> unified "internal announcements" place that everyone can pay attention
> to without fear of being spammed with too many messages. In theory the
> kde-devel mailing list is one such place, but it's got more than just
> announcements, and also mailing lists aren't very accessible for a lot
> of newer contributors who didn't grow up with them.
>
> What I'm proposing is some kind of place that *only* has internal
> announcements and is very log signal-to-noise such that we can
> fearlessly recommend that *everybody* subscribe to it. In addition,
> ideally those who want to subscribe via mailing list could do so, but
> its content would automatically appear in other places too, such as
> discuss.kde.org and an invent.kde.org project. That way people can
> subscribe by whatever means is most comfortable to them.
> 
> Thoughts?

I fear this will just create a new source of information instead of unifying 
the source of information. We already have the following channels for 
announcements:

- planet.kde.org: contains release announcements, gear release schedule 
announcement from Albert as well as random development updates
- kde-code-de...@kde.org: contains mostly news about new apps and modules
- kde-de...@kde.org: contains the gear release schedule announcements and 
other technical announcements
- plasma-devel@kde.org: contains important for plasma developers and the 
meeting notes of the monday chat meeting.
- kde-commun...@kde.org contains general community (non technical) 
announcements

Adding a new channel that is either a mailing list, rss feed or a forum 
category won't help and will probably only makes it worse. It's also very 
difficult to defines that is an important internal news for the whole community 
is as it will be different for every subproject in KDE. The plasma logo 
discussion would have not been very relevant for any app developers. Similarly 
discussion about the new default database backend for Akonadi won't be 
interesting for Plasma developers but might be interesting for KMyMoney and 
other non-PIM apps using Akonadi.

Something that might help is merging the kde-core-devel and kde-devel mailing 
lists as those are very similar and should hopefully not be too complicated to 
do.

Cheers,
Carl
> 
> Nate

Re: KRunner and KActivities

[Alexander Lohnau]

Heyho,

as stated in #Plasma, I will take care of it shortly ;)

Regards
Alex

On 11/20/23 18:57, Jonathan Riddell wrote:

I've just seen that KRunner uses KActivities but we moved activities
to Plasma and Runner is in Frameworks.  Whatever shall we do?

Joanthan

Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

[christoph]

On 2023-11-05 18:35, christ...@cullmann.io wrote:

On 2023-11-05 18:01, Nate Graham wrote:

On 11/5/23 07:42, Kevin Ottens wrote:
I was clumsily advocating for this Akademy 2021 or 2022 (can't 
remember

which).

This way it's clearer to application authors when they tie themselves 
to a

given workspace or not.

Also, isn't Elisa able to work without Baloo? It even seems to do the 
right
thing if I trust its CMakeLists.txt. It has Baloo as a recommended 
but

optional dependency, and disable it altogether for Win32 builds.


Yes, Elisa also includes an internal indexer, for use on Windows and 
Android, or on *Nix when Baloo isn't installed or is disabled.


I think the original idea for the app was to delegate all the indexing 
heavy lifting to Baloo to avoid internal complication, but clearly 
this has not worked out in practice, since to be truly cross-platform, 
it can't assume that Baloo is present and active and does need its own 
indexer. So maybe the best course of action is actually to remove 
Baloo support entirely and always use the internal indexer, so that we 
don't have two different code paths.


Hi,

sounds for me a lot easier to test with just one variant.
And one would always use the variant Windows uses.


Hi,

any more feedback about this?

Greetings
Christoph



Greetings
Christoph




Nate