Remove unused include

The biggest problem with sharing the dmabuf buffers it that its memory management becomes quite complex (and I'm unsure it's really doable).
PipeWire has mechanisms to create the buffers it's going to need, juggling this with passing the buffer from the app/output and making sure it stays relevant feels messy and error-prone.
Copying from dmabuf->dmabuf shouldn't be very expensive though, as it shouldn't go through the buses (AFAIK, that is).

Moved and finished (now works) here: https://invent.kde.org/plasma/kwin/-/merge_requests/17

In D29477#673166, @meven wrote:

In D29477#673039, @ndavis wrote:

Resuming this on invent

link ?

Hey man, can you join our vdg team on Telegram? Here is the link: https://t.me/vdgmainroom

Ping?

don't need to include cmath anymore

Address review feedback

• Use After instead of Wants

In D29263#673250, @ngraham wrote:

The existing magic number is also totally random, and does not even match

Zero based position parameters.

And the actual rationale appears to be: https://mail.kde.org/pipermail/kde-frameworks-devel/2020-March/105081.html

If, like me, you land here (after discovering the new dependency) and miss the rationale, see:

• https://phabricator.kde.org/T13025
• https://mail.kde.org/pipermail/kwin/2020-April/004517.html

In D29263#673249, @zzag wrote:

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

Speaking for myself, I'm not. I don't like 0.37 because it's not based on anything. Why not 0.39 or 0.4242?

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

LGTM :)

You can update users' config filed with a kconf update script (see https://techbase.kde.org/Development/Tools/Using_kconf_update) or avoid changing the config file key names in the first place.

So this should be good for merging @apol after spectacle D29408 has been rebased and D29487 has landed

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

In D29477#673039, @ndavis wrote:

Resuming this on invent

In D29263#673135, @niccolove wrote:

I'm a bit confused. Aren't we changing the size for third party global themes as well? Do all global themes set their size?

I'm a bit confused. Aren't we changing the size for third party global themes as well? Do all global themes set their size?

In D29263#673062, @niccolove wrote:

How do you think about putting it horizontally centered at the top of the screen? Maybe even avoiding panels, if possible?
I'd be fine both with "floating a bit under the panel" and "merged with screen/panel top" like krunner.

I don't think it's a problem to change this even for non-breeze themes.

It might be best not to change anything about the position until we can come up with a significantly better solution.

How do you think about putting it horizontally centered at the top of the screen? Maybe even avoiding panels, if possible?
I'd be fine both with "floating a bit under the panel" and "merged with screen/panel top" like krunner.

In D29263#673056, @ngraham wrote:

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

In the absence of a way for the Global Theme or (proposed-but-not-yet-existing OSD themes) to set a custom OSD position, are KWin people okay with this patch to improve the positioning of the new OSD?

Resuming this on invent

In D29263#673015, @ndavis wrote:

I'm feeling pretty lukewarm about this idea. It's maybe slightly better in some situations, but with the smaller size, I think it'll also be easier to miss if it's not in the center. Since the OSD is smaller, being exactly in the center isn't such a huge problem either. Although, I suppose it would still get in the way of crosshairs if the user was playing a shooter game.

I'm feeling pretty lukewarm about this idea. It's maybe slightly better in some situations, but with the smaller size, I think it'll also be easier to miss if it's not in the center. Since the OSD is smaller, being exactly in the center isn't such a huge problem either. Although, I suppose it would still get in the way of crosshairs if the user was playing a shooter game.

Ping. I think this is a mild improvement

With the smaller appearance, I'm feeling a bit like it just floats there... for no reason... it gives me the impression than there's no visual connection with anything. It's a bit like it's in a random position, maybe because it's not vertically centered. Could be fine anyway, but I was wondering if there's another place where it would better fit. Maybe top left? Can it avoid panels?

KWin @zzag @davidedmundson ping.

Account for software rotation

Does it work fine with software screen rotation?

Alright I tested latest version on PlaMo and seems to work perfectly fine now!

Will move the code review to GitLab.

Ping?

Alright I tested latest version on PlaMo and seems to work perfectly fine now!

• Keep previous line

As such, and introducing a new i18n string, I don't know whether it should be included in 5.19 or 5.20 release.

Okay, I see. We still probably need a kconf_update script, but it would be unrelated to what this change intends to do.

This sounds good to me overall. I am not that familiar with the technicalities of the different scaling methods (which seems to be quite a difficult subject) so I can't comment too much on this. To me it looks like proposal 3, 5 and 6 depend on proposal 4 e.g. the 135% scale factor in proposal 5 should normally be avoided AFAIK.

Sorry, I phrased it wrong. The change to use the enum instead of strings in the settigs was done before the new kcm, in the port to KconfigXT. This just updates the kcm to it since it's not working (it can not read/write the placement from the settings schema)

The setting "placement" is now stored usign the enum value, instead of a string equivalent

• Change assertion for simple check

• Add comment

The problem with setting both top and bottom anchors (or using anchors.fill) is that it stretches the component and distorts the spacing between its internal items. However this instance doesn't have multiple items, so it's fine. However please add a comment mentioning this, should someone ever add a text label or an icon in the future.

With ~20 rules I still can see a noticeable lag, although it's slightly better.

In D29407#668061, @meven wrote:

It has been reminded me that this solution to have some security rest entirely on the guarantees offered by $XDG_DATA_DIRS.
Same can be said about X-KDE-Wayland-Interfaces.

But currently I believe this does not constitutes a strong security model.
A malicious executable could manufacture a fake $XDG_DATA_DIRS, add an application folder in it and a desktop file for its executable, trigger kbuildsyscoca5 and then use any of the restricted interfaces.
We would need further to restrict path for which we would consider the desktop file, for instance, like only root owned path.

Improve naming of fetchRequestedWaylandInterfaces

All the changes seem nice but this one. I've not yet figure out why