That more pleasant gray would definitely be an improvement over the blue, and I would support doing that upstream to bypass all the bikeshedding over using the Plasma wallpaper. However, I still think using the Plasma wallpaper is even better. As I hope my screenshots and photos demonstrate, there isn't any contrast issue with the one we'd be shipping with.

An alternative would be to "adjust" the colour from the bright blue to a more neutral colour. Looking to e.g. Mac OS, you have a very pleasant grey colour, is the same I have set on my KDE desktop.

This would be an 18.10 goal that I can get behind. This would help us with updating the slideshow if there is one in Calamares.

+1, ship it!

So are we ok to go with this, as an initial upload anyway?

@raddison Well, I kinda understand what you mean. The SHA256SUMS.gpg key, the SHA256 and the .iso images are all in one basket.

64 looks a nice compromise to me. On a large but not hi-res screen, 80+ starts to look a big much/odd IMO, and we have to take into account that large amount of our user base will be people not blessed with hi-dpi,

@ragreen thanks for the suggestion. I was really trying to keep this selection small, and focused mostly on some classic non-photo type KDE wallpapers, that had been in KDE, but are not longer. Also makes copyright easier, as that job was done years ago for those.

64 looks a nice compromise to me. On a large but not hi-res screen, 80+ starts to look a big much/odd IMO, and we have to take into account that large amount of our user base will be people not blessed with hi-dpi,

What do you want to know? Neptune & Netrunner aswell as others are using Calamares very succesfully.

In the above screenshot, I have 80px icons and a 1x scale factor, and it doesn't look very messy to me...

As a matter of fact, 64 and 128 are the values that don't cause sub-pixel mess. Hence, probably, 64 is the best compromise.

Documentation is important. Now that we have 5.12.x in place, we should update/re-write/replace deprecated illustrations.

That's correct. We're using Calamares in Nitrux.

@ragreen That's correct. We're using Calamares in Nitrux.

+1, 80px icons look fantastic, especially with previews on by default now.

@uriherrera Nitrux has Calamares as well and it's Ubuntu-based, right?

So it's more like a question of whether we want to do it or not, I guess.

What do you want to know? Neptune & Netrunner aswell as others are using Calamares very succesfully.
You can find example configurations with branding here:
https://github.com/NeptuneOS/calamares-neptune
and here:
https://github.com/netrunner-desktop/calamares-desktop

... as a cross-distro project, we'd benefit from other people's improvements, and participate in a really worthwhile community effort.

Make sure you don't leave Marble Beach out. https://www.opendesktop.org/p/1200398/

Test package in ppa:kubuntu-ppa/staging-misc

Ooh, I love Elarun and Dance of the Spirits.

Nice! Those are some of my favorites from the past too. +1

My suggestions would be:

(Blushing)

In T7854#126259, @rikmills wrote:

Did not do this for 17.10 as the default wallpaper for Plasma 5.10 has some very light parts which gave horrible contrast with the user logos and login fields/buttons.

So lets revisit and see how it looks with the current darker default wallpaper. Initially looks ok, but some better screenshots would help for review.

This would be great, the default blue is ridiculous and looks unprofessional.

Could not reproduce with latest daily image and the past few weeks' images.

Upstream tasks were largely agreed to but got derailed into a total theme redesign, unfortunately. It's up to us if we want to ship 18.04 without login and lock screens that sear our users' eyeballs.

Cool, sounds like a plan! Hopefully Baloo is in better shape by then anyway. Michael has been doing an amazing job of rehabilitating it so far.

In T8256#133726, @ngraham wrote:

Darn, straight from the horse's mouth.

Okay, let's leave it off for the LTS and consider bringing it back for non-LTS releases.

Darn, straight from the horse's mouth.

I'm not happy to say this: Switching off full-text indexing by default is a reasonable thing to do.
There are many bugs reporting baloo_file going berserk, specially when large text files are involved. So I think it's better to get full-text indexing out of the way for some time. Testing this is difficult. To mimick real-life one needs a lot of files and some really large ones. Also with only James and me contributing to baloo there is only little man power. And the list of crash reports is long ...

Okay, so our substantive objections are that it's a resource hog. Do we have metrics or bug reports demonstrating this, and can we confirm that the problem disappears when Baloo is still on but only doing filename indexing? I personally have never experienced high CPU or memory usage caused by Baloo. My primary machine is a laptop and I get about 8 hours of battery life with it when doing real work, and I do measure the energy impact of various components.

Escaped, and now doesn't seem to be working. May need to force this harder at a system config level.

Fix hopefully: https://launchpad.net/ubuntu/+source/casper/1.390

Most people I know, techie or not at all, disable such indexing where it exists and they are aware of it, so I dispute that conclusion for any claim of popularity.

In T7057#133660, @ngraham wrote:

In T7057#133659, @darinmiller wrote:

Closing this task as it it fixed in 18.04.

Were you ever able to file an upstream bug on the freedesktop bug tracker? Ultimately, it would be good to get this fixed there so we don't need a workaround.

Oops, actually closing (resolving) this time.....

In T7057#133659, @darinmiller wrote:

Closing this task as it it fixed in 18.04.

Closing this task as it it fixed in 18.04.

https://launchpad.net/ubuntu/+source/kwin/4:5.12.3-0ubuntu2

Woohoo!

Done in: https://launchpad.net/ubuntu/+source/kubuntu-settings/1:18.04ubuntu6

Done in: https://launchpad.net/ubuntu/+source/kubuntu-settings/1:18.04ubuntu6

Done in https://launchpad.net/ubuntu/+source/kubuntu-settings/1:18.04ubuntu6

Done in https://launchpad.net/ubuntu/+source/kubuntu-settings/1:18.04ubuntu6

Done in https://launchpad.net/ubuntu/+source/kubuntu-settings/1:18.04ubuntu6

Done in https://launchpad.net/ubuntu/+source/kubuntu-settings/1:18.04ubuntu6

I'm closing this on the premise that @rikmills has raised some concerns that need to be addressed before this goes any further.

Way past EOL date.

I think this can be marked as a dup of https://phabricator.kde.org/T7332 but I'm not quite sure how.

@rikmills is this still a thing?

I can take care of this.

I think that anything within the qt5 packageset should also be in the kubuntu packageset. I can +1 this request with my MOTU + Qt 5 Uploaders hats on if needed, but that should be easy enough for a Kubuntu Developer to request.

@rikmills Ideas?

Minus all the OMG Ubuntu stuff, I can look into this.

I don't necessarily think we need a task for this; Santa's working on it.

I agree with @muskovac here.

+1 (please shout if it's annoying rather than useful :D )
both laptop and external display look better for me. This is also gnome's default setup, so unlikely to trigger incompatibilities?

-1 from me this close to release. This is really something that should be done far before Feature Freeze. Feel free to give it a try for 18.10 though.

Definitely not for 18.04 at this late stage in the game, but maybe 18.10?

I believe @tsimonq has talked about this. It would get a hearty +1 from me, FWIW. Calamares is really good, and more easily themable than Ubiquity. Also, as a cross-distro project, we'd benefit from other people's improvements, and participate in a really worthwhile community effort.

Added konversation