Plasm 6.1 Kickoff Meeting notes

[Nicolas Fella]

# Plasma 6.1 kickoff meeting notes

## 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)
    - 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

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

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

# 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


Problems:
- Neon's rollout was/still is bumpy. Needs retrospective from Neon
developers on what happened
- Nvidia:
    - Missing configuration to enable modesetting (downstream issue)
    - 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

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

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

# 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

Monday meeting notes for 15/01/2024

[Nicolas Fella]

Marco:

fixed wheel to switch desktop action in folderview
looking at why long touchscreen tap on the desktop crashes plasma, still
no clue
made an upstream merge request for layer shell to reserve edges also for
corner-aligned panels
refactored kirigami.Page to have global toolbars outside of it as the
hack we had broke in Qt 6.7
improved a bit fractional scaling rendering in kirigami icons and the
desktop style.. not perfect yet

redstrate:

I have been busy working on lots of artist-oriented features:

Added more tablet events for my MRs that depend on that
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1976)
TapHandler eventPoints seem to be missing some pen-specific information
like tilt, I might look into adding that upstream.
Pen buttons are now called that, not "tool buttons" which is a leakage
of the Wayland protocol verbage.
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1971)
Added a configurable pen pressure curve, which is now ready for review
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1972)
The pen tester tool, which is now ready for review too
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1970)
The pen calibration tool, which is still ready for review as well
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1833)
Other KWin changes:

