Ship the plasma-workspace-wallpapers package by default in Neon
Open, WishlistPublic

Description

KDE Neon should ship with the plasma-workspace-wallpapers package by default, which will provide a nice assortment of pretty wallpapers. Also, this package should get better and prettier over time due to D17780 and T10220.

Manjaro's KDE version already installs this package by default, and I've proposed that Kubuntu do likewise: T10218. As a KDE showcase distro, I think KDE Neon should too--especially the user edition! But probably the developer edition too.

ngraham created this task.Mon, Dec 24, 6:15 PM
ngraham triaged this task as Wishlist priority.
ngraham updated the task description. (Show Details)Wed, Dec 26, 5:45 PM
ngraham added a parent task: T10269: Improve wallpapers.
ngraham renamed this task from Ship the plasma-workspace-wallpapers package by default to Ship the plasma-workspace-wallpapers package by default in Neon.

I agree but then it's so large!!! oof

I feel like I was discussing this with someone at some point but then forgot about it since we couldn't come up with a good solution. That said, in lieu of solution it's probably best to just pack the wallpapers into the ISO.

BUT

What I think would be really cool though is on-demand installation. As in: the config dialog shows the preview but trying to use it will first install it via discover or maybe directly via packagekit actually. appstream data may well be useful for that.

In fact, since I am already coming up with nonesense...why wouldn't all KNS-enabled KCMs behave like that? Let's ignore the issue at hand for a moment and consider the content from http://store.kde.org/ exclusively. What if the wallpaper dialog (and others) showed top rated (or downloaded for all I care; or specially curated) content natively in the preview view, so I don't need to go into the knewstuff dialog at all but can get good content from the internet right then and there.

The main problem I have is that delivering this via a monolithic binary blob such as a deb package is in fact a horrible way to do it since users may not like any of them or only half of them or none of them. Why burden their disks (and subsequent plasma release downloads) with wallpapers they don't even want. The problem is largely presentational: the wallpaper config dialog looks a bit sad with only one wallpaper and the user might not readily find good wallpapers. But then TBH the true solution is make the dialog put content at the user's fingertips regardless of the plasma-workspace-wallpapers tarball, and instead have it get content from the store. To that end I think the wallpapers package should possibly go away and moved into the store, which has the added benefit of allowing the creators to get some money from their creation.

And on the store side the ability to be so prominently featured (be it via rating count or manual curation) adds additional incentive for artists to create good wallpapers (or any other KNS content) as getting in the "default" view would have a substantial impact on download count.

I agree but then it's so large!!! oof

You might be interested in D18005: Include only the largest size for each wallpaper. This cuts the size down to only 25 Mb!

I really like the idea of KNS-enabled KCMs actively pulling down content that we could specify automatically the first time they're launched. A bit out of scope for this right now though. :)

If https://phabricator.kde.org/D18005 gets in then sure but I think an extra 132MB will have people complain a lot more than be happy

sitter added a comment.Mon, Jan 7, 1:55 PM

if the diff doesn't get landed, another cheap approach is to add a button 'install addition wallpapers' in the wallpaper kcm which opens discover with an appstream component for the wallpapers. it'd be similar to a patch I maintained at kubuntu except with appstream ids we can now solve this properly in plasma itself without patching

if the diff doesn't get landed, another cheap approach is to add a button 'install addition wallpapers' in the wallpaper kcm which opens discover with an appstream component for the wallpapers. it'd be similar to a patch I maintained at kubuntu except with appstream ids we can now solve this properly in plasma itself without patching

Cool idea. However then the wallpaper KCM would confusingly have two buttons to install new wallpapers: one that invokes GHNS, and another one that gets just the Plasma wallpapers via Discover.

I think it would be a better user experience to include them by default if possible after D18005 lands.

If https://phabricator.kde.org/D18005 gets in then sure but I think an extra 132MB will have people complain a lot more than be happy

Agreed. This is one of the primary reasons why we're trying to slim down the size.