hmmm. Ping @mart. :) what do you suggest we do?

I don't feel like the world needs this.

Should I understand this is not desired and that I should abandon it?

Ping?

Will move to gitlab

Account for software rotation

I guess we're doing it for readability in sacrifice of simplicity or performance which admittedly is probably meaningless here.

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

I wonder if this should be specified in ToolBarApplicationHeader instead.

addressed

Address comment

Content

• 0.3 K Desktop Environment is -> rebranding. Should redefine KDE Software as the software developed by the KDE Community.
• 0.x Should define "KDE Community" as the projects developed in the KDE infrastructure to serve the end users FOSS needs including its by-products.
• 2.1 Should rephrase, talking about the software produced by the KDE Community spaces rather than "K Desktop Environment" package.
• 2.2 Should rephrase free desktop software -> free software for end-users
• 6. General Assembly -> it assumes it's in person but doesn't specify so. It talks about things like "show of hands" that is clearly awkward to implement on a virtual AGM. Adding something along the lines of the following would make sense:

Patch looks good to me overall.

Do not allocate a full QRegion on every paint.

Make sure the rects are always in the right coordinate space and properly scaled

Address scaling

As suggested by zzag

we were landing on \0 so we never reached \n

Rebase

An example is flatpak apps don't run because they can't find the portals dbus service which doesn't restart because it's running in the actual dbus instance.

I don't do it because it's harder to set up the IDE to have a wrapper. I'll address it in KDevelop.

+1 for the change btw, thanks!

We are in string freeze right now, aren't we?

The change is sound but the code looks terrible.

I'm expecting QDebug would handle it, I don't see why opengl would be giving us an empty debug message though.

Add missing file, fix rendering of some surfaces

I wouldn't have a big problem with merging as is, it could make sense to have QFuture<QVariant> retrieveData as is. It would make it easier to time out when a client is being shitty and would allow to parallelize different queries.

Support for window streaming

It could make sense to leverage QCollatorSortKey in this class if it's sorting often.

+1 overall, good idea.

Good catch

I feel like this could break Labels unknowingly. Maybe it would make sense to have an extra scrollToFit (?) property or even another separate component to do that.

In D29523#666095, @zzag wrote:

@davidedmundson Should I abandon D29519?

Looks good to me. Maybe to merge after branching?

Adapt to changes in the protocol, implement windows

Moving to kwayland-server

+1

In D29476#664751, @nicolasfella wrote:

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?

You can do that now but this behaviour is deprecated and disallowed in Qt 6 AFAIK.

Rebase on top of kwayland-server changes

If I understand correctly, it is necessary to use dbus spectacle in this case, so that dbus can manage the application instance and make sure we end up with only one, whether we launch the app, use a shortcut or launch from command line.

What's the advantage?
Won't this make it harder to put together the notifications kcm?

This should be documented somewhere, as is it's really confusing.

This will make our configure steps readable again. Thanks!

Hi @kkremitzki, it's good to see FreeCad interested! What do you have in mind?