Necessary changes for the pen pressure curve feature
(https://invent.kde.org/plasma/kwin/-/merge_requests/4920)
Fix coding style link in CONTRIBUTING
(https://invent.kde.org/plasma/kwin/-/merge_requests/4918)
Fix missing epoxy dependency when linking in downstream projects
(https://invent.kde.org/plasma/kwin/-/merge_requests/4919)
Tackled some other bugs I found:

Fix fallbacks for -symbolic icons, less colorful icons should show up in
the system tray as expected
(https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/118).
Tests for that functionality too
(https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/119).
Fixed camera-video-symbolic recoloring
(https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/315)

Arjen:

we did some fixes for fractional scaling in qqc2-desktop-style
some issues should be resolved but I also tracked an issue down to a
potential bug in Qt itself
it's unfortunately a little tricky to verify and fix

but it leads to rendering glitches in the kscreen kcm where sometimes a
single line will disappear or be duplicated

Xaver:

did some refactoring for how presentation is done in KWin, to make
triple buffering, adaptive sync and such stuff easier to deal with
I wrote a mostly complete implementation of "triple buffering" (there's
too many meanings for that word) in KWin, which makes dropping frames
because the GPU is too slow less bad
fixed multi gpu giving garbled output with older GPUs
fixed a bunch of KWin bugs with OpenGL ES. Color management is still
broken, but everything else looks good now
looked a bit into finally upstreaming our blur Wayland protocol
now I'm working on fixing some performance regressions

Neal:

Released Plasma 6 RC1 into Fedora Rawhide on Sunday, available now in
nightlies for KDE Spin and Kinoite 
Started looking at gaps for using KWin with LXQt for Wayland
(Two weeks ago) submitted a merge request to fix library name for krdp:
https://invent.kde.org/plasma/krdp/-/merge_requests/12
Looking into potentially a w-p submission of an output management
protocol for kwin and wlroots to support

Kai:

Plasma:

Merged fix for outputOnly on Wayland
OSD should be click-through on Wayland again
should probably be ported to PlasmaWindow, and the Window flags stuff be
made more comfortable so you can easily just set
Qt.WindowTransparentForInput
Frameworks:

Added KMessageDialog::beep function
Lets applications that do custom message boxes play the standard
notification sound without KNotification
Kate uses that for its “Save?” dialog now, which is fully custom but
also pretty much a confirm message box
Select current icon when choosing a new toolbar icon, please review:
https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/212
Qt:

Made a fix for QtWayland creating a GL context to check whether it needs
a deco or not, even for widget apps
Turns out there’s two places in KDE where it also does that, too:
plasma-integration’s kquicksettings for determining whether to use
software renderer :-(
KCrash to send the GL_VENDOR, can this not be in DrKonqi?
QtWayland takes ~60ms just to load and init the GL integration plug-in,
quite a waste for software-only apps
Found an awful performance regression in the glyph cache with color
fonts compared to Qt 5
when inserting a single emoji it would process and detach and copy the
entire (potentially 16384x1024) texture
plus some RGB-BGR meddling and other wasteful operations
overall there’s a lot of wasteful QImage detaching going on in RHI in
various places :-(

on the subject of notification sound I also had a look at how we could
retrofit that to QMessageBox but it goes 

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: QML: a packagers nightmare. Assistance please.

[Nicolas Fella]

On 11/8/23 17:11, Scarlett Moore wrote:

While I have everyone's attention. The part that is getting me ( and
our linters ) is qml installation paths seem all over the place
For example plasma-framework we have

org.kde.plasma.plasmoids

which I read in the docs is "identified" qml which states it must be
installed into the QML import path which is normally ( and our linter
is set to ) /usr/lib/{arch_triplet}/qt{version}/qml
https://doc.qt.io/qt-6/qtqml-modules-identifiedmodules.html

However, these are getting installed to /usr/share/plasma/plasmoids

This doesn't follow the folder path ( eg. org/kde/plasma/plasmoids )
nor the normal qml import path. Or am I missing something?
If it is our mistake to not have this in our import path and our
linter is confused somehow, how would I add it? /usr/share or
/usr/share/plasma but then wouldn't it still be looking for the
org/kde/plasma/plasmoids?
Thanks for any help, I am really trying to figure this stuff out, but
I am lost in a sea of docs.
Scarlett


You are talking about two very different things here.

QML modules (i.e. QML "libraries") are installed to
/usr/lib/{arch_triplet}/qt{version}/qml. They contain a qmldir file,
(optionally) a .so file, (optionally) some .qml files, (optionally) a
.qmltypes file etc.

The content of /usr/share/plasma/plasmoids are not QML modules. They are
plasmoid packages (in the KPackage format). They contain a metadata.json
file and a number of qml/js/xml files in contents/. For all intents and
purposes those are data files like any other in /usr/share and should be
treated as such.

As such what you are seeing is entirely expected.

Cheers

Nico

Re: plasma-framework

[Nicolas Fella]

On 11/7/23 12:22, Jonathan Esk-Riddell wrote:

On Sun, Nov 05, 2023 at 12:59:28PM +0100, Friedrich W. H. Kossebau wrote:

kactivities and kactivities-stats: please consider proper de-KF-ication now

Hi,

with plasma-framework, kactivities and kactivities entering the Plasma product
bundle, I assume they also will adapt to Plasma versioning.

We've done the reversioning now (thanks to those who tidied up after
me yesterday).  We plan to rename plasma-framework to libplasma
although I'm not sure who has the energy to do it.  I suppose we'll
also remove the KF terms from the other ones too.

kwayland is the 4th one being moved, it has been re-versioned but not yet moved 
in invent.


Let's not do anything to plasma-framework until after the alpha to avoid
stiring things up yet again.

We have plenty of time to do it before the beta/rc

Applet config dialog changes

[Nicolas Fella]

Hi,

I have an open MR that changes how applet's config UI integrates with
the container UI:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1675

See https://invent.kde.org/plasma/plasma-desktop/-/issues/99 for some
context.

The benefits would not only be somewhat cleaner internals but also more
flexibility for the applet itself. Currently the container provides a
scrollview around the config, which is problematic for content that
wants to provide its own scrollview, like the system tray entries page.
See https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3204

The downside is that we need to touch all applet configs. Most of this
is pretty straight-forward though, replacing the root item with a
SimpleKCM (or other appropriate *KCM type).

With release/freeze coming up we're in a now-or-never situation here.
Should we do a concerted push towards getting this done?

Cheers

Nico

Re: print-manager and wacomtablet to Plasma

[Nicolas Fella]

On 11/1/23 00:28, Nicolas Fella wrote:

On 10/31/23 23:23, Albert Astals Cid wrote:

El dimarts, 31 d’octubre de 2023, a les 20:43:47 (CET), Jonathan
Riddell va
escriure:

As discuccsed in Plasma meeting and just now with KDE gear release
spods,
Plasma would like to take over releases of print-manager and
wacomtablet.
This means renumbering the tars from e.g. 23.08 to 5.80.0.

Any issues?

What's the rationale for such move?


See https://mail.kde.org/pipermail/release-team/2023-June/013081.html
where I originally brought up the topic

partly it's not relevant any more since we settled on releasing Plasma
and Gear together this time. The point about these being effectively
tied to Plasma still stands, and as such releasing them together makes
sense, for example because it makes it easier to deal with changes in
their interaction with Plasma


Also, wacomtablet isn't actually part of Gear, it's independently
released and there hasn't been a release in a while.

By moving it to Plasma we would make sure it does get regular releases

Re: print-manager and wacomtablet to Plasma

[Nicolas Fella]

On 10/31/23 23:23, Albert Astals Cid wrote:

El dimarts, 31 d’octubre de 2023, a les 20:43:47 (CET), Jonathan Riddell va
escriure:

As discuccsed in Plasma meeting and just now with KDE gear release spods,
Plasma would like to take over releases of print-manager and wacomtablet.
This means renumbering the tars from e.g. 23.08 to 5.80.0.

Any issues?

What's the rationale for such move?


See https://mail.kde.org/pipermail/release-team/2023-June/013081.html
where I originally brought up the topic

partly it's not relevant any more since we settled on releasing Plasma
and Gear together this time. The point about these being effectively
tied to Plasma still stands, and as such releasing them together makes
sense, for example because it makes it easier to deal with changes in
their interaction with Plasma

Re: Plasma 6 alpha modules list

[Nicolas Fella]

In https://mail.kde.org/pipermail/release-team/2023-June/013081.html I
proposed to move print-manager and wacomtablet from Gear to Plasma.
Nobody objected so I guess we can move forward with this?

On 10/27/23 17:39, Jonathan Riddell wrote:

12 days to go until the first alpha release, it's time to work out
some details.

set(PROJECT_VERSION_MAJOR 5) shall I change to 6 now? This is used for
soversions for various internal libs

We've probably discussed but I've forgotted, what minimum version of
Qt? Currently 6.4 is set for most but do we want 6.6?

When is feature freeze?  Before Alpha? Or should we call that soft
feature freeze and have a harder one end of November before the Beta?

plasma-bigscreen - No Qt 6 port, drop?

aura-browser - bigscreen app, Qt 6 port but drop?
plank-player - bigscreen app, Qt 6 port but drop?
plasma-remotecontrollers - bigscreen plugin, Qt 6 port good but drop?

kwrited - can we get rid of this? I remmeber having great fun at uni
writing onto people's terminals but it feels like the write/mesg
concept is something that should die with old school unix.  I got it
to work in KDE neon using xterm after I edited /etc/login.defs but not
with konsole or gnome-terminal

plasma-mobile - good although it would be nice to get confirmation
from the plasma mobile team they want it released at the same time

Niccolo says he wants gamepad-kcm in which i think is
https://invent.kde.org/redstrate/gamepad-kcm that needs kdereviewed
pronto (or just put into plasma-workspace?)

bluedevil - good
breeze - Qt 5 and 6 in one for qt style theme
breeze-grub - good, no change needed
breeze-gtk - "find_package(Breeze 5.14.90 REQUIRED)" should this be
updated to 5.27.80 (it builds and installs fine with Qt 5 or 6 for now)
breeze-plymouth - good, no Qt needed
discover - good, needs new unreleased libappstream
drkonqi - good
flatpak-kcm - good
kactivitymanagerd - good
kde-cli-tools - good
kde-gtk-config - good
kdecoration - good
kdeplasma-addons - good
kgamma5 - good but can we drop the 5 from the repo name?
khotkeys - drop
kinfocenter - good
kmenuedit - good
kpipewire - good
kscreen - good
kscreenlocker - good
ksshaskpass - good
ksystemstats - good
kwallet-pam - good
kwayland-integration - drop
kwin - good
layer-shell-qt - good
libkscreen - good
libksysguard - good
milou - good
oxygen - good, builds Qt 5 and 6 in one
oxygen-sounds - good (no Qt)
plasma-browser-integration - good
plasma-desktop - good
plasma-disks - good
plasma-firewall - good
plasma-integration - good
plasma-nano - good (but does it have any users?)
plasma-nm - good
plasma-pa - good
plasma-sdk - good but can I suggest rename cuttlefish to iconexplorer
or something more explanatory?
plasma-systemmonitor - good
plasma-thunderbolt - good
plasma-vault - good
plasma-welcome - good but change REQUIRED_QT_VERSION to QT_MIN_VERSION ?
plasma-workspace - good
plasma-workspace-wallpapers - good
plymouth-kcm - good but QT_MIN_VERSION is still 5 so I'll bump it
polkit-kde-agent-1 - good
powerdevil - good
qqc2-breeze-style - good for Qt 6 but I think we need to release a Qt
5 build using the Plasma/5.27 branch but using a different name (neon
uses qqc2-breeze5-style)
sddm-kcm - good
systemsettings - good
xdg-desktop-portal-kde - good

[Powerdevil] [Bug 365100] Pressing the physical power button is ignored with certain hardware

[Nicolas Fella]

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

Nicolas Fella  changed:

   What|Removed |Added

 CC||nicolas.fe...@gmx.de

--- Comment #12 from Nicolas Fella  ---
also .config/kglobalshortcutsrc

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

Renaming Plasma's applications.menu file

[Nicolas Fella]

Hi,

In KF5 KService ships /etc/xdg/menus/applications.menu, our menu
definition according to
https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html

Since this will cause a conflict between KF5 and KF6 (and potentially
other desktop environments) for Plasma 6 I'm planning to:

- Move the file to plasma-workspace

- Rename it to plasma-applications.menu

- Set XDG_MENU_PREFIX="plasma-" at Plasma startup

See https://phabricator.kde.org/T12542,
https://invent.kde.org/frameworks/kservice/-/merge_requests/153, and
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3053

@distributions: I know some distributions change the name of this file
downstream (i.e. via -DAPPLICATIONS_MENU_NAME=foo) to work around
aforementioned issues. Such workarounds should no longer be needed and
removed.

Cheers

Nico

Monday meeting notes for 09/10/2023

[Nicolas Fella]

Meven:

I am written the kcm wallpaper, it is progressing, it updates the any
screen wallpaper and display the screen layout
A bunch of things are left to do, hopefully will have a draft later this
week
And I will be merging the dbus backend

redstrate:

not much, just a leftover from last week:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1737. it's
the kaccess kcm UI refresh if anyone else can take a look at it

Xaver:

I merged the new output config system. Still have to port plasma mobile,
but other than that things are looking good
I made auto rotation adjust to the panel orientation for weird hardware:
https://invent.kde.org/plasma/kwin/-/merge_requests/4477.
kbroulik it would be great if you could test that
I'll look into implementing mirroring transforms in KWin and KScreen
this week
I tried to implement ICC profile support with some cut corners:
https://invent.kde.org/plasma/kwin/-/merge_requests/4471. It doesn't
seem to work though, so I'll take some time to try and do it properly

Arjen:

I've been doing some list item porting work
I also did a first MR for moving some bits of Kirigami into a submodule:
https://invent.kde.org/frameworks/kirigami/-/merge_requests/1319

then ran into an issue where types from that submodule wouldn't be found
if imported from another module and that module was imported with
different versions
in the end found that the declarative registration MR fixed that
oh also I have an MR up for qqc2-desktop-style to enable tooltips by
default for itemdelegates
https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/304

if anyone has opinions on that

Nico:

I did some API work on KService
(https://invent.kde.org/frameworks/kservice/-/merge_requests/165) and
KBookmarks
(https://invent.kde.org/frameworks/kbookmarks/-/merge_requests/39)
Since we want to move towards desktopfile based global shortcuts I added
infrastructure to migrate existing shortcuts:
https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/18
I investigated why the widgets explorer filter menu has broken menu item
names
Turns out to be a very cursed Qt bug:
https://bugreports.qt.io/browse/QTBUG-117922

Monday meeting notes for 25/09/2023

[Nicolas Fella]

redstrate:

I did some accessibility-related work, some of which is already merged:

I fixed a kaccess bug causing some options to become out of sync
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1736).
Redone the appearance of the accessibility KCM, so it looks a bit nicer.
(https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1737)
Added an accessibility page to plasma-welcome, letting users enable the
screen reader while setting up the system. I think this was suggested by
someone in Carl's accessibility BoF at akademy.
(https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/106)
Added "orca" (the screen reader we use) to the list of recommend
packages on the wiki, and now the Fedora KDE spin is looking to ship it
by default so that's nice!

Kai:

KDE will be at LinuxDay Vorarlberg this Saturday: https://www.linuxday.at/

Plasma:

Fixed System Monitor repaint issues caused by calling winId() on a
random widget, thanks Nico and d_ed
Polkit prompt can now be closed via Escape like a regular dialog
Kirigami:

Emulate header positioning of static header in GridView for
InlineViewHeader, please have a look:
https://invent.kde.org/frameworks/kirigami/-/merge_requests/1271
Frameworks:

Fixed KUrlNavigator focus problem, QAbstractButton::toggled is emitted
also for programmatic setChecked
Apps:

Fixed assert on teardown of terminal panel in Dolphin (“class destructor
may have already run“)
Fixed double close prompt bug in Kate/KWrite
turns out QCoreApplication::quit() closes all windows in Qt 6, before it
was like QCoreApplication::exit() which just exits the event loop
Fixed “compact” view in file dialog, only “icon” and “details” worked
Fixed Gwenview image rendering at fractional scale
Found a regression in Kolourpaint’s Undo/Redo button after my
KToolBarPopupAction changes, will fix.
Fix Hotspot not compiling against KF6 because of KNotification change
If you know someone who to poke about this fix:
https://github.com/KDAB/hotspot/pull/511

Oh, and found another FINAL property regression, this time in Qt itself…
https://codereview.qt-project.org/c/qt/qtdeclarative/+/506773

Fushan:

Improve keyboard navigation in systemsettings' sidebar:
https://invent.kde.org/plasma/systemsettings/-/merge_requests/256 and
https://invent.kde.org/frameworks/kirigami/-/merge_requests/1267
Add a test to make sure after the battery widget is split and the power
dataengine is ported, there will be no significant regression:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3323
(which requires the two fixes below)
Little battery fix for rich:
https://invent.kde.org/plasma/powerdevil/-/merge_requests/247
Workaround for questionable data from upower:
https://invent.kde.org/plasma/powerdevil/-/merge_requests/246
There is no binding loop/undefined warnings anymore in the
mediacontroller widget. And if in the future there is any, the test will
fail.
Fixed kdeplasma-addons CI, again

Xaver:

I'm banging my head against kscreen with
https://invent.kde.org/plasma/kwin/-/merge_requests/4431. It's ready for
testing, but some bits and pieces aren't working yet (like auto rotate
and the KScreen OSD)

I looked into making a Wayland protocol so that these global settings
can be applied together with output specific settings, but it would
require more changes in libkscreen than it's worth

Meven:

I 'd like to mention I have made progress
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3122
And now I am trying to build up a kcm.

Marco:

a fix for taskbar layout and animation glitches
fixes https://bugs.kde.org/396616
partially fixes https://bugs.kde.org/433256 (still broken on
non-expanding taskbars)
fixed blurry icons at fractional scaling in kirigami/plasma
doing some last runs of removing api that we don't want in 6.0 from kirigami
helping in chasing that 3.5 beta app launch bug
found an embrassing bug in folderview: if a folder is copied on the
desktop, all items in the folder, recursively get added to screen
mapping, affects 5.27 and 6
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1738 (and
partly explains the ginormous config files we get in appletsrc sometimes)

the screenmapper config must be nuked from orbit, but in the meantime,
let's fix as much as possible the current terrible one

Arjen:

so mostly wanted to mention that the new list item API in Kirigami has
been merged, which means anything using {Abstract,Basic}ListItem will
complain about it being deprecated

porting isn't necessarily straightforward as it really depends on the
usage, I'm planning on writing a more extensive tutorial about it, for
now there's several porting MRs that one can look at to see what needs
doing, like
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2948 and
https://invent.kde.org/plasma/systemsettings/-/merge_requests/257

Alex:

I have been working on KRunner optimizations, I discovered an issue in
kactivities-stats

KF6/Plasma 6 packaging notes

[Nicolas Fella]

Hi,

I'm happy that more and more distros are looking into packaging an
experimental KF6/Plasma 6 session. Since there are some non-obvious
things to keep in mind while doing that I started collecting some
packaging notes/information in
https://community.kde.org/Plasma/Plasma_6#Packaging_notes.

If there is anything unclear or you have ore useful information to add
feel free to ask here or edit the wiki directly.

Cheers

Nico

Porting aid place for Plasma stuff?

[Nicolas Fella]

Hi,

on several occasions we found API in Frameworks that we would like to
remove, but is still used in more than one place in Plasma and it may
not be feasible to port all of these usages in time for (Frameworks) 6.0.

There's a few things that fall in this category that come to my mind:

- KWayland: https://phabricator.kde.org/T11903#295217

- The drag and drop stuff in kdeclarative:
https://phabricator.kde.org/T12041#295298

- Plasma::Dialog:
https://invent.kde.org/frameworks/plasma-framework/-/issues/16

I would like to avoid a situation where we have to carry these all
throughout KF6 just because we miss to remove them before 6.0. An idea
that came up was to move them to somewhere in Plasma. There would be no
stability guarantee and we'd drop them as soon as they are no longer needed.

Assuming that's something we want to do I'm wondering what a good place
for those could be. plasma-workspace? plasma5support?
plasma-portingAidDumpingGround?

Thought?

Cheers

Nico

Re: Remaining plasma-framework KF6 tasks

[Nicolas Fella]

Am 09.07.23 um 12:56 schrieb Nicolas Fella:

Hi,

on the KF6 workboard there's a number of plasma-framework related tasks
that are still open. Some of them are actionable, others probably not or
need discussion.

I would appreciate if someone could go over the open tasks and triage
them, i.e. determine whether we consider them done, whether they are
still relevant, whether we need more discussion on it.

This helps us get a clear picture of what still needs to be done before
a potential 6.0 release of Frameworks/Plasma and thus helps with
planning our release timeline.

In particular I'd like input on these tasks:

- Split plasma-framework: https://phabricator.kde.org/T11642

- What to do with splitted frameworks: https://phabricator.kde.org/T12118

- qml imports plasma Core: https://phabricator.kde.org/T12117

- Discuss: QML scriptapplet plugin: https://phabricator.kde.org/T12111

- Deprecate Plasma::Theme https://phabricator.kde.org/T12108

- plasma-framework improvements / breaking changes:
https://phabricator.kde.org/T14954

The Plasma 6 board could use a similar cleanup.

If we need discussion on any of this we can organize a BBB meeting like
we have in the past.

Furthermore there's a number of "TODO KF6" comments in p-f code. Those
should be looked into as well

Remaining plasma-framework KF6 tasks

[Nicolas Fella]

Hi,

on the KF6 workboard there's a number of plasma-framework related tasks
that are still open. Some of them are actionable, others probably not or
need discussion.

I would appreciate if someone could go over the open tasks and triage
them, i.e. determine whether we consider them done, whether they are
still relevant, whether we need more discussion on it.

This helps us get a clear picture of what still needs to be done before
a potential 6.0 release of Frameworks/Plasma and thus helps with
planning our release timeline.

In particular I'd like input on these tasks:

- Split plasma-framework: https://phabricator.kde.org/T11642

- What to do with splitted frameworks: https://phabricator.kde.org/T12118

- qml imports plasma Core: https://phabricator.kde.org/T12117

- Discuss: QML scriptapplet plugin: https://phabricator.kde.org/T12111

- Deprecate Plasma::Theme https://phabricator.kde.org/T12108

- plasma-framework improvements / breaking changes:
https://phabricator.kde.org/T14954

The Plasma 6 board could use a similar cleanup.

If we need discussion on any of this we can organize a BBB meeting like
we have in the past.

Cheers

Nico

Moving print-manager and wacomtablet to Plasma

[Nicolas Fella]

Hi,

print-manager and wacomtablet are in a somewhat odd place currently.
They provide integration of (printers|tablets) into Plasma via KCMs,
kded modules, plasmoids etc, to the point where they are not that useful
outside of Plasma (technically they should mostly work outside of
Plasma, but it doesn't make a lot of sense UX-wise). Despite their close
alignment with Plasma they are not developed and released as part of
Plasma though. print-manager is part of Gear while wacomtablet is
independently releases (and hasn't had a release since 2019!).

While being slightly awkward this was mostly not an issue in the past,
but now with Plasma 6 on the horizon we have a challenge. To be useful
with Plasma 6 they need to be ported accordingly, and a ported version
needs to be released together with Plasma 6. Both projects build against
Qt6 already, but porting the applet requires larger changes that are
incompatible with Qt5/Plasma 5.

Given the close tie of both projects to Plasma I propose that we start
releasing them as part of Plasma beginning with Plasma 6.0 (and drop
print-manager from Gear at an appropriate time).

Thoughts?

Cheers

Nico

Plasma Sprint Topics

[Nicolas Fella]

Hi,

with the sprint all in order it's time to collect some topics.

Of course we don't want to pre-plan the whole week, and there will be
lots of time for free-form discussion and hacking, but having some
topics known from the start could help structure the whole thing a bit.

This is particularly relevant given that not all attendees will be there
for the whole week.

If you are not able to attend but would like to remotely join to discuss
a particular topic we can also arrange that. I think this has a much
higher chance of success than trying to bridge the whole event to the
internet.

If you have ideas for topics please add them to
https://community.kde.org/Sprints/Plasma/2023#Topics

Cheers

Nico

Re: Plasma Sprint 2023

[Nicolas Fella]

Am 02.04.23 um 17:09 schrieb Nicolas Fella:

Am 29.03.23 um 15:15 schrieb Nicolas Fella:

Am 16.03.23 um 17:38 schrieb Nicolas Fella:

Hi,

I guess we can all agree that it's high time for another Plasma Sprint.

We are in contact with Tuxedo, who kindly agreed to host us in their
office in Augsburg, Germany.

To find a suitable date I've created a poll, ranging from May to early
June. Please add yourself there so we can plan accordingly:

https://nuudel.digitalcourage.de/oHPocPKEPaz9ZExx

I was thinking of a week-long sprint, including the weekend, so that
people with busy workdays get a chance to at least partly attend.

If there is interest we can also discuss remote participation options.


Hi,

I'm happy to announce that we have a date and location for a sprint!

TUXEDO kindly agreed to host us in their offices in Augsburg, Germany
from 4.5. to 11.5.

Current plan is:

4.5.: Travel and some initial gathering.

5.5.-10.5.: Sprint

11.5.: Travel back and potentially more sprint/gathering


Please contact me (in private) if you are planning to attend. Please
include:

- Whether you want accommodation provided (there will be a group booking
for a hotel)

- When you will be traveling (so we can book accommodation accordingly)

- Any relevant accessibility needs, dietary restrictions/preferences, or
anything else we should be aware of when organizing

- Anything I, KDE e.V., or TUXEDO can do to help you attend (stuff like
Visa letters, local information, help with German bureaucracy)

Please also contact me if you filled out the poll and do *not* plan to
attend, so that I know not to chase after you, or if you would like to
join remotely. I cannot promise a good remote experience, but we can try
to make something work.

Remember that KDE e.V. will reimburse travel cost. We will add the event
to reimbursements.kde.org soon.


Hi,

the event is now available for reimbursements on
https://reimbursements.kde.org/events/167.

Please use this to get your travel costs reimbursed. For accommodation
we will do a group booking, so no need to include it in the
reimbursement request.

Please do the travel support request *and* let me know whether you plan
to attend and whether you need accommodation as soon as possible so we
can plan accordingly.


Hi,

I have now booked accommodation for those who told me they need it.

If I haven't contacted you to confirm that I have booked for you and you
had told me you need accommodation please contact me asap.

If you haven't requested accommodation and still need it then please
book it for yourself (e.g.
https://www.hotel-bb.com/en/hotel/augsburg-sued) and request
reimbursement via reimbursements.kde.org.

If you plan to attend but do not need accommodation please tell me.

Cheers

Nico

Re: Plasma Sprint 2023

[Nicolas Fella]

Am 29.03.23 um 15:15 schrieb Nicolas Fella:

Am 16.03.23 um 17:38 schrieb Nicolas Fella:

Hi,

I guess we can all agree that it's high time for another Plasma Sprint.

We are in contact with Tuxedo, who kindly agreed to host us in their
office in Augsburg, Germany.

To find a suitable date I've created a poll, ranging from May to early
June. Please add yourself there so we can plan accordingly:

https://nuudel.digitalcourage.de/oHPocPKEPaz9ZExx

I was thinking of a week-long sprint, including the weekend, so that
people with busy workdays get a chance to at least partly attend.

If there is interest we can also discuss remote participation options.


Hi,

I'm happy to announce that we have a date and location for a sprint!

TUXEDO kindly agreed to host us in their offices in Augsburg, Germany
from 4.5. to 11.5.

Current plan is:

4.5.: Travel and some initial gathering.

5.5.-10.5.: Sprint

11.5.: Travel back and potentially more sprint/gathering


Please contact me (in private) if you are planning to attend. Please
include:

- Whether you want accommodation provided (there will be a group booking
for a hotel)

- When you will be traveling (so we can book accommodation accordingly)

- Any relevant accessibility needs, dietary restrictions/preferences, or
anything else we should be aware of when organizing

- Anything I, KDE e.V., or TUXEDO can do to help you attend (stuff like
Visa letters, local information, help with German bureaucracy)

Please also contact me if you filled out the poll and do *not* plan to
attend, so that I know not to chase after you, or if you would like to
join remotely. I cannot promise a good remote experience, but we can try
to make something work.

Remember that KDE e.V. will reimburse travel cost. We will add the event
to reimbursements.kde.org soon.


Hi,

the event is now available for reimbursements on
https://reimbursements.kde.org/events/167.

Please use this to get your travel costs reimbursed. For accommodation
we will do a group booking, so no need to include it in the
reimbursement request.

Please do the travel support request *and* let me know whether you plan
to attend and whether you need accommodation as soon as possible so we
can plan accordingly.

Cheers

Nico

Re: Plasma Sprint 2023

[Nicolas Fella]

Am 16.03.23 um 17:38 schrieb Nicolas Fella:

Hi,

I guess we can all agree that it's high time for another Plasma Sprint.

We are in contact with Tuxedo, who kindly agreed to host us in their
office in Augsburg, Germany.

To find a suitable date I've created a poll, ranging from May to early
June. Please add yourself there so we can plan accordingly:

https://nuudel.digitalcourage.de/oHPocPKEPaz9ZExx

I was thinking of a week-long sprint, including the weekend, so that
people with busy workdays get a chance to at least partly attend.

If there is interest we can also discuss remote participation options.


Hi,

I'm happy to announce that we have a date and location for a sprint!

TUXEDO kindly agreed to host us in their offices in Augsburg, Germany
from 4.5. to 11.5.

Current plan is:

4.5.: Travel and some initial gathering.

5.5.-10.5.: Sprint

11.5.: Travel back and potentially more sprint/gathering


Please contact me (in private) if you are planning to attend. Please
include:

- Whether you want accommodation provided (there will be a group booking
for a hotel)

- When you will be traveling (so we can book accommodation accordingly)

- Any relevant accessibility needs, dietary restrictions/preferences, or
anything else we should be aware of when organizing

- Anything I, KDE e.V., or TUXEDO can do to help you attend (stuff like
Visa letters, local information, help with German bureaucracy)

Please also contact me if you filled out the poll and do *not* plan to
attend, so that I know not to chase after you, or if you would like to
join remotely. I cannot promise a good remote experience, but we can try
to make something work.

Remember that KDE e.V. will reimburse travel cost. We will add the event
to reimbursements.kde.org soon.

Looking forward to seeing you in Augsburg!

Cheers

Nico

Re: kpipewire and sddm theme in plasma6

[Nicolas Fella]

Am 25.03.23 um 19:47 schrieb Harald Sitter:

and breeze widget style that will need to be available for qt5 :(

On Fri, Mar 24, 2023 at 10:29 AM Harald Sitter  wrote:

Ciao

It occurred to me that we have some compatibility problems coming up.
Notably the sddm login theme (which is used by sddm - may be Qt5) and
kpipewire (used by spectacle - also may be Qt5)

Has anyone pondered these?

HS


Breeze is known and handled. breeze master supports building for Qt5.

SDDM is presumably easy to solve. We only need to support whatever major
version SDDM currently uses. Though we will have a bit of a challenge
when SDDM switches.

kpipewire and spectacle is a bit tricky. Either we make kpipewire
support both and make it coinstallable, or release Qt6 Spectacle
together with Plasma 6. We probably need some coordination between
Plasma and Gear there anyway

Ping: Plasma Sprint 2023

[Nicolas Fella]

On 3/16/23 17:38, Nicolas Fella wrote:

Hi,

I guess we can all agree that it's high time for another Plasma Sprint.

We are in contact with Tuxedo, who kindly agreed to host us in their
office in Augsburg, Germany.

To find a suitable date I've created a poll, ranging from May to early
June. Please add yourself there so we can plan accordingly:

https://nuudel.digitalcourage.de/oHPocPKEPaz9ZExx

I was thinking of a week-long sprint, including the weekend, so that
people with busy workdays get a chance to at least partly attend.

If there is interest we can also discuss remote participation options.


Hi,

thanks for the poll responses so far. I'm still missing responses from a
few Plasma faces. Please try to do that soon so that we can finalize a
date and plan ahead.

If you are interested in joining but are unsure whether you are
"qualified" enough: Yes you are.

KDE e.V. will reimburse travel/accommodation cost, so don't let that
prevent you from coming.

Cheers

Nico

Re: Plasma repositories sprint cleaning

[Nicolas Fella]

Hi,

ksysguard, kwayland-server, plasma-active-window-control,
plasma-redshift-control, and plasma-tests are now archived.


On Fri, Mar 3, 2023 at 1:45 PM Nicolas Fella  wrote:

- khotkeys: consensus seems to be to abandon it, because maintaining two
global shortcut systems is no joy: https://phabricator.kde.org/T2050.
It's still released with 5.27 though

How do we go for epos that are part of 5.27 but won't be on 6? anyways
yeah, let's yank it from 6. repo should still be there for 5.27
maintenance mode tho


An option that has been discussed for frameworks with a similar
situation is clearing the master branch (except for a readme) but
leaving the release branches intact.

Cheers

Nico

Plasma Sprint 2023

[Nicolas Fella]

Hi,

I guess we can all agree that it's high time for another Plasma Sprint.

We are in contact with Tuxedo, who kindly agreed to host us in their
office in Augsburg, Germany.

To find a suitable date I've created a poll, ranging from May to early
June. Please add yourself there so we can plan accordingly:

https://nuudel.digitalcourage.de/oHPocPKEPaz9ZExx

I was thinking of a week-long sprint, including the weekend, so that
people with busy workdays get a chance to at least partly attend.

If there is interest we can also discuss remote participation options.

Cheers

Nico

Re: Plasma repositories spring cleaning

[Nicolas Fella]

Am 03.03.23 um 13:45 schrieb Nicolas Fella:

Hi,

while porting Plasma repos to Qt6 I've come across several repos in the
plasma/ namespace on invent that I found questionable:

- khotkeys: consensus seems to be to abandon it, because maintaining two
global shortcut systems is no joy: https://phabricator.kde.org/T2050.
It's still released with 5.27 though

- ksysguard: We stopped releasing/maintaining it several releases ago.
Not part of any supported release. Could be archived?

- kwrited: The functionality is kind of old/niche. Is it worth having at
all? If yes, given it is quite tiny, would it make sense to fold it into
plasma-desktop instead of having it separate?

- kwayland-server: Obsolete implementation detail. Not released any
more. Can probably be archived now

- lancelot: An alternative Plasma launcher. No releases, not much
activity in recent years. If anyone cares about it it might be better of
maintained outside of KDE to avoid impression that it is "officially"
supported

- plasma-active-window-control: No release, a little activity in recent
times. What do we do with it?

- plasma-redshift-control: No releases. Does this provide anything
interesting compared to the "official" night color stuff?

- plasma-simplemenu: Had releases in the past, but last one is from 4
years ago. Semi-active recently. Might be worth incorporating into
proper Plasma release?

- plasma-tests: Is this useful at all?

- smaragd: Last release 5 years ago. Not a whole lot of activity since
then. Make it part of the proper Plasma release or kill it?


I'm asking this mainly to see what "needs" to be ported to Qt6/Plasma6,
but I also think it's important to have a clear messaging about what we
as a "Plasma Team" properly support and what is on a best-effort basis
by whoever feels like supporting it.

By "sprint cleaning" I mean "spring cleaning" of course. That said I'm
desperate for a Plasma Sprint soon ;-)

Plasma repositories sprint cleaning

[Nicolas Fella]

Hi,

while porting Plasma repos to Qt6 I've come across several repos in the
plasma/ namespace on invent that I found questionable:

- khotkeys: consensus seems to be to abandon it, because maintaining two
global shortcut systems is no joy: https://phabricator.kde.org/T2050.
It's still released with 5.27 though

- ksysguard: We stopped releasing/maintaining it several releases ago.
Not part of any supported release. Could be archived?

- kwrited: The functionality is kind of old/niche. Is it worth having at
all? If yes, given it is quite tiny, would it make sense to fold it into
plasma-desktop instead of having it separate?

- kwayland-server: Obsolete implementation detail. Not released any
more. Can probably be archived now

- lancelot: An alternative Plasma launcher. No releases, not much
activity in recent years. If anyone cares about it it might be better of
maintained outside of KDE to avoid impression that it is "officially"
supported

- plasma-active-window-control: No release, a little activity in recent
times. What do we do with it?

- plasma-redshift-control: No releases. Does this provide anything
interesting compared to the "official" night color stuff?

- plasma-simplemenu: Had releases in the past, but last one is from 4
years ago. Semi-active recently. Might be worth incorporating into
proper Plasma release?

- plasma-tests: Is this useful at all?

- smaragd: Last release 5 years ago. Not a whole lot of activity since
then. Make it part of the proper Plasma release or kill it?


I'm asking this mainly to see what "needs" to be ported to Qt6/Plasma6,
but I also think it's important to have a clear messaging about what we
as a "Plasma Team" properly support and what is on a best-effort basis
by whoever feels like supporting it.

Cheers

Nico

Plasma master switches to Qt6

[Nicolas Fella]

Hi,

The master branch for Plasma repos will be made Qt6-only tomorrow,
28.02.2023.

There will be disruption because of this. While we aim for getting a
basic workspace running as soon as possible non-essential functionality
might be broken for a while.

Existing kdesrc-build setups will be switched to building Plasma from
the Plasma/5.27 branch to keep things building with Qt5. Make sure your
.kdesrc-buildrc contains "branch-group kf5-qt5".

You can build the Qt6/master version by specifying the "kf6-qt6" branch
group.

Cheers

Nico

Splitting KGlobalAccel interface and runtime

[Nicolas Fella]

Hi,

the kglobalaccel framework currently contains two pieces: kglobalacceld,
the runtime component that manages global shortcuts, and an
application-side library to interact with it.

The two communicate with each other via DBus. On X11 there is a
standalone kglobalacceld5 process providing the interface, on Wayland
the runtime is linked into KWin and thus the kwin_wayland process
provides the interface.

The current architecture has a number of downsides:

- Any call to the KGlobalAccel library may DBus-activate the
kglobalacceld5 process, which may be undesired on Desktop other than
Plasma since it competes with their native shortcut system. We tried
fixing that by making such calls no-op on !Plasma, but that broke things
for people that did want it to run, for example people using KWin with
LXQt, because KWin relies on KGlobalAccel for shortcuts

- We want to keep the dependencies of the interface library minimal,
which is inconvenient for the development of the runtime part. For
example we really want to use KIO::ApplicationLauncherJob in the
runtime, but currently can't, because that would introduce a dependency
cycle in Frameworks (KIO depends on KXmlGui, which depends on
KGlobalAccel, which would depend on KIO)

- Coinstallability of KF5 and KF6. Conceptually there can only be one
kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install a
kglobalacceld this is going to be problematic. This also means that a
KF6-based kglobalacceld must work with a KF5 interface library

- Other shortcut daemon implementations. Since somewhat recently there
is an XDG Portal for global shortcuts. Platforms like Windows and macOS
also have ways for applications to register global shortcuts. While we
are currently not using any of these it's very well possible that we
would eventually want to use the KGlobalAccel interface library to
interact with those. Having the kglobalacceld runtime in the same
frameworks therefore doesn't feel right.

To address these issues I suggest we split out the runtime part of
kglobalaccel into its own project, under the Plasma release group,
because that's primarily where it's used/supported. The interface
library would remain in frameworks. We have a similar situation with
activities, where the manager (kactivitymanagerd) is in Plasma and the
interface is in Frameworks. When doing this we'd also change the way how
kglobalacceld is started away from DBus activation towards explicitly
starting it as part of the Plasma startup. This avoids accidentally
launching it when it shouldn't be but still allows to explicitly start
outside of Plasma if really wanted. It would also allow for greater
flexibility in the development of the runtime, especially around
dependency constraints.

It wouldn't automatically solve the coinstallability problem of KF5 and
KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still
conflict with a Plasma-provided kglobalacceld, but it's at least
conceptually less messy since it's clear that the Plasma-provided one
would be the preferred one to use.

Thoughts about this?

Cheers

Nico

Monday meeting notes for 07/11/2022

[Nicolas Fella]

David E:
nothing

Arjen:
so I'm looking into some kwin performance related things, currently
focusing on activation lag when activating the window view effect from
the taskbar
which has lead me to a deep dive into framesvg and related things in plasma
as qml profiling showed that creating PC3 buttons was taking around 5ms each
I'm collecting a bunch of things in
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/645

Xaver:
I did a bunch of work on my Wayland fractional scaling proposal. Seems
to work well with glfw, next step is to implement it for a more complex
client or toolkit, like Qt
I can hopefully complete the screen tearing stuff for Wayland this week
And I've been working on hardware rotation for KWin. amdgpu is horribly
broken with it though, so it might not be going anywhere for a while

Kai:
Did a blog post about some of the performance stuff I did in recent
months: https://blog.broulik.de/2022/11/performance-musings/
Notifications:
Explicitly uncheck paused button, please review
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2302
Use "0" for null percent, please review
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2301
KRunner:
Add tooltip for main text, please review
https://invent.kde.org/plasma/milou/-/merge_requests/48
KFileMetadata:
Did a bunch of fixes, improvements, test coverage, etc
Added support for "Flat XML" open document files
Added FictionBook2 extractor
KWin:
Nightcolormanager is less chatty on DBus now
Fixed test failure on FreeBSD with F_SEAL_WRITE
FreeBSD allows mmap with PROT_READ on F_SEAL_WRITE, Linux does not

Vlad:
Made kwin build with -Wno-unused-parameter. It suited the stuff that we
have in kwin, maybe it's also worth using in other plasma projects?
wayland-protocols 1.28 has been released. I would like to land
xwayland-shell-v1 soon-ish, when CI lets us to do so
I did some stuff with fractional geometry, i.e. moved from QRegion to
StrutRects. I also created a patch to use floating point geometry more,
but I would like to have another pair of eyes to check that it's correct
I need a poor soul or two to review my X11Window and OutputBackend patches

Fushan:
Backported a QQuickWidget a11y fix to kde/5.15, so a screen reader can
read text in system settings.
Allow a screen reader to read notifications, second attempt:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2295
Port yet another DropArea:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1232

Nico:

Fix crash in KWordQuiz:
https://invent.kde.org/education/kwordquiz/-/merge_requests/19
Fix non-global shortcuts appearing in kwin effect config:
https://invent.kde.org/plasma/kwin/-/merge_requests/3141
https://invent.kde.org/plasma/kwin/-/merge_requests/3142
Fix i18n in tablet KCM:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1225
Add Touchscreen KCM that allows to configure properties of touchscreen:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1227
Some cleanup/deprecation/renaming in KIO:
https://invent.kde.org/frameworks/kio/-/merge_requests/1020
https://invent.kde.org/frameworks/kio/-/merge_requests/1021
https://invent.kde.org/frameworks/kio/-/merge_requests/1022
https://invent.kde.org/frameworks/kio/-/merge_requests/1023
Fix devices leaking in tablet KCM:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1228
Some more Qt6 porting/cleanup
Deprecate some unused functions in KWindowSystem
Extract X11-specific functions of KWindowSystem into new KX11Extras
class: https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/72

New bugfix release for plasma-workspace

[Nicolas Fella]

Hi,

Plasma 5.25 has no planned releases any more, but the Plasma/5.25 branch
in plasma-workspace has accumulated two fixes for somewhat important
bugs (https://bugs.kde.org/show_bug.cgi?id=458829 and
https://bugs.kde.org/show_bug.cgi?id=458865). The former is a regression
introduced in 5.25.5. Instead of hoping distros will apply those
themselves I propose we make a 5.25.5.1 release for plasma-workspace.

Cheers

Nico

Re: testing UIs and improving a11y all at once!

[Nicolas Fella]

Am 10.08.22 um 12:29 schrieb Harald Sitter:

Servus,

A while ago I prototyped a "new" approach to UI testing and I'm
wondering if there's general interest in doing more Plasma testing
using it. I'm able to invest time in polishing the experience for us.

Very rough prototype: https://invent.kde.org/sitter/selenium-webdriver-at-spi

The testing is run through the accessibility API we have on Linux
https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ as well as the
testing API selenium https://www.selenium.dev/ respectively the more
specific appium https://appium.io/

Architecturally appium is an extension to selenium and selenium is a
client-server system where the client is the test and the server is a
so called webdriver. Webdriver is a standardized well-defined API of
various UI interactions https://www.w3.org/TR/webdriver/ and we'd
implement one based on the a11y APIs (the feature sets match fairly
well).

Since selenium has wide spread use across the industry we get to use
excellent tooling on the client without any extra work from us. And
because it is so wide spread the stuff is generally very well
maintained. All we need to maintain is the webdriver that interacts
with the a11y API.

The way this type of testing works is by UI interaction and state
validation. There is a kcalc test available in the prototype repo [1]
- the test operates the various UI elements to perform a calculation
and then checks that the output UI element contains the expected
value.

A simple plasma test might open kickoff, and launch one of the
favorites, then validate that indeed a new window has opened.

Since all this is driven by the a11y API there is the additional
advantage of making us notice a11y problems and deal with them,
resulting in bettery a11y support in the long run. Two birds, one
stone!

What do you reckon?

[1] 
https://invent.kde.org/sitter/selenium-webdriver-at-spi/-/blob/91486b50995ade23c6b03a54f77347c263c2f03a/calculatortest.py

HS


+energy-efficie...@kde.org

Servus Harald,

that looks very cool!

It could also come in handy for energy consumption measurements where we
need an automated and predictable way to emulate user interaction.

The idea of using a11y API for that came up, but AFAIK there's no work
to actually do it on our side.

That's three birds one stone I guess?

Cheers

Nico


PS: I pondered about different ways to do GUI automation for energy
consumption measurements in my master thesis recently, but I left the
a11y way for future work. If you are interested you can find the thesis
at https://nx9294.your-storageshare.de/s/PDQK4DEyPMW8AHM

Re: Latte Dock Farewell

[Nicolas Fella]

On 7/27/22 13:14, Aleix Pol wrote:

On Wed, Jul 27, 2022 at 12:15 PM Jonathan Riddell  wrote:

Michail has announced he's not going to be developing Latte Dock in future
https://psifidotos.blogspot.com/2022/07/latte-dock-farewell.html
Thanks for all your work Michail!

As far as we can tell Latte Dock is a popular Plasma addon.  If anyone is 
looking for a project to take on this is your chance.

Otherwise I expect it'll stop working before too long as it uses various 
private APIs so we'll need to tell distros to stop shipping it when it does.

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

Aleix


I think it could make sense to add Latte to the regular Plasma release,
for the following reasons:

 - It gives us regular releases "for free", which makes sure that
occasional fixes/improvements actually reach users. It would be a shame
if those never see the users because no one feels responsible enough to
make a release

- Having Plasma and Latte in sync helps with the private API problem
since a release of Latte has to only support one Plasma release. See
e.g. the recent KPipeWire topic where Plasma wanted to remove things
Latte uses.

Re: C++/library requirements for Plasma 5.26

[Nicolas Fella]

On 07/07/2022 14:08, Nicolas Fella wrote:

Hi,

for Plasma 5.26 I would like to make use of some C++20 features, in
particular coroutines.

In terms of compiler requirements this should translate to requiring GCC
10 or Clang 11.

In addition we would like to require the qcoro library
(https://github.com/danvratil/qcoro). As per
https://github.com/danvratil/qcoro/issues/85 the library can be
considered stable and is regularly released.

Is there any distribution that plans to ship Plasma 5.26 that cannot
fulfill these requirements?

To test whether your system provides the necessary bits you can try
building
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1023 or
https://invent.kde.org/plasma/plasma-nm/-/merge_requests/124

Let me know of there are any problems with this plan.

Cheers

Nico


Ignoring the question of coroutines for a moment. I have not seen any
objections against the compiler version requirements proposed.

Unless someone objects to this soon I'd like to at least formalize that
part.

Cheers

Nico

Re: C++/library requirements for Plasma 5.26

[Nicolas Fella]

On 07/07/2022 19:24, Ivan Čukić wrote:

You might very well not be reading this correctly, as it's phrased very
ambiguously:

Very likely. It is just that the ambiguous wording with the conclusion
didn't give me the confidence of the quality of implementation.


However, C++20 also brought dozens of smaller language and library
improvements that have been working just fine in both Clang and GCC even

Yes, many library features C++20 brought are nice gems. :)


Ok, building and possibly also *testing* ;-)

Tests for async things are usually not that good/exhaustive even
for normal code that doesn't deal with experimental compiler
features.

If we go for coroutines, I'd just advise a slower and well-planned
adoption then - use it in a smaller, but often used part, and then
go from there. (I hate advocating slow adoption of something this
cool, but... :) )


We have some experience using coroutines in Plasma Mobile apps, and I
don't remember obvious problems. But granted, most of the time those
apps are built with gcc, not clang.


Cheers,
Ivan

C++/library requirements for Plasma 5.26

[Nicolas Fella]

Hi,

for Plasma 5.26 I would like to make use of some C++20 features, in
particular coroutines.

In terms of compiler requirements this should translate to requiring GCC
10 or Clang 11.

In addition we would like to require the qcoro library
(https://github.com/danvratil/qcoro). As per
https://github.com/danvratil/qcoro/issues/85 the library can be
considered stable and is regularly released.

Is there any distribution that plans to ship Plasma 5.26 that cannot
fulfill these requirements?

To test whether your system provides the necessary bits you can try
building
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1023 or
https://invent.kde.org/plasma/plasma-nm/-/merge_requests/124

Let me know of there are any problems with this plan.

Cheers

Nico

Re: Parent windows for system dialogs

[Nicolas Fella]

On 6/29/22 09:10, Vlad Zahorodnii wrote:

On 6/29/22 01:35, Nicolas Fella wrote:

Hi,

we have several places where we have "system" dialogs that don't have a
"real" parent window. Examples would be stuff like KWallet, network
management, or anything spawned by kded where there's no corresponding
app window. Currently, at least on Wayland, they are placed
semi-randomly on the screen, which isn't particularly nice. See e.g.
https://bugs.kde.org/show_bug.cgi?id=456060. They probably should be
centered in the/a screen.


It's odd. With the default placement policy (centered) "orphan" dialog
windows should be centered on Wayland.


With Centered placement policy they seem to be centered indeed. With
"Minimal Overlapping" they appear in some corner though

Parent windows for system dialogs

[Nicolas Fella]

Hi,

we have several places where we have "system" dialogs that don't have a
"real" parent window. Examples would be stuff like KWallet, network
management, or anything spawned by kded where there's no corresponding
app window. Currently, at least on Wayland, they are placed
semi-randomly on the screen, which isn't particularly nice. See e.g.
https://bugs.kde.org/show_bug.cgi?id=456060. They probably should be
centered in the/a screen.

Usually the centering would be achieved by setting  a parent window, but
in that case there isn't an obvious one. What should we do in that case?
Set the parent window to some magic Plasma window? Special-case this in
KWin somehow? Something else entirely?

Cheers

Nico

Re: [GSoC Draft proposal] Redesign system settings modules by porting them to QtQuick

[Nicolas Fella]

Hi,

On 3/31/22 19:04, Smit Patil wrote:

Hello all,
I'm looking for potentials mentors for GSoC 2022 to review/comment my
draft proposal
for this task:-
https://community.kde.org/GSoC/2022/Ideas#Plasma_modernise_system_settings_modules


I think for the Font Management KCM there was a conclusion that we would
remove that from systemsettings and have it as a standalone application
instead, so porting to QML isn't strictly necessary.

For the KWin Scripts KCM Alex is already working on a port:
https://invent.kde.org/plasma/kwin/-/commits/work/alex/scripts_qml_tmp

As for the proposal itself: It's currently a bit superficial, merely
saying port X in week Y. Maybe you could add a bit more detail about
what kind of challenges there might be while porting?

Cheers

Nico

Monday Meeting Notes for 28/3/2022

[Nicolas Fella]

Marco:

Wayland:
Merged realtime screen edges support
touch friendly changes for Overview

Breeze:
More tablet mode friendlyness for breeze qstyle, change on the fly and
enlarge many controls
https://invent.kde.org/plasma/kwin/-/merge_requests/2168

https://invent.kde.org/plasma/breeze/-/merge_requests/202

Alex:

Been mostly working on
https://invent.kde.org/frameworks/kcmutils/-/merge_requests/84, I had
quite a few issues with the QML parts and have spend way too much time
on it already :(.

I would appreciate feedback on how to improve the API (mostly thinking
about d_ed who helped me out already with it)
Fixed the KNewStuff issues with the server rejecting the connection on
certain locales (BUG: 451165).
And also ported plasma-workspace to use the KNS enums or the status
codes,
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1595. I
will work on a few more KF6 related stuff for KNewStuff this week

Further work on the Dataengine ports:
https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/127
Please check my comment there with the issues of the different release
cycles.

David R:

I have been thinking about KColorScheme and not storing colors in kdeglobals
I think it's possible in KF5 time even
would be guarded behind a new constructor
With some kind of fallback if you are running older plasma
Let's see if it works out

Arjen:

I've mostly been off to maliit land last week, working on some virtual
keyboard stuff
though I did manage to get the exclude device for tablet mode stuff
merged into kwin, so we can eventually have the steam deck report tablet
mode properly
also one small but important fix in maliit is that it will now re-show
if you tap on a textfield while you manually hid the keyboard
also I wouldn't mind a review of
https://invent.kde.org/plasma/breeze/-/merge_requests/200

Aleix:

Global Shortcuts
Worked more on the global shortcuts portal proposal. There's a PoC
available now.
This includes adding support to released shortcuts in KGlobalAccel,
which should allow implementing Push-to-talk kind of patterns.
There's a shitload of MRs for y'all, I'd appreciate it if you can look
at them. There's the ones less directly related to the portal itself
(i.e. the PTT in kglobalaccel), if we can parallelise that, that would
be great too although I understand the use-case hasn't really been there
before.
KWin
Fixed (wrongly) a bug we have when unlocking the screen that makes our
session go all flickery, disco-style. Still unsure how to properly fix
it. https://invent.kde.org/plasma/kwin/-/merge_requests/2188#note_422260
Discover
Saw some problems pile up a bit, I started looking into them. Nothing
super interesting going on.

Fix unlocking wayland sessions (!2188)
One notable problem in Discover is wrt apt+packagekit
if someone knows an upstream apt dev, please get them in touch with us
and hopefully we can address it
(regarding apt sometimes failing and leaving the db unusable then asking
users to run a dark jedi command)

Kai:

Plasma:

Fixed media controller initial position being zero sometimes
You cannot set value > to in QQC2 Slider, so set to to the correct value
before
KWin:

Now supports rendering a transparent (rather than black) back-drop
If KColorscheme wasn't in KConfigWidgets, we could probably drop KWin's
dep on it and KWidgetsaddons :(
Dolphin:

Fixed applying default view properties
e.g. Search view was meant to have a "Path" column by default
Added a bunch new custom default view mode presets for e.g. different
search modes
Not often you get to close a bug in the 1x, 3x, 4x range in
the same commit :D

Nico:

Some performance improvements in Plasma when dealing with lots of
notifications:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1596
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1597
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1598
I have some more ideas, but needs more thinking

Performance improvements for Dolphin tooltips:
https://invent.kde.org/system/dolphin/-/merge_requests/364

Reuse metadata widget when creating tooltips (!364)
Show "KDE" instead of "Unknown author" in discover for our apps without
explicit author name
Perf improvement in KFilePlacesModel:
https://invent.kde.org/frameworks/kio/-/merge_requests/792

Been investigating a weirdness in the battery applet, lead me to file
https://github.com/flatpak/xdg-desktop-portal/issues/745

[Powerdevil] [Bug 359142] powerdevil ignores "even when external monitor connected" option

[Nicolas Fella]

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

Nicolas Fella  changed:

   What|Removed |Added

 CC||nicolas.fe...@gmx.de
 Resolution|--- |WORKSFORME
 Status|REOPENED|RESOLVED

--- Comment #10 from Nicolas Fella  ---
(In reply to Vytautas from comment #9)
> I was able to reproduce this on Arch with Plasma 5.23.5. Curiously, for me
> this only happens on Wayland while X11 works fine.

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

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

Plasma 6 Kickoff sprint

[Nicolas Fella]

Hi,

recently there was some discussion on Plasma 6 branching/timeline. At
the KF6 meeting we figured it would help finding a timeline if we had
some discussion on what kind of (architectural) changes we want to make.

I know that Marco has some ideas in particular around plasma-framework
and applets, and I'm sure others have other ideas worth discussing.

Therefore I'd suggest we have a Plasma 6 Kickoff Sprint (pun intended)
sometime soon. Date and everything to be discussed. Given _vaguely
gestures at everything_ I don't see us doing a physical one though, sadly.

Thoughts?

Cheers

Nico

Re: Next Plasma LTS?

[Nicolas Fella]

On 1/10/22 12:51, David Edmundson wrote:

The last 5.X release definitely needs to be an LTS. That's unmovable.
We can't have two active LTSs, it'd be a backporting nightmare and at
best it would be a lie to claim we're actively supporting both.

An LTS now effectively means we can't start Plasma 6 for another year.
I personally think that's too late we're at a point where some people
are building certain plasma repos against Qt6 already.

I can envision Plasma 5.25 being the last before branching.


I think that's a bit too early. It also heavily depends on how the KF6
work is going to go where we don't really have a concrete timeline yet.

Cheers

Nico

[plasmashell] [Bug 447389] Notifications widget in the system tray shows items that are not clickable

[Nicolas Fella]

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

Nicolas Fella  changed:

   What|Removed |Added

  Component|general |Notifications
Product|kwrited |plasmashell
   Assignee|plasma-devel@kde.org|k...@privat.broulik.de
   Target Milestone|--- |1.0
 CC||nicolas.fe...@gmx.de,
   ||plasma-b...@kde.org

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

Re: Gitlab CI - Inbound

[Nicolas Fella]

On 05.09.21 08:13, Ben Cooksley wrote:

Hi all,

This morning after much work i'm happy to announce that the new
generation CI scripts intended for use with Gitlab CI successfully
completed their first build (of ECM, and then subsequently of
KCoreAddons).

This begins our first steps towards transferring CI over from Jenkins
to Gitlab.

These scripts are 'Gitlab native' and are designed to work in an
environment where they will be running on merge requests, tags as well
as all branches of our repositories - something the existing scripts
were completely incompatible with. While there are still some
infrastructural elements to put in place (such as 'seed jobs' to mass
rebuild all projects after substantial changes and 'cleanup jobs' to
remove old builds from the Package Registry) the core elements needed
for initial testing of these scripts are now ready.

For those curious, the results of those initials runs can be found at
https://invent.kde.org/groups/teams/ci-artifacts/-/packages


Due to the challenges associated with having to handle all of the
different forms of build and the versioning of this information, these
scripts also represent a radical change in how CI builds will be
conducted - with a large part of the configuration of the jobs
themselves, including information on project dependencies now shifting
to files located within the repository themselves. Those who monitor
commits to Frameworks repositories will have noticed the appearance of
these '.kde-ci.yml' files in some repositories.

To assist in the future rollout of the CI system it would be
appreciated if projects could please begin setting up these files
within their respective repositories.
You can find a template detailing the available options at
https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml


Where possible please avoid overriding the system defaults except
where needed by your project (ie. don't just copy the template in full)
The defaults mirror the template and can be found at
https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml


In terms of the format of the 'Dependencies' section, please bear in
mind the following:
- For the 'on' section, the special value '@all' can be used to mean
"All platforms" to avoid needing to update the file in the event
additional platforms are added in the future
- For the 'require' section:
  1) Please only include the projects you *explicitly* depend on.
Dependencies of your dependencies will be included automatically
  2) When specifying a project, you must use the repository path on
Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop)
are no longer in use and will not work.
  3) There are three special values for the branch name - '@same',
'@latest' and '@stable' which can be used to refer to the branch/tag
of a dependency.
  '@same' means the branch name should be the same as that of the
project being built and should be used when declaring dependencies
among projects in a release group.
  '@latest' and '@stable' refer to the corresponding branches
defined in the branch-rules.yml file, which can be found in
sysadmin/repo-metadata

As a general rule, unless you require the absolute latest version of
another project in another release unit, it is recommended that you
use @stable.
Please avoid using explicit branch names unless absolutely necessary.

At this time it is expected that the first set of Gitlab CI builds
using the new scripts may be conducted for Frameworks within the next
week or so, assuming the build of the seed jobs goes according to plan.

Once the scripts have been proven successfully for Frameworks, we will
look at extending them to projects that depend only on Frameworks and
repositories within their release unit and finally will extend them to
projects with more complex dependency requirements. It is expected
that the switch will be flipped on the Frameworks builds sometime in
the next week or two.

Please let me know if you have any questions on the above.

Thanks,
Ben Cooksley
KDE Sysadmin


Hi Ben,

thanks for your work on this!

How would I best encode a dependency like "On Linux and FreeBSD depend
on kwayland, but not on Windows and macOS"?

Cheers

Nico

Re: polkit-kde-agent-1 build failure

[Nicolas Fella]

Hi,

Should be fixed with
https://invent.kde.org/libraries/polkit-qt-1/-/merge_requests/18


On 26/08/2021 13:19, Jonathan Riddell wrote:

I wonder if anyone has ideas on a build failure I'm getting in
polkit-kde-agent-1

https://build.neon.kde.org/job/focal_stable_kde_polkit-kde-agent-1_bin_amd64/44/console


There haven't been any changes in the git repo since the last
successful build which suggests its due to update in ubuntu but I've
not been able to track that down.

[ 54%] Building CXX object
CMakeFiles/polkit-kde-authentication-agent-1.dir/polkit-kde-authentication-agent-1_autogen/mocs_compilation.cpp.o
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtGui/qwindowdefs.h:44,
from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qwidget.h:44,
from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qdialog.h:44,
from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/QDialog:1,
from
/home/jr/src/kde/polkit-kde-agent-1/kdegit/polkit-kde-agent-1/AuthDialog.h:26,

from
/home/jr/src/kde/polkit-kde-agent-1/kdegit/polkit-kde-agent-1/build/polkit-kde-authentication-agent-1_autogen/EWIEGA46WW/moc_AuthDialog.cpp:10,

from
/home/jr/src/kde/polkit-kde-agent-1/kdegit/polkit-kde-agent-1/build/polkit-kde-authentication-agent-1_autogen/mocs_compilation.cpp:2:

/usr/include/glib-2.0/gio/gdbusintrospection.h:155:25:error: expected
unqualified-id before ‘public’
 155 |   GDBusSignalInfo **signals;
 | ^~~


Jonathan

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

[Nicolas Fella]

Should be fixed with
https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/30

On 10.08.21 20:36, CI System wrote:

*BUILD FAILURE*
Build URL
https://build.kde.org/job/Plasma/job/breeze/job/kf5-qt5%20SUSEQt5.15/267/


Project:kf5-qt5 SUSEQt5.15
Date of build:  Tue, 10 Aug 2021 18:35:17 +
Build duration: 1 min 34 sec and counting



*CONSOLE OUTPUT *
[...truncated 271 lines...]
[2021-08-10T18:36:50.229Z] Call Stack (most recent call first):
[2021-08-10T18:36:50.229Z] CMakeLists.txt:18 (include)
[2021-08-10T18:36:50.229Z] This warning is for project developers. Use
-Wno-dev to suppress it.
[2021-08-10T18:36:50.229Z]
[2021-08-10T18:36:50.229Z] Installing in /home/jenkins/install-prefix.
Run /home/jenkins/workspace/Plasma/breeze/kf5-qt5
SUSEQt5.15/build/prefix.sh to set the environment for breeze.
[2021-08-10T18:36:50.229Z] -- Looking for __GLIBC__
[2021-08-10T18:36:50.488Z] -- Looking for __GLIBC__ - found
[2021-08-10T18:36:50.488Z] -- Performing Test _OFFT_IS_64BIT
[2021-08-10T18:36:50.746Z] -- Performing Test _OFFT_IS_64BIT - Success
[2021-08-10T18:36:50.746Z] -- Performing Test HAVE_DATE_TIME
[2021-08-10T18:36:50.746Z] -- Performing Test HAVE_DATE_TIME - Success
[2021-08-10T18:36:51.005Z] -- Found KF5CoreAddons:
/home/jenkins/install-prefix/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.005Z] -- Found KF5GuiAddons:
/home/jenkins/install-prefix/lib64/cmake/KF5GuiAddons/KF5GuiAddonsConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.006Z] -- Found KF5ConfigWidgets:
/home/jenkins/install-prefix/lib64/cmake/KF5ConfigWidgets/KF5ConfigWidgetsConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.006Z] -- Found KF5WindowSystem:
/home/jenkins/install-prefix/lib64/cmake/KF5WindowSystem/KF5WindowSystemConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.006Z] -- Found Gettext: /usr/bin/msgmerge (found
version "0.21")
[2021-08-10T18:36:51.006Z] -- Found KF5I18n:
/home/jenkins/install-prefix/lib64/cmake/KF5I18n/KF5I18nConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.006Z] -- Found KF5IconThemes:
/home/jenkins/install-prefix/lib64/cmake/KF5IconThemes/KF5IconThemesConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.006Z] -- Found KF5: success (found suitable
version "5.85.0", minimum required is "5.82") found components:
CoreAddons GuiAddons ConfigWidgets WindowSystem I18n IconThemes
[2021-08-10T18:36:51.006Z] -- Found XCB_XCB: /usr/lib64/libxcb.so
(found version "1.14")
[2021-08-10T18:36:51.006Z] -- Found XCB: /usr/lib64/libxcb.so (found
version "1.14") found components: XCB
[2021-08-10T18:36:51.006Z] -- Warning: Property URL already set to
"https://xcb.freedesktop.org/;, overriding it with
"https://xcb.freedesktop.org;
[2021-08-10T18:36:51.006Z] -- Performing Test
COMPILER_HAS_HIDDEN_VISIBILITY
[2021-08-10T18:36:51.263Z] -- Performing Test
COMPILER_HAS_HIDDEN_VISIBILITY - Success
[2021-08-10T18:36:51.264Z] -- Performing Test
COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
[2021-08-10T18:36:51.521Z] -- Performing Test
COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
[2021-08-10T18:36:51.521Z] -- Performing Test
COMPILER_HAS_DEPRECATED_ATTR
[2021-08-10T18:36:51.521Z] -- Performing Test
COMPILER_HAS_DEPRECATED_ATTR - Success
[2021-08-10T18:36:51.778Z] -- Found KF5Config:
/home/jenkins/install-prefix/lib64/cmake/KF5Config/KF5ConfigConfig.cmake
(found version "5.85.0")
[2021-08-10T18:36:51.778Z] -- Found KF5: success (found suitable
version "5.85.0", minimum required is "5.82") found components: I18n
Config GuiAddons IconThemes ConfigWidgets WindowSystem
[2021-08-10T18:36:51.778Z] Installing in /home/jenkins/install-prefix.
Run /home/jenkins/workspace/Plasma/breeze/kf5-qt5
SUSEQt5.15/build/misc/kde4breeze/prefix.sh to set the environment for
breeze.
[2021-08-10T18:36:51.778Z] -- Could not set up the appstream test.
appstreamcli is missing.
[2021-08-10T18:36:51.778Z] -- Found KF5: success (found version
"5.85.0") found components: CoreAddons Config
[2021-08-10T18:36:52.343Z] -- The following OPTIONAL packages have
been found:
[2021-08-10T18:36:52.343Z]
[2021-08-10T18:36:52.343Z] * PkgConfig
[2021-08-10T18:36:52.343Z] * XCB, X protocol C-language Binding,

