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.

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.

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?

So while I'm not absolutely sure on this point, maybe the biggest benefit of migrating from script to effect (or maybe a plasmoid?) would be to avoid the limit of type of window allowed for scripts. Could this provide some integration with plasma panels and their plasmoids (like launchers)?

On second thought, although I've only thought of one disadvantage, I think it outweighs all the advantages of switching from ThumbnailItem to EffectWindow. Mixing C++ and QML elements in the same UI would make everything a nice (even impractical) mess.

The question is define the best way to implement this. KWin script? KWin effect? Plasmoid?

Right. And migrating the effects from C++ to QML can bring good results. Plasma itself shows that QML is great for building UI.

Zero based position parameters.

toplevel.h changes removed.

Component version bumped.

Cool!

Q_UNUSED semicolon removed.

I just thought of a separate list to avoid impact in possible existing scripts that currently do not filter desktop windows and may need to.

Sorry for the silly question, but should I update the version of all components or just the ClientModelByScreenAndActivity one?

activities property moved from Toplevel to AbstractClient class.

Indeed. The ideal solution would be to work with a generic ClientModel and be able to set the restrictions on the qml side, avoiding the declaration of a model for each situation.

Thanks for fixing this!

For the record, only now I went to read https://community.kde.org/Get_Involved/development. Now after solving some issues in my project, I must use Phabricator properly and maybe I can contribute with some patches to KWin.

Sorry for that mistake. For now I am solving some internal problems of my project (qml side of things) and I haven't even compiled kwin yet. After that I plan to submit some patches.

Unfortunately, yes. I confirmed it now using the Desktop Grid effect.

It would be for the opening and closing animations of the effect, which I think should be as similar as possible to the ones from Present Windows effect. But I think I can get the stacking order through the EffectWindowList stackingOrder() method of the EffectsHandlerImpl class. Anyway, thanks for your explanation.