* It's worth discussing the state of KF6
* there's been some recent issues on other parts of KDE with people
porting early
* so to make sure we're all on the same page, it's worth following
anything on frameworks-devel before going loco with devleopment

Nico: There's two things to keep in mind here:
1. KF6 is going to be somewhat unstable/breaking for the forseeable future
2. if a project makes the jump to KF6 (even if 5 compat is kept) that
means that all deps need to make the jump, and all other projects that
consume the project need to make the jump too
* So right now we should avoid anything in plasma. Current plan seems
to be that we hold off on a while before pushing.
* and just to clarify, the CI on plasma right now for Qt6 is Qt6 builds of kf5
which is a bit confusing! but overall makes sense
*And on a related note, is it worth now putting into plasma code
#ifdef KF5
#include <KDeclarative/wahtever>
#include <KQmlWhatever>
I'm still not clear if the bigger changes can be started on p-f or not then
* We can do them without breaking CI
* But Plasma won't be able to use them yet
So consensus seems to be to wait a bit before making the jump?
we should be polishing 5.27 anyway :D
we have said in the past we do it on the day of 5.27.2

* I am busy investigating annoying bugs with klipper and plasma-nm
with one liner fixes that do not reflect the investigation time :D

* spectacle: juggling encoders and players to make sure we offer
something interesting
* settling with vp8 which works about as well as x264 (maybe not
entirely but quite) and it's free of patents and other bullshits
* discover: fixed the ci run for flatpaktest and worked on some
bugfixing around flatpak support too
* sddm: did a push on a longstanding issue from fedora that is almost
fixed (in a PR, feel free to give it a go)
* otherwise spent quite some time in SDDM issues and PRs to see what
can be included in view of a release and what should be postponed

* I've mostly done KF6 things
* Nothing worth mentioning in particular

* Mmh, might be worth mentioning we're working on an rdp
implementation for remote desktop
* Trying to build on top of freedrp, which so far is proving pretty tricky
* There's a repo at https://invent.kde.org/ahiemstra/krdp
* Which is currently mostly me trying to wrap my head around things

* Was investigating AppImage desktop integration behavior. Do you
think it makes sense to make changes in Plasma to make AppImage
integrate better (as libtaskmanager already did for snapd)?
* AppImageKit patch, blind fix, still fighting against building it but
it builds on OBS: https://github.com/AppImage/AppImageKit/pull/1232
* Libtaskmanager patch:
* Kwin patch: https://invent.kde.org/plasma/kwin/-/merge_requests/3519

Nico: I really don't like us bending over to make appimages work
Also I don't like the code duplication between kwin and libtaskmanager
The problem boils down to appimages not having .desktop files in the
standard location
Which is kind of a fundamental issue with appimage's deployment model
I understand https://github.com/TheAssassin/AppImageLauncher kind of fixes that

* adapting tests to qt patch which exports the pushed actions on
checkable toolbuttons
* revisiting some gui-testing related merge requests that weere stuck
since a while
* better migration code and consistency check for multiscreen mapping
in plasma containments
* merged notification applets fixes
* fixed layout problems of desktop widgets when the resolution changes
and fixed the "widget migrate upwards some pixels" on plasma restart
KF6 stuff
* kirigami fixes to make kirigami gallery mostly load and work in kf6
* added most properties of AppletInterface back into Applet (stiull
some more difficult ones missing,all the ones i did didn't require any
api change at all) in preparation of ScriptEngine killing attempt

Reply via email to