[2021-08-10T18:36:52.343Z] Required to pass style properties to native
Windows on X11 Platform
[2021-08-10T18:36:52.343Z] * Qt5Network (required version >= 5.15.2)
[2021-08-10T18:36:52.343Z] * Qt5Qml (required version >= 5.15.2)
[2021-08-10T18:36:52.343Z] * Qt5QmlModels (required version >= 5.15.2)
[2021-08-10T18:36:52.343Z] * Qt5Quick
[2021-08-10T18:36:52.343Z] * KF5FrameworkIntegration (required version
>= 5.82), KF5 Framework Integration,

[2021-08-10T18:36:52.343Z] Required to use KStyle convenience
functionalities in style
[2021-08-10T18:36:52.343Z] * KF5Service (required version >= 

Using C++20 in Plasma

[Nicolas Fella]

Hi,

I would like to explore whether it would be feasible from a distribution
POV to use C++20 in Plasma (and other non-Frameworks projects).

In practical terms this would mean something like requiring gcc 10 or
clang 10 (the exact version that supports a given standard is hard to
define precisely, but these versions seem to have a reasonable coverage).

Is there any distro planning to ship future Plasma releases that does
not have gcc 10 or clang 10?

Cheers

Nico

Re: plasma_install_package vs plasma_install_bundled_package

[Nicolas Fella]

On 29/07/2021 15:50, Alexander Lohnau wrote:


Hi,


in
https://invent.kde.org/frameworks/kpackage/-/blob/master/KF5PackageMacros.cmake#L109
<https://invent.kde.org/frameworks/kpackage/-/blob/master/KF5PackageMacros.cmake#L109>
 there
is the a JSON file created.


I think the problem is that this file is installed next to the rcc
bundle, but KPackage expects it inside the bundle, so loading the
metadata from it doesn't work and it falls back to the .desktop file
inside the bundle.



The initial discussion about this function was in
https://phabricator.kde.org/D9197 <https://phabricator.kde.org/D9197
>. In https://phabricator.kde.org/D19383
<https://phabricator.kde.org/D19383> the topic was also discussed, but
without getting a conclusion.


There only being two users in all these years might be a sign that we
don't really need it, especially since in the initial patch
description it was stated that it is experimental :)


