Maybe a way to move this forward would be to come up with which parts within KDE would need to adapt to this. Or do you think that making Falkon better would be enough?

We have several goals related to input methods and Wayland. I think it would be good if we tried to put our thoughts together in order to put forward one unified proposal.

We have several goals related to input methods and Wayland. I think it would be good if we tried to put our thoughts together in order to put forward one unified proposal.

We have several goals related to input methods and Wayland. I think it would be good if we tried to put our thoughts together in order to put forward one unified proposal.

We have several goals related to input methods and Wayland. I think it would be good if we tried to put our thoughts together in order to put forward one unified proposal.

This seems more like a Plasma feature rather than a KDE-wide goal, right?

I'd like to bump the out-of-process/sandboxed plasmoid use-case:

• it would make it possible to ship sandboxed services like KDE Connect as containers. At the moment we need to install them all in the system and use the same Qt and libraries, which does narrow down greatly what we can do with Plasmoids.
• it should help plasmashell startup by a big deal as a bunch of it can be parallelised (think dbus calls). Makes me think it doesn't even need to be just for 3rd parties.
• a plasmoid can't kill all plasmashell.

Do we still need hardware for the booth, other than the rpi? I can bring some but it would be good some hindsight.

I created this matrix room to coordinate this with the people I know they're coming, please join if you want to come. https://matrix.to/#/#kde-qtws-2023:kde.org

Separate repositories make sense, yes. I don't really see how it fits in KNewStuff. From a feature offering perspective, it seems to me it's a bit weird how it kind of overlaps with Purpose but not entirely. I don't know what to make of it though.

No. I meant the camera, microphone and gps.

First make sure to start working on one of the 3 listed. I guess it depends on which you prefer we can start looking into.

It was originally developed for bigscreen but it doesn't really have much bigscreen specific. I recommend you give it a try.

Have you seen this? https://invent.kde.org/plasma-bigscreen/plasma-remotecontrollers/

If an issue you reported isn't a problem anymore, it's usually helpful to mark it as resolved so that we don't need to triage it later on.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1508

https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/222

plasmoid/contents/ui/PasteMenuItem.qml:8:import org.kde.plasma.components 2.0 as PlasmaComponents for MenuItem
plasmoid/contents/ui/ShareDialog.qml:10:import org.kde.plasma.components 2.0 as PlasmaComponents for Highlight and ListItem

TODO
package/contents/ui/IconItem.qml:9:import org.kde.plasma.components 2.0 as PlasmaComponents // for ContextMenu+MenuItem

TODO:
package/contents/ui/main.qml:12:import org.kde.plasma.components 2.0 as PlasmaComponents // for Menu+MenuItem

Still todo:
contents/ui/BarcodePage.qml:10:import org.kde.plasma.components 2.0 as PlasmaComponents For ContextMenu
contents/ui/ClipboardItemDelegate.qml:13:import org.kde.plasma.components 2.0 as PlasmaComponents2
contents/ui/Menu.qml:11:import org.kde.plasma.components 2.0 as PlasmaComponents For Highlight

Sorry, I wasn't clear enough. I meant we can move the KFileItemActions integration. Or maybe even into plasma-integration and this way it rolls with Plasma, although changing release cycles has some problems.

An idea would be to move this into the frameworkintegration repository.

+1 please ping me, I'll be around.

Sure, if it's the 14th note we already have the fireside chat at some point of the day.

It could make sense to provide façade interfaces to do the common things the different plugin types allow.

It's supposed to be something similar to Android's intents.

In D18758#678706, @arrowd wrote:

So, do we want to get this in?

Short recap:

• Project::open() executes KIO jobs synchronously at the moment.
• To make the code asynchronous we need some 3rd-party library implementing futures, like QtPromise.
• The original bug that made me work on this is fixed already.
  
  Should we abandon this?

My comment was mostly aimed at the plasmashell profiling (i.e. plasmoids) we did for the pinebook. KCM delays should be less stressful to performance because we don't trigger it as the system is starting up.

In T14752#261083, @paulb wrote:

@apol, can you confirm these are KDE patrons?

Canonical, Google, SUSE, The Qt Company, Blue Systems, Haute Couture Enioka, Slimbook and PINE64

https://develop.kde.org/hig/ < let's not reinvent the wheel. Whatever is there can be addressed if it doesn't fit. If an application doesn't fit the HIG it can definitely be addressed.

Would it maybe make sense to style it into Plasma rather than like an application?

Adjust the voting structure:

I agree with the overall goal, some details follow.

Like we said to the last few, feel free to work on it. I haven't seen much activity happen around the topic. Maybe you would like to explain how you'd like to start working on it?

In T8187#243082, @elvisangelaccio wrote:

Just my 2 cents: we have telemetry now, so we can actually check whether people prefer single or double click.

@cubix tell us if you don't know where to start from or if you have any questions. :)

Makes sense to me too, but I've seen many projects that have taken ownership of the flatpak recipe to let it degrade over time. We need ways to make sure it doesn't happen.

IIRC the patch was stopped with the concern that it would bring a QtQml dependency that isn't always necessary. I'd say it should be fine though.

https://invent.kde.org/frameworks/networkmanager-qt/-/merge_requests/2

We have moved to gitlab, now patches should be uploaded here: https://invent.kde.org/frameworks/networkmanager-qt

Rebased to master into https://invent.kde.org/plasma/kwin/-/merge_requests/145.

I'd love to merge it.

Should be working on Wayland as of Plasma 5.18 with improvements in 5.19.

Moved here: https://invent.kde.org/plasma/kwin/-/merge_requests/106

https://invent.kde.org/plasma/kwayland-server/-/merge_requests/31

Moved to invent for kwayland-server

Did you like the format? Anything we can improve upon?

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