In T13037#234908, @tcorreabr wrote:

In T13037#234728, @mvourlakos wrote:

In T13037#234721, @tcorreabr wrote:

Going back to solution B, what do you think about WallpapersModel working with thumbnails of images/videos recorded on disk?
I think the problem with WallpaperPreviewItem wasting memory would be alleviated, although we no longer have live previews.

WallpapersModel won't care if somehow a screenshot is provided for specific activity and screen. It will be extendable to new ways to present previews. Of course I don't know how that screenshot can be taken for activities that are not the active one and if the user must also approve first such behavior.

No, I wasn't thinking about screenshots. The idea was that WallpaperPreviewItem take the paths provided by WallpapersModel and generate thumbnails of the images/videos on disk, with a small size to not take up much space in memory when loaded.

In T13037#234728, @mvourlakos wrote:

In T13037#234721, @tcorreabr wrote:

Going back to solution B, what do you think about WallpapersModel working with thumbnails of images/videos recorded on disk?
I think the problem with WallpaperPreviewItem wasting memory would be alleviated, although we no longer have live previews.

WallpapersModel won't care if somehow a screenshot is provided for specific activity and screen. It will be extendable to new ways to present previews. Of course I don't know how that screenshot can be taken for activities that are not the active one and if the user must also approve first such behavior.

In T13037#234729, @davidedmundson wrote:

Redesign PlasmaShell in order to have DesktopViews for each running Activity in each screen. In Example 1 that would mean six different DesktopViews that could be used afterwards as Previews in kwin scripts, desktop components etc... Personally I can not take over such big task.

It's not that much work to do, the challenge is keeping the memory down.
1920x1080x4bytesperpixel = 8Mb. Then we need that in memory and in the GPU as a texture. That's 16. Then we need the final framebuffer with the applets drawn on, both front and back. So 32Mb. Then we multiply that by 6.
Maybe some magic tricks with expose events could help us.

Redesign PlasmaShell in order to have DesktopViews for each running Activity in each screen. In Example 1 that would mean six different DesktopViews that could be used afterwards as Previews in kwin scripts, desktop components etc... Personally I can not take over such big task.

In T13037#234721, @tcorreabr wrote:

Going back to solution B, what do you think about WallpapersModel working with thumbnails of images/videos recorded on disk?
I think the problem with WallpaperPreviewItem wasting memory would be alleviated, although we no longer have live previews.

Another reason I chose solution A is because it's quite natural for me to think that the activities were designed to have their own desktops, plasmoids included. But I didn't know about the tough experience that Plasma 4 had.

In T13037#234603, @tcorreabr wrote

I also think that solution A is a big task, but if there is a consensus that it is the right one, wouldn't it be better to concentrate efforts on it?

As the WallpapersModel works with image/video paths and you mentioned the lack of widgets layers, I assumed that LiveDesktopPreviews would reload these resources in memory, which would be unwanted, especially when it comes to videos; don't you think so?

This seems like it would be very useful to alleviate the issues I ran into while trying to implement T10495.

A model like this could be quite useful I think.

I an trying to investigate if there is consensus in the community about the need of a WallpapersModel.

In D23174#519704, @ngraham wrote:

Hooray!

Next, do you think you could clean up the applications list so there aren't all those duplicates and they all get icons?

Next, do you think you could clean up the applications list so there aren't all those duplicates and they all get icons?

Ping.

p.p.s. The 'smart' termination was an attempt to fix the 'Qt SQL has no idea how to properly deinitialize on termination bug' :)

Sorry, I missed this one.

FYI you could have also solved it by creating a QDBusMessage::createMethodCall

Yeah, QDBusInterface blocks as it needs introspection to generate the properties/slots and stuff. It's a confusingly rubbish class.