Regards

Alex



On Thursday, July 29, 2021 2:29:01 PM CEST Nicolas Fella wrote:

> Hi,

>

> in

>
https://invent.kde.org/frameworks/plasma-framework/-/blob/master/KF5PlasmaMa

> cros.cmake#L12 we recommend using plasma_install_bundled_package over

> plasma_install_package.

>

> However in practice we always use the latter, except for plasma-pa and

> plasma-nm.

>

> I stumbled across this because the bundled version does not seem to

> create a metadata.json from the metadata.desktop like the other macro

> does. That means that the desktop file needs to be converted to json at

> runtime which comes with a significant performance overhead when loading

> a plasmoid.

>

> Now I'm wondering whether we should fix plasma_install_bundled_package

> or port the two users away from it and abandon it.

>

> Thoughts?

>

> Cheers

>

> Nico

plasma_install_package vs plasma_install_bundled_package

[Nicolas Fella]

Hi,

in
https://invent.kde.org/frameworks/plasma-framework/-/blob/master/KF5PlasmaMacros.cmake#L12
we recommend using plasma_install_bundled_package over
plasma_install_package.

However in practice we always use the latter, except for plasma-pa and
plasma-nm.

I stumbled across this because the bundled version does not seem to
create a metadata.json from the metadata.desktop like the other macro
does. That means that the desktop file needs to be converted to json at
runtime which comes with a significant performance overhead when loading
a plasmoid.

