Create Task
Maniphest T13037

Wallpapers Model in KActivities
Open, Needs TriagePublic
Actions

Description

KActivities::WallpapersModel

By using the success story of Latte SlideShow plugin,

Plasma/Wallpapers will become responsible to feed the KActivities::WallpapersModel with data. So WallpapersModel will not be responsible to discover the wallpapers data like it is currently.

The model should provide the following structure:

[Activity1]
      [Screen1]  -  [WallpaperData]
      [Screen2]  -  [WallpaperData]
[Activity2]
      [Screen1]  -  [WallpaperData]
      [Screen2]  -  [WallpaperData]
  .
  .

WallpaperData

type: wallpaper type
path [optional] : file path if there is any
properties [optional] : properties that each wallpaper type provides

Supported Wallpaper Types

typepathpropertiesComment
image<image_path>
color<colorname_string>
video<video_path><video_position>, <video_position_registration_timestamp>the timestamp can be used from consumers to reposition the video playback properly
qmlcode (?)<qml_code_string>full qml code string that can be used from consumers to recreate a qml code representation

WallpaperPreviewItem
It might be a good idea that KActivites provide also a WallpaperPreviewItem that can be used as delegate in ListView(s), GridView(s), Flow(s) etc... when they use the WallpapersModel.
WallpaperPreviewItem is going to be responsible to draw a proper QQuickItem based on the provided WallpaperData.

Use Case Example

  1. During startup WallpaperModel is completely empty
  2. Plasma::Wallpapers when loaded are exposing their wallpaper metadata to WallpapersModel
  3. WallpapersModel is signaling its changes
  4. WallpaperPreviewItem(s) are updating their visual presentation based on model changes

Related Objects

mvourlakos added a comment.Apr 24 2020, 4:25 PM

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

One of the main reasons is that with current PlasmaShell implementation it is not possible to have a RunningActivities Desktop LivePreview.
This is because each DesktopView is a single window assigned at specific screen and contains stacked in qml the running activities visual desktop presentation.

Example 1: In Plasma two screens and three running activities means two DesktopView windows and every window contains internally in qml three stacked desktop layouts.
The previous example makes it impossible to provide desktop global live previews for activities that are running but are not the current one.

So if we want LiveDesktopPreviews for All Running Activities we can:

Solution A

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.

Solution B

Provide a WallpaperModel that is going to be used by various Plasma/KWin parts and will not prevent of course Solution A if such a decision is taken in the future.

ivan added a comment.Apr 24 2020, 6:39 PM

A model like this could be quite useful I think.

But, this does not really belong to KActivities. Wallpapers and screens are a Plasma thing.

The background code inside KActivities was meant to be temporary and removed once we get a DBus API for setting-getting wallpapers in Plasma which was planned at the time but never materialized.

ngraham added a subscriber: ngraham.Jun 24 2020, 7:34 PM

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

tcorreabr added a comment.Jul 3 2020, 8:23 PM

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?

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?

mvourlakos added a comment.Jul 3 2020, 11:01 PM
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?

It was how Plasma 4 was working. Plasma devs had concluded that it was too difficult to maintain and it was not memory efficient because of the multiple windows. I am not in favor of any solution I just want a decision to be taken and check out how many people would be interested implementing it.

tcorreabr added a comment.Jul 4 2020, 9:08 PM

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.

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.

mvourlakos added a comment.Jul 4 2020, 10:07 PM
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.

davidedmundson added a comment.Jul 4 2020, 10:31 PM

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.

But back to your goal:
You want something like desktop grid but for running activities? Then the of Plan B being that kwin could load the wallpapers directly? and then render the other windows from that activity on top?

mvourlakos added a comment.Jul 4 2020, 11:08 PM
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.

Sounds interesting... I had the impression that Plasma team for Plasma 5 had decided to not follow that road. From my understanding this was how Plasma 4 was working.

But back to your goal:
You want something like desktop grid but for running activities?

Yes but it could be used also in pagers, Activity Manager etc... In any qml part that wants to draw the desktop of a running activity

Then the of Plan B being that kwin could load the wallpapers directly?

exactly, based on the metadata that could be files, video links etc.

and then render the other windows from that activity on top?

exactly. This is already the case for Parachute that is drawing window previews on top of current Plasma desktop window

tcorreabr added a comment.Jul 7 2020, 6:49 PM
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.

mvourlakos added a comment.Jul 7 2020, 6:59 PM
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.

that could be an option for WallpaperPreviewItem. Its consumers could choose to use a thumbnail or not.