wallpaper cache
Open, Needs TriagePublic

Description

So that if a user uses a wallpaper and that wallpaper is removed on disk because (for example) it was removed from the packaging, they don't get an ugly black background

and partly for the picture of the day stuff. that is something I want to refactor so plugins aren't writing C++

jriddell created this task.Feb 19 2019, 1:22 PM

<kbroulik> I'm mostly interested in it working for the lock screen
<kbroulik> Windows 10 has this bing picture of the day thing on the lock screen and people seem to be quite enjoying that

<flipwise[m]> and as far as I remember it would make having Qt scaled wallpapers cheaper performance-wise
<d_ed> I might try and take it on given I did the last wallpaper cleanup

jriddell assigned this task to davidedmundson.

My plan for POTD:

POTD written in QML as individual wallpaper plugins. Rather than a "POTD" which has providers.

All inheriting from a base class/item that has a slot/function "newImage(someUrl)"
Images will be cached and loaded asyncronously. Cached image is also loaded on boot.
This base class will take care of creating the Image and handling the transition.

New POTD plugins will be written in QML inherit from this
For porting purposes we'll inherit from this and import the old provider as an import.

mart added a subscriber: mart.Feb 19 2019, 1:35 PM

usability wise, i would much prefer still having a single "photo of the day" wallpaper.
as for caching, this would solve the lockscreen problem only if the plugin is used also as desktop wallpaper, but if it's used only in the lockscreen would still be broken would need an external potd service to be controllable by dbus or something like that)

It would be broken, I was hoping that I could assume POTD users would use it consistently.

I don't want to have some complex DBus syncing with FDs for images - we're better off revisiting whether the sandboxing we have is actually the right approach.


With regards to keeping a "single POTD".

I definitely want to migrate to scripting languages for the POTD backends and to make it easier to move them to the store.
I think re-using the existing plugin infrastructure is definitely the best way to go about doing that. It'll be super tidy yet also remain super flexible.

As for the UI, personally I think it's more consistent to have "Haeanu", "Wikimedia POTD" and "Animated Fireworks" all at the same level, but I can probably come up with some UI to group them if you think it's needed.

I don't have a very strong opinion but I kind of like the idea of each one being its own plugin. That way you could see and choose a POTD provider in one step rather than two (1. choose POTD plugin -> 2. then go through list of POTD options)

GB_2 added a subscriber: GB_2.Apr 15 2019, 8:41 PM
filipf added a subscriber: filipf.Apr 15 2019, 9:52 PM

Update: I did an amazing rewrite of wallpaper that cleaned a lot up, but this task still arguably remains.

Update: I did an amazing rewrite of wallpaper that cleaned a lot up, but this task still arguably remains.

Awesome! Do you think the cache is doable for 5.18?

odeda added a subscriber: odeda.Jun 25 2020, 7:15 AM

Have been doing some work on this in an attempt to fix a bug I came across the other day. From a first glance I see two possible options when looking at the plugin code:

  1. Cache images when they're added by the user and the delete icon in wallpaper settings deletes the cached image when applied.
  2. Cache images when the "Apply" button is hit in wallpaper settings so we only cache the current image.

I've written a rudimentary patch that implements option 1, so before I go any further would like to get some input. I think a benefit of option one is that it may work better for slideshow images, since we probably wouldn't want to copy over a new image to the cache every time the slideshow is activated.

However, option 2 would use less storage space and be more efficient for a traditional single image wallpaper.

If anyone has any other ideas I'd love to hear them as well.