Now I'm wondering whether we should fix plasma_install_bundled_package
or port the two users away from it and abandon it.

Thoughts?

Cheers

Nico

Re: Maliit as Plasma's on-screen keyboard

[Nicolas Fella]

Hi,

On 28.06.21 09:12, Tobias C. Berner wrote:

Moin moin

I'm a bit concerned about it seeming to be built on a stack of
abandonware -- qtfeedback (no release), and presage (2015).


mfg Tobias

On Fri, 25 Jun 2021 at 16:38, Aleix Pol  wrote:

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

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

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

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

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

Thanks!
Aleix


qtfeedback is something we use in other places as well and we are
discussing options on how to un-abandon it. One of the discussed options
is importing it under the KDE umbrella. See
https://lists.qt-project.org/pipermail/development/2021-April/041229.html

Can't comment on presage.

Cheers

Nico

Re: Maliit Keyboard and Plasma

[Nicolas Fella]

Hi,

On 24/06/2021 20:17, Jonathan Riddell wrote:

It's unclear to me if Plasma expects or needs Maliit to be installed.


Technically speaking it does not expect Maliit, any keyboard
implementing the required Wayland protocol will do. Maliit happens to be
the one we tend to test and it's what we ship on Plasma Mobile, so it
would be my default recommendation.



It's discussed here that "The built-in keyboard was dropped in 5.20 in
favor of external virtual keyboards."
https://bugs.kde.org/show_bug.cgi?id=427972


And of course users on tablet style machines

So should we have maliit installed by default?


Yes


  Should this be added as a cmake runtime check somewhere?


That's a bit harder to answer since technically any compliant keyboard
will do


  Should distros be told?  It doesn't seem to be a lot of distros
looking at repology
https://repology.org/project/maliit-keyboard/versions



yes.

> Is this page obsolete now we have the kwin virtual keyboard
kcm?https://invent.kde.org/plasma/kwin/-/wikis/Virtual-Keyboard


The information is still accurate, it's how the KCM works under the
hood. It's just not as relevant any more as it used to be.



Jonathan


Cheers

Nico

Re: Akademy Plasma Bof

[Nicolas Fella]

On 07/06/2021 10:42, Marco Martin wrote:

Hi all,
Do we want a plasma bof at akademy?
often we do a full day one, which may or may not be useful,
depending on what topic we do have.
Personally i would like to make one about plasma 6
Any day/time preference? other topics?


Hi,

in terms of topics I'd like to discuss how some recent efforts integrate
and depend on each other. In particular the long-proposed rewrite of
present windows ties into the ongoing work on the scene and effects API
redesign and QtQuick integration. This also ties into the realtime
gesture work by Janet
(https://invent.kde.org/plasma/kwin/-/merge_requests/1059) and the
design of present windows/other overviews. I'd like everyone involved to
have some shared understanding of a timeline and design goals so that
e.g. we have a design idea ready once we can implement a present windows
successor.

Cheers

Nico

Re: Re-purposing KWaylandServer

[Nicolas Fella]

Hi,

I noticed that the current split makes it very hard to perform git
bisect on kwin given its close relation to kwayland-server. Therefore
big +1 from me to incorporating kwaylandserver into the kwin repo.

Cheers

Nico

On 4/29/21 3:14 PM, Vlad Zahorodnii wrote:

On 4/28/21 4:27 PM, Aleix Pol wrote:

+1 for unifying them and refactoring all within a product. It must
stay properly separate but it would allow us to organise the


If kwaylandserver is integrated with the rest of kwin, it will be
possible to simplify some protocols as wayland bits will be able to
talk directly to the backend or the renderer instead of relying on
callbacks, or taking impl objects.

It will be also nice to unify client buffers for wayland clients and
internal clients.

I would personally prefer full integration of kwaylandserver in libkwin.

Cheers,
Vlad


components in ways that make sense beyond the frameworks splitting
much like you are finding right now.

Aleix

Re: KDE CI: Plasma » kinfocenter » kf5-qt5 SUSEQt5.15 - Build # 93 - Failure!

[Nicolas Fella]

See https://invent.kde.org/plasma/kinfocenter/-/merge_requests/24

On 3/4/21 12:25 PM, CI System wrote:

*BUILD FAILURE*
Build URL
https://build.kde.org/job/Plasma/job/kinfocenter/job/kf5-qt5%20SUSEQt5.15/93/


Project:kf5-qt5 SUSEQt5.15
Date of build:  Thu, 04 Mar 2021 11:23:34 +
Build duration: 1 min 33 sec and counting



*CONSOLE OUTPUT *
[...truncated 748 lines...]
[2021-03-04T11:25:04.649Z]
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:316: undefined reference to
`glXChooseVisual'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
CMakeFiles/kcm_opengl.dir/opengl.cpp.o: in function
`print_limits(QTreeWidgetItem*, char const*, bool)':
[2021-03-04T11:25:04.649Z]
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:582: undefined reference to
`glGetFloatv'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:583: undefined reference to
`glGetIntegerv'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:585: undefined reference to
`glGetError'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
CMakeFiles/kcm_opengl.dir/opengl.cpp.o: in function
`get_gl_info_glx(_XDisplay*, int, int, QTreeWidgetItem*,
QTreeWidgetItem*)':
[2021-03-04T11:25:04.649Z]
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:739: undefined reference to
`glXChooseVisual'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:741: undefined reference to
`glXChooseVisual'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:757: undefined reference to
`glXCreateContext'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:765: undefined reference to
`glXMakeCurrent'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:766: undefined reference to
`glXQueryServerString'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:767: undefined reference to
`glXQueryServerString'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:768: undefined reference to
`glXQueryServerString'
[2021-03-04T11:25:04.649Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:769: undefined reference to
`glXGetClientString'
[2021-03-04T11:25:04.650Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:770: undefined reference to
`glXGetClientString'
[2021-03-04T11:25:04.650Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:771: undefined reference to
`glXGetClientString'
[2021-03-04T11:25:04.650Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:772: undefined reference to
`glXQueryExtensionsString'
[2021-03-04T11:25:04.650Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:773: undefined reference to
`glGetString'
[2021-03-04T11:25:04.650Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:774: undefined reference to
`glGetString'
[2021-03-04T11:25:04.650Z]
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
/home/jenkins/workspace/Plasma/kinfocenter/kf5-qt5
SUSEQt5.15/Modules/opengl/opengl.cpp:775: undefined reference to
`glGetString'
[2021-03-04T11:25:04.650Z]

Re: Consistent CMake requirements in Plasma

[Nicolas Fella]

Hi,

I have now bumped the requirement for all Plasma repos.

There was one resulting build failure in kinfocenter that has been
corrected. Let me know if you notice any other unusual behavior.

Cheers

Nico

On 3/1/21 12:30 PM, Nicolas Fella wrote:

Hi,

so far I haven't received any negative feedback on this and got
acknowledgements from Debian, Fedora and OpenSUSE.

Unless someone objects within the next 24 hours I suggest that we
proceed with this.

Cheers

Nico

On 2/9/21 7:32 PM, Nicolas Fella wrote:

Hi,

while I was doing some cmake cleanup in Plasma I noticed that our stated
minimum cmake versions are both somewhat inconsistent and super old.
Most Plasma projects state that either 2.8 (released in 2009) or 3.0
(released in 2014) are the minimum. That's obviously unrealistic.

Newer cmake versions offer some nice stuff such as imported targets for
common libs (e.g. used in
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336). For
the sake of consistency I propose that we standardize Plasma on
something recent-ish.

My candidate for this would be cmake 3.16. It's the version shipped by
Ubuntu 20.04 and thus Neon. This would exclude Debian stable which ships
3.13 (which does not have the feature relevant for
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336).

Thoughts?

Cheers

Nico

Re: Consistent CMake requirements in Plasma

[Nicolas Fella]

Hi,

so far I haven't received any negative feedback on this and got
acknowledgements from Debian, Fedora and OpenSUSE.

Unless someone objects within the next 24 hours I suggest that we
proceed with this.

Cheers

Nico

On 2/9/21 7:32 PM, Nicolas Fella wrote:

Hi,

while I was doing some cmake cleanup in Plasma I noticed that our stated
minimum cmake versions are both somewhat inconsistent and super old.
Most Plasma projects state that either 2.8 (released in 2009) or 3.0
(released in 2014) are the minimum. That's obviously unrealistic.

Newer cmake versions offer some nice stuff such as imported targets for
common libs (e.g. used in
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336). For
the sake of consistency I propose that we standardize Plasma on
something recent-ish.

My candidate for this would be cmake 3.16. It's the version shipped by
Ubuntu 20.04 and thus Neon. This would exclude Debian stable which ships
3.13 (which does not have the feature relevant for
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336).

Thoughts?

Cheers

Nico

Fwd: Consistent CMake requirements in Plasma

[Nicolas Fella]

Hi packagers,

I recently proposed to formalize that Plasma depends on CMake 3.16. The
reasoning is to 1) make the requirements consistent across Plasma repos
and 2) enable the use of modern CMake features. If accpected this can
act as a precedent for other non-frameworks KDE software.

Is there any distro that does not ship at least CMake 3.16 interested in
shipping future Plasma releases?

Cheers

Nico

 Forwarded Message 
Subject:Consistent CMake requirements in Plasma
Date:   Tue, 9 Feb 2021 19:32:36 +0100
From:   Nicolas Fella 
Reply-To:   plasma-devel@kde.org
To: plasma-devel@kde.org



Hi,

while I was doing some cmake cleanup in Plasma I noticed that our stated
minimum cmake versions are both somewhat inconsistent and super old.
Most Plasma projects state that either 2.8 (released in 2009) or 3.0
(released in 2014) are the minimum. That's obviously unrealistic.

Newer cmake versions offer some nice stuff such as imported targets for
common libs (e.g. used in
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336). For
the sake of consistency I propose that we standardize Plasma on
something recent-ish.

My candidate for this would be cmake 3.16. It's the version shipped by
Ubuntu 20.04 and thus Neon. This would exclude Debian stable which ships
3.13 (which does not have the feature relevant for
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336).

Thoughts?

Cheers

Nico

Consistent CMake requirements in Plasma

[Nicolas Fella]

Hi,

while I was doing some cmake cleanup in Plasma I noticed that our stated
minimum cmake versions are both somewhat inconsistent and super old.
Most Plasma projects state that either 2.8 (released in 2009) or 3.0
(released in 2014) are the minimum. That's obviously unrealistic.

Newer cmake versions offer some nice stuff such as imported targets for
common libs (e.g. used in
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336). For
the sake of consistency I propose that we standardize Plasma on
something recent-ish.

My candidate for this would be cmake 3.16. It's the version shipped by
Ubuntu 20.04 and thus Neon. This would exclude Debian stable which ships
3.13 (which does not have the feature relevant for
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336).

Thoughts?

Cheers

Nico

Re: theming questions

[Nicolas Fella]

On 23.12.20 20:05, Dirk Hohndel wrote:

Hi there and happy holidays

I'm trying to improve the theming of my Kirigami-based app. We started using 
Kirigami about 5 years ago (before the current Theme code was there) and have 
done a lot of rather brute force things along the way (mostly out of 
incompetence and impatience, TBH).
Additionally, while Kirigami appears to think of theming mostly as "let's fit into 
whatever desktop theme is used", we want to offer the user the ability to switch 
between different color schemes at run time (and then of course remember their choice).
As a result we have our own "ThemeInterface" object that we instantiate from 
QML and use to grab the theme colors. Of course that clashes with the way Kirigami does 
theming. We have a few hacks to the Kirigami code (hooray for open source libraries), but 
I'm trying to move away from those and find ways to utilize the existing Kirigami theming 
more.
And that's where I'm running into what I guess are understanding issues with 
the code.

Here's how I think Kirigami theming works.
There's an attached property that shows up on every QML object. The Theme 
property offers background, text, highlight colors, and interestingly a 
colorSet that allows for different color combination for Windows, Buttons, 
modal things, etc.
All great and logical (I think).

Now let's assume you want to change those colors. The documentation advises 
against that, but also shows how to do that.

This is a code snippet from our main.qml:

 // we want to use our own colors for Kirigami, so let's define our 
colorset
 Kirigami.Theme.inherit: false
 Kirigami.Theme.colorSet: Kirigami.Theme.Button
 Kirigami.Theme.backgroundColor: subsurfaceTheme.backgroundColor
 Kirigami.Theme.textColor: subsurfaceTheme.textColor

First you apparently need to (unintuitively?) set inherit to false so that our 
colors get used. That seems backwards, but it appears to work.
But now comes the hard part. Here I'm trying to get the ActionButton to use our 
theme colors. And the above works. And because of the bindings, if the 
subsurfaceTheme changes, the ActionButton color changes as well.

Next I want to theme the global/context drawer including its handles.
I've tried a few things adding similar blocks to the above to my 
Kirigami.ContextDrawer instantiations, but I can't seem to get this to work.
First, which colorSet should they be using... reading the code I think it's 
View, but I'm not sure. But even if I add something like

contextDrawer: Kirigami.ContextDrawer {
id: contextDrawer
closePolicy: QtQuickTemplates.Popup.CloseOnPressOutside
// we want to use our own colors for Kirigami, so let's define 
our colorset
Kirigami.Theme.inherit: true
Kirigami.Theme.colorSet: Kirigami.ThemeView
Kirigami.Theme.backgroundColor: subsurfaceTheme.backgroundColor
Kirigami.Theme.textColor: subsurfaceTheme.textColor

I still get white-ish drawers and dark gray on very light gray open/close 
handles for those drawers - regardless of the colors set in my subsurfaceTheme 
object.

So, I guess, my question is... is there a more detailed example somewhere that 
illustrates how I can manually change the colors of all (most?) of the visual 
aspects of a Kirigami app without patching Kirigami?

Thanks

/D


Hi Dirk,

The Kirigami.Theme that we have in QML is backed by the PlatformTheme
class
(https://invent.kde.org/frameworks/kirigami/-/blob/master/src/libkirigami/platformtheme.cpp).
It contains a plugin system that is responsible for loading the actual
colors
(https://invent.kde.org/frameworks/kirigami/-/blob/master/src/libkirigami/platformtheme.cpp#L916)
and a fallback implementation
(https://invent.kde.org/frameworks/kirigami/-/blob/master/src/libkirigami/basictheme.cpp).
The plugin is selected based on the QQC2 style, for example the
implementation for qqc2-desktop style can be found at
https://invent.kde.org/frameworks/qqc2-desktop-style/-/blob/master/kirigami-plasmadesktop-integration/plasmadesktoptheme.cpp.
My suggestion would be to create your own color plugin and ship that
with your app. That would allow you to define the various
Kirigami.Theme.* values based on your own logic while not requiring any
special QML code. What QQC2 style do you use in your app? If you have
your own anyway then it would be a matter of having a plugin with the
right name in the plugin path and it would be selected. If not then we
can talk about adding some API that allows selecting a specific color
plugin.

Cheers and happy holidays

Nico

D25961: [WIP] Switch the Attica KDE plugin to use KAccounts

[Nicolas Fella]

nicolasfella added a comment.


  @leinir it seems like this was merged so I guess this should be closed?

REPOSITORY
  R119 Plasma Desktop

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

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

[kwrited] [Bug 429652] [Feature Request] Notification applet should also save images

[Nicolas Fella]

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

Nicolas Fella  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |NOT A BUG
 CC||nicolas.fe...@gmx.de
 Status|NEEDSINFO   |RESOLVED

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

D28194: Fix loading button icons from qrc

[Nicolas Fella]

nicolasfella abandoned this revision.
nicolasfella added a comment.


  Abandoning in favor of 
https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/35

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

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

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

D21049: [wizard] Enable 1-finger touch scrolling

[Nicolas Fella]

nicolasfella closed this revision.

REPOSITORY
  R97 Bluedevil

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

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

C++17 in Plasma

[Nicolas Fella]

Hi,

do we have any rules on the C++ standard used in Plasma? Most Plasma
repos don't specify a CMAKE_CXX_STANDARD , defaulting to 11 through ECM.
Some, such as kwin set it to 14.

I found myself a few times in the situation where a C++17 feature would
have been useful, but it always felt like requiring 17 just for this
particular case wouldn't be justifiable. I do however believe that if
you sum up all these minor occasions it becomes significant. I therefore
propose to formalize that using C++17 in Plasma is acceptable.

Several KDE projects already require C++17 (keysmith, kio-fuse,
kio-extras, maui, kaidan, itinerary, sink, elisa, akonadi and
kactivitymanagerd). Given that kactivitymanagerd is technically part of
Plasma we even have precedence of using C++17 in Plasma. Qt6 will
require C++17 too.

With regards to compiler compatibility: gcc supports C++17 since version
5, Neon bionic, which is about as old a distro as I would reasonably
expect Plasma to support, ships gcc 7, so I don't expect any issues here.

Thoughts?

Cheers

Nico

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> broulik wrote in androidutils.h:29
> `const QDate &`

Actually clazy disagrees, QDate and QTime should be passed by value

REPOSITORY
  R1047 Kirigami Addons

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

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

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella marked an inline comment as done.
nicolasfella added inline comments.

INLINE COMMENTS

> broulik wrote in TimeDialog.qml:15
> Generally conversions between C++ timedate and JavaScript `Date` is bad. 
> There's no way to represent just a time with no date and timezone associated 
> with it in JavaScript.
> While it's ugly, I'd suggest we return a bunch of `int`.
> Also, I think we should have the selected time as properties and an 
> `accepted`/rejected signal or similar.
> (Same probably goes for the date picker)

If we do this should the date thing also use ints for symmentry?

REPOSITORY
  R1047 Kirigami Addons

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

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

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella updated this revision to Diff 83053.
nicolasfella marked 10 inline comments as done.
nicolasfella added a comment.


  - fix
  - Address some comments

REPOSITORY
  R1047 Kirigami Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29268?vs=81471=83053

BRANCH
  work

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

AFFECTED FILES
  CMakeLists.txt
  KF5KirigamiAddonsConfig.cmake.in
  cmake/modules/FindGradle.cmake
  cmake/modules/local.properties.in
  cmake/modules/settings.gradle.in
  src/dateandtime/CMakeLists.txt
  src/dateandtime/DateDialog.qml
  src/dateandtime/KF5KirigamiDateAndTimeAndroid-android-dependencies.xml
  src/dateandtime/TimeDialog.qml
  src/dateandtime/android/AndroidManifest.xml
  src/dateandtime/android/CMakeLists.txt
  src/dateandtime/android/build.gradle
  src/dateandtime/android/org/kde/kirigamiaddons/dateandtime/DatePicker.java
  src/dateandtime/android/org/kde/kirigamiaddons/dateandtime/TimePicker.java
  src/dateandtime/lib/androidutils.cpp
  src/dateandtime/lib/androidutils.h
  src/dateandtime/lib/plugin.cpp
  src/dateandtime/qmldir

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

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> broulik wrote in CMakeLists.txt:69
> Why this only on Android? or is that used for that dummy library?

It's for the dummy library only

> broulik wrote in FindGradle.cmake:2
> Feels like this should go into ECM?

Yep

> broulik wrote in DateDialog.qml:12
> `org.kde.kirigamiaddons.private.dateandtime` to emphasis it's an impl detail

I'd rather do that in a separate patch since it should also be done for other 
classes

> broulik wrote in TimeDialog.qml:15
> Generally conversions between C++ timedate and JavaScript `Date` is bad. 
> There's no way to represent just a time with no date and timezone associated 
> with it in JavaScript.
> While it's ugly, I'd suggest we return a bunch of `int`.
> Also, I think we should have the selected time as properties and an 
> `accepted`/rejected signal or similar.
> (Same probably goes for the date picker)

In this particular case the timezone is not relevant though

REPOSITORY
  R1047 Kirigami Addons

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

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

D22702: [fileitemaction] Clean up includes

[Nicolas Fella]

nicolasfella closed this revision.

REPOSITORY
  R845 Plasma Vault

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

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

D22868: Revamp Kirigami.AboutPage

[Nicolas Fella]

nicolasfella added a comment.


  can this be closed?

REPOSITORY
  R169 Kirigami

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

To: hein, #frameworks, #vdg, mart, apol, ngraham, leinir, nicolasfella
Cc: nicolasfella, ngraham, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, apol, ahiemstra, davidedmundson, mart

D22702: [fileitemaction] Clean up includes

[Nicolas Fella]

nicolasfella updated this revision to Diff 83047.
nicolasfella added a comment.


  Update

REPOSITORY
  R845 Plasma Vault

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22702?vs=62441=83047

BRANCH
  foo

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

AFFECTED FILES
  fileitemplugin/plasmavaultfileitemaction.cpp

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

D28154: Add users KCM

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> davidedmundson wrote in kcm.cpp:97
> OH!
> 
> Initial-ise
> 
> not initialise as in "to prepare"
> 
> Makes sense :)

Then it should have a different name, like "getInitials", else the next person 
will be just as confused

REPOSITORY
  R119 Plasma Desktop

BRANCH
  arcpatch-D28154

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

To: cblack, #plasma, #vdg, ngraham
Cc: mart, yurchor, iasensio, meven, crossi, The-Feren-OS-Dev, davidedmundson, 
broulik, filipf, ngraham, nicolasfella, zzag, plasma-devel, Orage, LeGast00n, 
cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra

D29466: [applets/appmenu] Add search to global application menu

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> appmenumodel.cpp:193
> +removeSearchActionsFromMenu();
> +if (filter == QString()) {
> +return;

.isEmpty()

> appmenumodel.cpp:196
> +}
> +auto actions = flatActionList();
> +for (const auto : actions) {

const

> appmenumodel.h:70
>  void setScreenGeometry(QRect geometry);
> +QList flatActionList();
> +

const

> appmenumodel.h:73
> +void setMenuOpen(bool open);
> +bool menuOpen();
> +Q_SIGNAL void menuOpenChanged();

const

REPOSITORY
  R120 Plasma Workspace

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

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

D29466: [applets/appmenu] Add search to global application menu

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> appmenumodel.cpp:246
> +}
> +for (auto : m_menu->findChildren()) {
> +if (action->menu() == nullptr) {

Extract the list into a variable before iterating, else this might blow up

See 
https://github.com/KDE/clazy/blob/master/docs/checks/README-temporary-iterator.md

REPOSITORY
  R120 Plasma Workspace

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

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

D28194: [WIP] Fix loading button icons from qrc

[Nicolas Fella]

nicolasfella updated this revision to Diff 82149.
nicolasfella added a comment.


  - Also handle ':/' prefix

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28194?vs=78197=82149

BRANCH
  qrcicons

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

AFFECTED FILES
  plugin/kquickstyleitem.cpp

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

D29476: WIP: Port klipper to use wayland clipboard

[Nicolas Fella]

nicolasfella added a comment.


  Isn't this something that should be in QClipboard in an ideal world? Or is 
that currently not feasible since the protocol is non-standard?

REPOSITORY
  R120 Plasma Workspace

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

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

D29435: Fix typo in examples

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:35f055a25e73: Fix typo in examples (authored by 
nicolasfella).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29435?vs=81954=82023

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

AFFECTED FILES
  examples/PageRouter.qml
  examples/PageRouterCachePagesDo.qml
  examples/PageRouterCachePagesDont.qml
  examples/PageRouterColumnView.qml
  examples/PageRouterInitialRoute.qml
  examples/PageRouterRoutes.qml

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

D29435: Fix typo in examples

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Kirigami, cblack.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
nicolasfella requested review of this revision.

REPOSITORY
  R169 Kirigami

BRANCH
  typo

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

AFFECTED FILES
  examples/PageRouter.qml
  examples/PageRouterCachePagesDo.qml
  examples/PageRouterCachePagesDont.qml
  examples/PageRouterColumnView.qml
  examples/PageRouterInitialRoute.qml
  examples/PageRouterRoutes.qml

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

D29312: Change microphoneindicator for reporting audio monitors

[Nicolas Fella]

nicolasfella added a comment.


  In D29312#660702 , @kurmikon wrote:
  
  > In D29312#660670 , @nicolasfella 
wrote:
  >
  > > > but due to a lack in qt libraries
  > >
  > > Can you elaborate on this? What is Qt lacking?
  >
  >
  > I'm not an expert, so I don't really know. Reading the bug report, there's 
no way to discern input devices from monitor sinks. So if you want to report 
applications that are using a microphone, you end up showing applications like 
PuseEffects that create a monitor sink. Those applications can use a microphone 
but in most cases don't, because PulseEffects is mostly used to apply effects 
to output streams (but need to record those streams effectively).
  
  
  Qt is not really involved in this. What matters is what libpulse offers, and 
it seems to me that we can check whether a sink is a monitor 
(https://freedesktop.org/software/pulseaudio/doxygen/structpa__source__info.html#a5e304b796ce71c7fa54e5a88f630).
 One would need to add a method isMonitor to Sink that reads this information 
and then we can not show the indicator when it's a monitor

REPOSITORY
  R115 Plasma Audio Volume Applet

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

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

D29308: Fix excessive right padding in scrollable page

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:e97ffaa7a6b3: Fix excessive right padding in scrollable 
page (authored by nicolasfella).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29308?vs=81611=81626

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

AFFECTED FILES
  src/controls/ScrollablePage.qml

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

D29312: Change microphoneindicator for reporting audio monitors

[Nicolas Fella]

nicolasfella added a comment.


  > but due to a lack in qt libraries
  
  Can you elaborate on this? What is Qt lacking?

REPOSITORY
  R115 Plasma Audio Volume Applet

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

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

D29308: Fix excessive right padding in scrollable page

[Nicolas Fella]

nicolasfella added a comment.


  Mobile before:
  F8274015: Screenshot_20200430_195955.png 

  
  Mobile after:
  F8274019: Screenshot_20200430_200111.png 


REPOSITORY
  R169 Kirigami

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

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

D29308: Fix excessive right padding in scrollable page

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Kirigami, mart.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  In this example
  
import QtQuick 2.5
import QtQuick.Layouts 1.1
import org.kde.kirigami 2.4 as Kirigami

Kirigami.ScrollablePage {

Rectangle {
width: parent.width
height: 1000
color: "red"
}
}
  
  the gap between the rectangle and the scrollbar was larger than the distance 
between the left edge of the rectangle and the window. This was caused by the 
extra rightPadding of the RefreshableScrollView. It also seems unnecessary to 
me since the ScrollView itself takes care of dodging the scroll bar 
(ScrollView.qml:21).

REPOSITORY
  R169 Kirigami

BRANCH
  margin

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

AFFECTED FILES
  src/controls/ScrollablePage.qml

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

D29293: Add rules about import naming and platform specialization

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R1047:a445f089cbec: Add rules about import naming and platform 
specialization (authored by nicolasfella).

REPOSITORY
  R1047 Kirigami Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29293?vs=81559=81560

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

AFFECTED FILES
  rules.txt

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

D29293: Add rules about import naming and platform specialization

[Nicolas Fella]

nicolasfella updated this revision to Diff 81559.
nicolasfella added a comment.


  - Expand notes on specific platforms

REPOSITORY
  R1047 Kirigami Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29293?vs=81558=81559

BRANCH
  rules

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

AFFECTED FILES
  rules.txt

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

D29293: Add rules about import naming and platform specialization

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Kirigami, davidedmundson, vkrause.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  As discussed in chat

REPOSITORY
  R1047 Kirigami Addons

BRANCH
  rules

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

AFFECTED FILES
  rules.txt

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

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella added a comment.


  In D29268#659586 , @vkrause wrote:
  
  > There might be ways around the native function registration issue from the 
QML thread, e.g. by using the alternative approach of exported (mangled) 
symbols instead: 
https://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/design.html -> 
"Loading and Linking Native Methods".
  
  
  I tried that, but it didn't seem to work.

REPOSITORY
  R1047 Kirigami Addons

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

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

D29279: Don't play volume feedback if max volume is reached

[Nicolas Fella]

nicolasfella added a comment.


  To be clear: the 95%->100% transition still emits a sound, but 100%->100% 
does not any more

REPOSITORY
  R115 Plasma Audio Volume Applet

BRANCH
  vol

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

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

D29279: Don't play volume feedback if max volume is reached

[Nicolas Fella]

nicolasfella added a comment.


  The lack of sound is feedback that you are at maximum volume
  
  Before it was hard to hear the difference between 90% and 100%

REPOSITORY
  R115 Plasma Audio Volume Applet

BRANCH
  vol

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

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

D29279: Don't play volume feedback if max volume is reached

[Nicolas Fella]

nicolasfella updated this revision to Diff 81525.
nicolasfella added a comment.


  - Fix comment

REPOSITORY
  R115 Plasma Audio Volume Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29279?vs=81524=81525

BRANCH
  vol

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

AFFECTED FILES
  applet/contents/ui/main.qml

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

D29279: Don't play volume feedback if max volume is reached

[Nicolas Fella]

nicolasfella updated this revision to Diff 81524.
nicolasfella added a comment.


  - Whitespace

REPOSITORY
  R115 Plasma Audio Volume Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29279?vs=81523=81524

BRANCH
  vol

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

AFFECTED FILES
  applet/contents/ui/main.qml

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

D29279: Don't play volume feedback if max volume is reached

[Nicolas Fella]

nicolasfella updated this revision to Diff 81523.
nicolasfella added a comment.


  - Clarify comment

REPOSITORY
  R115 Plasma Audio Volume Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29279?vs=81522=81523

BRANCH
  vol

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

AFFECTED FILES
  applet/contents/ui/main.qml

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

D29279: Don't play volume feedback if max volume is reached

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: Plasma, drosca.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  I often smash my volume up key until the volume is max. I usually smash it 
for too long and the sound is still playing even if the volume isn't actually 
changing any more. By not playing a sound when the volume is already at maximum 
we avoid a weird sound and give an accoustic feedback that the maximum has been 
reached.

REPOSITORY
  R115 Plasma Audio Volume Applet

BRANCH
  vol

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

AFFECTED FILES
  applet/contents/ui/main.qml

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

D29276: Bundle icons for inline messages

[Nicolas Fella]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:8a65fcefe42d: Bundle icons for inline messages (authored 
by nicolasfella).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29276?vs=81513=81516

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

AFFECTED FILES
  KF5Kirigami2Macros.cmake

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

D29276: Bundle icons for inline messages

[Nicolas Fella]

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

REVISION SUMMARY
  Those are used in InlineMessage for the standard message types. We need to 
bundle those into the apk on Android

REPOSITORY
  R169 Kirigami

BRANCH
  icons

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

AFFECTED FILES
  KF5Kirigami2Macros.cmake

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

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella updated this revision to Diff 81471.
nicolasfella added a comment.


  - fix

REPOSITORY
  R1047 Kirigami Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29268?vs=81470=81471

BRANCH
  work

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

AFFECTED FILES
  CMakeLists.txt
  KF5KirigamiAddonsConfig.cmake.in
  cmake/modules/FindGradle.cmake
  cmake/modules/local.properties.in
  cmake/modules/settings.gradle.in
  src/dateandtime/CMakeLists.txt
  src/dateandtime/DateDialog.qml
  src/dateandtime/KF5KirigamiDateAndTimeAndroid-android-dependencies.xml
  src/dateandtime/TimeDialog.qml
  src/dateandtime/android/AndroidManifest.xml
  src/dateandtime/android/CMakeLists.txt
  src/dateandtime/android/build.gradle
  src/dateandtime/android/org/kde/kirigamiaddons/dateandtime/DatePicker.java
  src/dateandtime/android/org/kde/kirigamiaddons/dateandtime/TimePicker.java
  src/dateandtime/lib/androidutils.cpp
  src/dateandtime/lib/androidutils.h
  src/dateandtime/lib/plugin.cpp
  src/dateandtime/qmldir

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

D29268: [WIP] Add Date/Time dialog

[Nicolas Fella]

nicolasfella created this revision.
nicolasfella added reviewers: davidedmundson, vkrause, broulik.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  Import the date/time picker used in KTrip. It wraps the existing date/time 
picker components into a dialog. On Android it calls the native date/time 
picker instead.
  
  The Android implementation is slightly messy since we apparently can't do JNI 
things directly from a QML plugin because it gets loaded in the wrong thread. 
As a workaround we have a linkable library on Android that forces JNI 
initialization in the right thread.
  
  Finish

TEST PLAN
  Ported KTrip to it

REPOSITORY
  R1047 Kirigami Addons

BRANCH
  work

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

AFFECTED FILES
  CMakeLists.txt
  KF5KirigamiAddonsConfig.cmake.in
  cmake/modules/FindGradle.cmake
  cmake/modules/local.properties.in
  cmake/modules/settings.gradle.in
  src/dateandtime/CMakeLists.txt
  src/dateandtime/DateDialog.qml
  src/dateandtime/KF5KirigamiDateAndTimeAndroid-android-dependencies.xml
  src/dateandtime/TimeDialog.qml
  src/dateandtime/android/AndroidManifest.xml
  src/dateandtime/android/CMakeLists.txt
  src/dateandtime/android/build.gradle
  src/dateandtime/android/org/kde/kirigamiaddons/dateandtime/DatePicker.java
  src/dateandtime/android/org/kde/kirigamiaddons/dateandtime/TimePicker.java
  src/dateandtime/lib/androidutils.cpp
  src/dateandtime/lib/androidutils.h
  src/dateandtime/lib/plugin.cpp
  src/dateandtime/qmldir

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

D29057: Introduce PlaceholderMessage component

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

> PlaceholderMessage.qml:26
> + * @code{.qml}
> + * import org.kde.kirigami 2.11 as Kirigami
> + ** used as a "this view is empty" message

This needs to be 2.12

REPOSITORY
  R169 Kirigami

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

To: ngraham, #vdg, #kirigami, mart
Cc: nicolasfella, leinir, abetts, broulik, cblack, plasma-devel, fbampaloukas, 
GB_2, domson, dkardarakos, ngraham, apol, ahiemstra, davidedmundson, mart